Wireshark-bugs: [Wireshark-bugs] [Bug 9381] HTTP reassembly fails if Content-Length header is wr
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Wed, 06 Nov 2013 21:53:53 +0000

Comment # 4 on bug 9381 from 
It looks like the change works if the HTTP headers and the extra data all come
in the same packet.  For example, on a large capture file, I found these
mismatches:

Errors (23267)
=============
   Frequency      Group           Protocol  Summary
       23260   Checksum               IPv4  Bad checksum
           3  Malformed               HTTP  Actual length 663 greater than
Content-Length header value 358, using header value
           2  Malformed               HTTP  Actual length 470 greater than
Content-Length header value 160, using header value
           2  Malformed              UASIP  Malformed Packet (Exception
occurred)

In each of the 5 error cases, the entire HTTP response was in one packet.  I
will try to simulate this and update a trace file.

So the check fails if there is extra data and that is coming in a separate
packet.

The printfs showed that the variables were as expected:

reported_datalen: 663, content_length: 358

Pascal, I did not understand this statement: "reports the remaining length for
the reassembled segment, not from the original packet".  I will check the code
you mentioned.  But note the above "partially working" case.

Evan, I am OK with truncating reassembly to advertised "Content Length" - this
is the current approach taken by packet-http.c.  I only want a warning in the
Expert-Info that this happened on response starting at packet N.  As you can
see above, it works with my patch (on 1.8.2), but only sometimes.

You are receiving this mail because:
  • You are watching all bug changes.