Ask Your Question
0

Why 40 bytes overhead at end of TCP/IP Frames?

asked 2021-06-16 07:35:49 +0000

rip gravatar image

Running a tcpip socket exchange between 2 apps on the same VMWare Windows server (loopback). Wireshark shows an extra 40 bytes (nominal) at the end of every frame.

The extra bytes are not present if the same exchange is run on a standalone Windows laptop.

What are these extra bytes (bold below)?

Windows Server Exchange (sample data frame)

  • 0000 02 00 00 00 45 02 00 37 9a 72 40 00 80 06 00 00
  • 0010 0a 18 11 0d 0a 18 11 0d cc 44 27 48 4f 82 81 6a
  • 0020 87 16 6c 5f 50 18 40 00 40 4b 00 00 01 30 30 30
  • 0030 30 30 31 02 30 32 38 30 43 44 03 00 00 00 00 00
  • 0040 86 db 00 00 00 00 01 00 00 00 00 00 89 00 12 00
  • 0050 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00
  • 0060 34 00 00 (data italics, extra bytes bold)

Standalone Laptop Exchange (same sample data frame)

  • 0000 02 00 00 00 45 00 00 37 c2 19 40 00 80 06 00 00
  • 0010 c0 a8 01 72 c0 a8 01 72 d8 50 1b dd cd eb e9 99
  • 0020 4c 92 46 64 50 18 40 00 6b a5 00 00 01 30 30 30
  • 0030 30 30 31 02 30 32 38 30 43 44 03
edit retag flag offensive close merge delete

Comments

Do you have WinPcap installed, or do you have Npcap installed, on the server on which you captured this?

If it's Npcap, what version of Npcap is it, and if you run Get-NetAdapter from PowerShell, does it show "Npcap Loopback Adapter" and, if so, how many instances does it show?

Guy Harris gravatar imageGuy Harris ( 2021-06-16 09:20:47 +0000 )edit

same sample data frame

Are you sure they're the same? The bytes preceding the data bytes in italics are different, so I don't understand what's being presented here. Surely this isn't the same packet captured at both the server and laptop as the data is different. Can you provide the hex bytes of the entire packet as captured on both sides?

cmaynard gravatar imagecmaynard ( 2021-06-16 14:47:12 +0000 )edit

The fields that differ between them are:

  • the IPv4 Type of Service field (0x02 in the first, 0x00 in the second);
  • the IPv4 Identification field (not a surprise);
  • the IPv4 source and destination addresses (10.24.17.13 in the first, 192.168.1.114 in the second);
  • the TCP source port (52292 in the first, 55376 in the second);
  • the TCP destination port (10056 in the first, 7133 in the second);
  • the TCP sequence and acknowledgment numbers (not a surprise, they're relative to the ISN, which is generally randomly chosen);
  • the TCP checksum (not a surprise, as the TCP headers differ).

Notably, the IPv4 total length is the same - 55 bytes - so the extra stuff is past the end of the IPv4 packet/TCP segment.

So they're presumably not "the same" in the sense of "the same frame captured at two different capture points), but they're ...(more)

Guy Harris gravatar imageGuy Harris ( 2021-06-16 19:44:05 +0000 )edit

And the same questions about the laptop:

Do you have WinPcap installed, or do you have Npcap installed, on the laptop on which you captured this?

If it's Npcap, what version of Npcap is it, and if you run Get-NetAdapter from PowerShell, does it show "Npcap Loopback Adapter" and, if so, how many instances does it show?

Guy Harris gravatar imageGuy Harris ( 2021-06-16 19:44:57 +0000 )edit

@Guy Harris and @cmaynard Thanks for comments.

1) On the laptop, Wireshark is reporting Npcap v1.31 and it is not reported in response to Get-NetAdapter. Apologies but I don't have access to the Server VM atm.

2) The scenarios for the above sample data are that the 2 apps involved are executing the same network exchange in different environment configurations (i.e. Scenario#1 both apps in a single VMWare Windows 10 Server VM and then Senario#2 both apps in a standalone Windows 10 Laptop.
The same payload is being exchanged, but obviously the IP and TCP headers will be different.

3) Ran another scenario yesterday with app#1 in a different Windows Server VM connecting to app#2 running in the same (original) Windows Server VM environment . . . and no extra bytes.

It's looking like the extra bytes:

  • have to do with loopback in a VMWare ...
(more)
rip gravatar imagerip ( 2021-06-18 01:44:52 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2021-06-16 12:00:59 +0000

hugo.vanderkooij gravatar image

Be aware that Ethernet packets are supposed to be at least 64 bytes. So it may depend on where in the stack you capture the data. Close to the nic this may be including the padding.

edit flag offensive delete link more

Comments

These aren't Ethernet packets. The original poster said they're being captured on the loopback adapter; this is on Windows, where packets on the loopback adapter use the BSD "null" encapsulation, where the only "link-layer" header is a 4-byte AF_ value, and that's what's seen here - 02 00 00 00 is 2, in little-endian form, and 2 is AF_INET, i.e. this is an IPv4 packet.

Loopback interfaces don't impose a minimum length for packets (well, there's a 4-byte minimum due to the null header, but that's it).

Guy Harris gravatar imageGuy Harris ( 2021-06-16 19:06:46 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2021-06-16 07:35:49 +0000

Seen: 1,333 times

Last updated: Jun 16 '21