Re: Question about reassembled fragmentation

[Guy Harris <guy () alum mit edu>]

On Nov 11, 2009, at 12:46 AM, Qmo (Yi-Sheng) wrote:

> Thank you in advance. But I still confused.
> Do you mean when Wireshark encounter packet No.132,
> it knows it's a part of packet No.134. How does Wireshark do that?
> In the cap file, each packet is composed by a serial strings,

Actually, each packet is a sequence of octets; some parts of a packet  
containing part or all of an HTTP request or response happen to be  
text strings, but the link-layer, IP, and TCP headers are binary data,  
and even the payload of an HTTP request or response could be binary  
(depending on the transfer encoding).

> In packet No.132, packet No.133 and packet No.134, I couldn't see  
> the related info about them,
> even the Wireshark knows what HTTP responses look like, does it  
> imply some info in the strings?

It implies information in the raw packet data.

For example:

In your capture file, the TCP sequence numbers in the TCP headers  
indicate that the TCP payload in frame 133 comes right after the TCP  
payload in frame 132 (because the TCP sequence number in the TCP  
header in frame 132, plus the total number of TCP payload data bytes  
in frame 132, is equal to the TCP sequence number in the TCP header in  
frame 133), and that the TCP payload in frame 134 comes right after  
the TCP payload in frame 133.  (The total number of TCP payload data  
bytes in a frame is indicated by the packet length information in the  
IP header in that frame.)

This allows the TCP dissector to combine the TCP payload data from  
those three frames.

However, the TCP dissector doesn't know anything about HTTP, so it  
doesn't know *how much* TCP payload data to combine.  The HTTP  
dissector gets the TCP payload of frame 132 passed to it; it sees part  
of an HTTP response, but doesn't see all of an HTTP response, so it  
provides an indication to the TCP dissector that it should accumulate  
more data.  Then, with frame 133, the TCP dissector adds the payload  
from that frame to the payload from frame 132, and hands the combined  
payload to the HTTP dissector; it sees that it got more of the  
response, but that it still doesn't have all of the response, so it  
again indicates to the TCP dissector that it needs more data.  With  
frame 134, the TCP dissector adds the payload from *that* frame to the  
combined payload of frames 132 and 133, and hands that combination to  
the HTTP dissector, which now sees a complete HTTP response, and  
dissects it.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe