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? asked 27 Jun '16, 23:31  liuanhf |
Thanks
One Answer:
It is a misunderstanding. answered 28 Jun '16, 00:59  sindy 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
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.
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:
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
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.
(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 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 (30 Jun '16, 02:26) sindy showing 5 of 6 show 1 more comments |
Working from an image makes investigating the question very hard. Can you share a capture in a publicly accessible spot, e.g. CloudShark?
Thank you for your reply, sorry about only one image, please see the answer with me