This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

PSH packet Length 2920 eventhough MSS negotiated in 1460

0

Hi Team,

I am seeing a TCP connection where the the MSS is negotiated as 1460 but there are few PSH packets which have the length 2920. I have also confirmed that the MTU of the windows box which is sending the data is 1500. So there is no way that the windows box can send a packet of such length.

Following ping test ensures that the windows box has max MTU of 1500.

C:\Documents and Settings\Administrator>ping 172.16.199.105 -f -l 1472
Pinging 172.16.199.105 with 1472 bytes of data:
Reply from 172.16.199.105: bytes=1472 time<1ms TTL=64
Ping statistics for 172.16.199.105:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
Control-C
^C

C:\Documents and Settings\Administrator>ping 172.16.199.105 -f -l 1473 Pinging 172.16.199.105 with 1473 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Ping statistics for 172.16.199.105: Packets: Sent = 2, Received = 0, Lost = 2 (100% loss), Control-C ^C C:\Documents and Settings\Administrator>

I also disabled the following in the wireshark, so that wireshark is not combining two packets in to one.

Reassamble fragmented IP datagrams

Allow subdissector to reassemble TCP streams

The capture was taken from the same windows PC which is supposedly sending the packet of Length 2920. Has anyone encountered such issue. Is this a problem with the windows box or the wireshark tool.

Thanks!

asked 14 Mar ‘11, 21:43

Prab's gravatar image

Prab
1112
accept rate: 0%

edited 15 Mar ‘11, 00:59

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245


2 Answers:

3

Yes, what you see is a typical result of capturing on the sending PC equipped with a network card that has the "large send offload" option. What happens is that Wireshark captures the outgoing data before it is actually completely processed for transmission in the network card, meaning that you see large chunks of data in your trace that get chopped down to the real network packets in the network card only after you've already recorded it.

You can verify this by capturing on the receiver at the same time - you'll see that all packets that actually arrive have the correct size. Or you can go into the advanced settings of your network card and turn of the large offsend feature to see the difference.

answered 15 Mar '11, 00:59

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

3

This can happen on systems that support TCP segmentation offloading on the NIC. Wireshark captures packets between the NIC-driver and the NIC. Since the TCP segmenting is now done on the NIC, wireshark sees a large frame going out, but the NIC splits it up into multiple packets on the wire.

(see: http://wiki.wireshark.org/CaptureSetup/Offloading#Segmentation_Offload)

answered 15 Mar '11, 01:03

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Hi SYNbit, Jasper,

Thanks for the comments. Now i understand this.

(15 Mar '11, 02:50) Prab

You're welcome :-)

Could you accept either Jaspers or my answer by clicking on the "checkmark" on the left of the answer? That way the question will be removed from the list of "unanswered questions". Thx!

(15 Mar '11, 10:40) SYN-bit ♦♦