This started while trying figure out why loading a web page in a browser from apache via HTTP was so very slow going through a pinhole from an untrusted network to a trusted one.
I thought it was smoothwall related, see my post here http://community.smoothwall.org/forum/viewtopic.php?p=297864#p297864 but not so sure and drove me to using wireshark and tcpdump.
This is what I am seeing and lead to my main question of why does wireshark show 3 packets but tcpdump only shows 1 big packet? Is something combining them? Why do the ID's go in order for both wireshark and tcpdump (39771, 39772, 39773) and then wireshark goes to 700x but tcpdump goes to 39774? ug, out of my league here.
Wireshark on the wire shows 3 packets, id 7006, 7007, 7008 with a Total Length of 1500, however, on the router running tcpdump, I see ONE packet, id 39774 with a size of 4420 which causes the router to generate an ICMP Destination unreachable (Fragmentation needed).
If Debian is the source machine, very many ICMP Fragmentation Required packets are generated by the router.
If Windows XP is the source machine, transfer is very fast and no ICMPs.
vmware-tools and vmxnet3 driver is installed on everything (debian, windows, router)
While the issue was not related to wireshark or tcpdump, it was the strange packets I was seeing that sent me here to ask “why” which may have got me looking in the right place.
asked 05 May ‘11, 08:53
edited 08 May ‘11, 09:17
So, it looks like I found a fix: VMware_Networking_Speed_Issue
Cause: There is a bug related VMware network adapters or their drivers related to "segmentation offload" (TSO and GSO). I have heard one mention that the checksum feature may also have problems.
Solution: Turning off TSO/GSO on the guest OSes is the fool-proof solution. You could try installing a newer OS or try playing with the adaptor type (eg: E1000, VMxnet2) but that seems to work only some of the time.
Linux solution (worked for me)
NB: This linux fix does not persist through reboot. The article talks about how you might do that.
Windows solution (did not try, never had a problem with WinXP)
answered 08 May ‘11, 09:08
edited 08 May ‘11, 09:11
When capturing on the same device sending packets, you will often see outbound packets greater than the MTU because the capturing software, tcpdump in this case, sees the packet before it's packetized on the wire. You may also encounter packets with less than the minimum number of bytes required because the padding hasn't been added yet.
As for the IDs, are you looking at the IP header's identifier field and trying to compare it with Wireshark's relative sequence numbers, perhaps? If you want to see the identifier, you can add a custom column to display it using ip.id as the display filter.
As for the fragmentation issue, what's the path MTU? Most likely it's lower than 1500 bytes, thus the ICMP destination unreachable message.
answered 05 May '11, 09:45
Let me get this straight, you have a client (192.168.5.199) connected to the Smoothwall (gate) through a virtual switch vSwitch-X and the Smoothwall (gate) is connected with a second interface to the server (10.0.0.16) through vSwitch-Y.
When you try to open a webpage on the client, on the webserver you can see 3 outgoing packets in Wireshark, while tcpdump on the server interface of the Smoothwall shows you 1 incoming packet from the webserver. Or are you running tcpdump on the client facing interface?
The behavior is weird, but it looks like somehow one of the systems is trying to create jumbo frames out of the 3 separate packets. And smoothwall does not like it.
The "[bad hdr length 16 - too short, < 20]" part of the output is due to the fact that the ICMP message contains part of the original packet that caused the unreachable message. tcpdump is interpreting this payload and sees a packet that is cut in the middle of the tcp header (which should at least be 20 bytes long, but only 16 bytes are present).
answered 05 May '11, 16:17