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

TCP segment of a reassembled PDU, but packet length less than MSS

0

When I tracked a TCP stream, there is a packet which length is 75 but "TCP segment of a reassembled PDU" showed in WireShark. I searched the mean of "TCP segment of a reassembled PDU", which only appeared when application data length exceed MSS. So why this happen? alt text Thanks

asked 27 Jun '16, 23:31

liuanhf's gravatar image

liuanhf
6113
accept rate: 0%

Working from an image makes investigating the question very hard. Can you share a capture in a publicly accessible spot, e.g. CloudShark?

(28 Jun '16, 01:00) Jaap ♦

Thank you for your reply, sorry about only one image, please see the answer with me

(28 Jun '16, 03:55) liuanhf

One Answer:

2

which only appeared when application data length exceed MSS

It is a misunderstanding. [TCP segment of a reassembled PDU] is shown in the Info column whenever the TCP packet in question contains just a part of the application layer PDU, except the final one, regardless the MSS. The sending side may not make use of the MSS and send shorter packets for whatever reason. So in your case, frames (packets) 148, 150, and 152 contain the complete Ceph PDU.

answered 28 Jun '16, 00:59

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

edited 29 Jun '16, 03:36

Thank you very much for your reply. It seems my misunstanding about [TCP segment of a reassembled PDU]. But I still don't know when application will not not make use of the MSS. I've tried a simple server and client program, client sends 3 times to server, but tcp sequences are different. Any hint will be appreciated. Thank you!

(29 Jun '16, 02:02) liuanhf

But I still don't know when application will not not make use of the MSS

This is not a question regarding Wireshark (so off-topic on this site) nor a question Wireshark itself could help you answer. Wireshark shows you clearly what has happened, but it can tell you why it has happened only in a few cases.

In particular, Wireshark can detect and indicate some protocol errors, but it has no means to find out why applications behave the way they do on a formally correct input.

client sends 3 times to server, but tcp sequences are different

can you elaborate what exactly worries you here?

TCP sequence numbers must be different for different chunks of data in the same TCP session, it is the cornerstone of TCP handshaking.

If you have in mind different sessions carrying identical chunks of data, it is still normal that the sequence numbers differ if we talk about absolute sequence numbers - it is also due to the way how TCP works. It is only for convenience of reading that Wireshark uses the sequence number of the first SYN packet as a reference and displays offsets from this value, called relative sequence numbers, in place of the absolute ones.

(29 Jun '16, 03:51) sindy

Oh, sorry, some of my description are not clear.My intention is:

  1. I found the ack number of packets(148/150/152) are the same, not the sequence, sorry
  2. Wireshark display [TCP segment of a reassembled PDU] may because they have the same ack number
  3. I don't know why their length less than MSS but they have the same ack number, so I test my program. "client sends 3 times to server, but tcp sequences are different" is wrong, sorry, I mean ack number are different

So my question is how this happen -- length less than MSS but ack number are the same, who did this? applicaion layer or IP stack?

sorry again and hope for your reply

Thank you very much!

(29 Jun '16, 04:42) liuanhf
  1. this is probably normal (probably because you haven't provided a capture file). Ack value in A->B direction only changes if some data have been received in B->A direction, as the Ack value in A->B direction announces the next expected Seq value of the B->A direction.

Example: A sends a packet with Seq=100 and the payload size is 22, which means that the Seq of the next packet from A will be 122. In response, B sends a packet with Ack=122, telling A that it may send that next packet rather than repeating the previous one. If B would send any lower value in Ack (like e.g. 100), most likely after some delay, it would mean that B has not received the packet from A, and that A should re-send the part of data starting from Seq=100.

  1. no, see above. [TCP segment of a reassembled PDU] only means that this TCP packet is other than the last one of an application-layer PDU, as stated in my original Answer. More complex cases do exist, but I don't want to confuse you at this stage; however, rest assured that these cases have nothing to do with the Ack value.

  2. if the client sends to server three packets with some payload while the server sends no payload back, Seq should be growing in the packets from client and Ack should be correspondingly growing in the packets from server. Ack in packets from client and Seq in packets from server should not change.

(29 Jun '16, 05:21) sindy

Thank you very much.

1: Yes, you are right, I re-test my program as you mentioned--"the server sends no payload back", the ack numbers of client are not change.

2: In my program,though ack number are the same, but wireshark does't show [TCP segment of a reassembled PDU], so I think if wireshark show [TCP segment of a reassembled PDU], it must be a session of an applicaton-layer protocal over tcp

The next step is to find out why tcp segmentation happened although the length of an application-layer protocal less than MSS. May be there are some mechanisms

Thank you for your patience and guidance

(29 Jun '16, 22:35) liuanhf

If your test application doesn't use a PDU of some higher layer protocol (which Wireshark can recognize!) as a payload of the TCP packets, i. e. if TCP is the highest dissectable protocol in the TCP stream, and the payload is dissected as just Data, Wireshark will never show [TCP segment of a reassembled PDU] because there is no PDU to be reassembled.

When you look at packet timestamps (frames 148, 150, and 152 in your screenshot), it is quite likely be that your TCP stack is flushing the Tx buffer more frequently than the application writes the data to the socket. So the application writes the first 9 (75-66) bytes of the PDU to the socket, and before it collects the the next 136 (202-66) bytes to write, the TCP stack decides to send what it has so far.

You may verify this theory using your test program if it is running on the same machine on which you took your capture, i.e. if it is using the same TCP stack. You would send 20 bytes, then wait for 0.5 ms, and then send another 30 bytes. If you get two packets, that was it; if you get just one with 50 bytes of payload, it is something else. But make sure that these socket writes do not set an equivalent of PSH (push) flag, as in such case the TCP stack must flush the buffer immediately, while your capture doesn't show PSH flags to be present in your [TCP segment of a reassembled PDU] packets.

(30 Jun '16, 02:26) sindy
showing 5 of 6 show 1 more comments