Wireshark mailing list archives
Re: Capturing up 64K byte frame on a VM guest
From: Martin Visser <martinvisser99 () gmail com>
Date: Mon, 15 Mar 2010 12:37:36 +1100
Just following up on myself, it seems that this might have been initially implemented quite a while ago (2002 in Linux 2.5.33) http://kerneltrap.org/node/397 There is quite a bit of chatter on talk in the VMware KBs and communities about so-called TSO (TCP Segmentation Offload). It seems to be there be default (with the e1000 NICs that we have). Obviously it's intent is to provide better transfer between guest OS and the NIC (a 64K frame will be transferred in a single DMA request). As yet I need to determine whether this is causing us grief. All that said I think it is a "bug" in the TCP stack to show the small MSS yet accept the larger send frames. Of cause none of this talk on my behalf is actually related to Wireshark. I guess it is a case of when you think you are seeing what is an error using Wireshark it might just be showing up some black magic (smoke and mirrors) that actually works. Regards, Martin MartinVisser99 () gmail com On Mon, Mar 15, 2010 at 12:13 PM, Martin Visser <martinvisser99 () gmail com>wrote:
One other thing in regard to this is that the received TCP MSS (max. segment size) from the client, by the server is 1420 bytes. So when viewing the .cap file it looks like it is breaking the TCP protocol (by send larger than MSS segments). I'm surprised this anomaly doesn't seem to been noted by anyone before (using my Google brain). Regards, Martin MartinVisser99 () gmail com On Sat, Mar 13, 2010 at 9:54 PM, Martin Visser <martinvisser99 () gmail com>wrote:Hi, Doing some troubleshooting work at a customer and came across a strange anomaly I hadn't seen before. We setup a test server using a run-of-the-mill Centos 5.x machine running as a VMware ESX guest (not sure of the version). I believe the NICs are Intel e1000. We captured some HTTP data transfers using the Centos built-in tcpdump on the test server. Taking this offline to analyse in Wireshark I was surprised to Ethernet frame sizes up to 64000 bytes in length. I am dead-certain these aren't acually going on the wire (based on previous captures off a switch port-mirror) and even the fact that the Centos guest has default 1500 byte MTU set for it's interfaces. By the time these frames get to the client they have been fragmented to the correct size of less than 1500 bytes. (This is despite the "Don't Fragment" bit set in all outgoing frames). Has anyone else seen this before? The only thing I can put it down is that there is probably a TCP offloading driver being used, or maybe some magic that running inside VMware ESX, and that the tcpdump capture is being down at a point where larger-than-ethernet buffers are pushing data to the hardware/virtual NIC for TCP processing. (We are tracking a problem where it seems clear that TCP segments are going missing in certain circumstances, and this has come up as a bit of a red herring.) Regards, Martin MartinVisser99 () gmail com
___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- Capturing up 64K byte frame on a VM guest Martin Visser (Mar 13)
- Re: Capturing up 64K byte frame on a VM guest Martin Visser (Mar 14)
- Re: Capturing up 64K byte frame on a VM guest Martin Visser (Mar 14)
- <Possible follow-ups>
- Re: Capturing up 64K byte frame on a VM guest Saulpaugh, Chris (Mar 17)
- Re: Capturing up 64K byte frame on a VM guest Martin Visser (Mar 14)