Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 3785] Some HTTP responses don't decode with TCP reassembly on

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3785

Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeff.morriss.ws@xxxxxxxxx

--- Comment #11 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2011-03-24 14:14:44 PDT ---
Hmmm, I don't think this patch is the correct fix.

In the case of the broken_http_response.pcap capture, there is no
content-length so we must DESEGMENT_UNTIL_FIN.  We do not want to stop
desegmenting just because we reached the end of the TVB.  This check:

~~~
    if (length_remaining < reported_length_remaining) {
           /*
            * It's a waste of time asking for more
            * data, because that data wasn't captured. 
            */
~~~

is (correctly) only checking for the case where we _know_ we do not have enough
data because the captured packet was cut short (due to snapshot length).  IOW,
if we change the test to <=, we will (in the common case where snapshots did
not truncate the packet) go into that case and never DESEGMENT_UNTIL_FIN.

I suppose what is confusing Wireshark here is that it wants to
DESEGMENT_UNTIL_FIN but there is no FIN captured (and I'm guessing Wireshark is
not smart enough to realize that it has reached the end of the capture file and
thus all the connections are (effectively) finished.  (If someone good at
building packets could build a FIN and append it to this capture, I bet it
would cause the HTTP to be dissected properly.)

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.