[bugzilla-daemon@xxxxxxxxxxxxx]

Pascal Quantin changed bug 9381

What	Removed	Added
CC		pascal.quantin@gmail.com

Comment # 2 on bug 9381 from Pascal Quantin

Hi Deepak,

I guess what you see is due to the fact that TCP reassembly for HTTP body is
based on Content-length value. See the HTTP dissector option description:
Reassemble HTTP bodies spanning multiple TCP segments: Whether the HTTP
dissector should use the "Content-length:" value, if present, to reassemble the
body of a request spanning multiple TCP segments, and reassemble chunked data
spanning multiple TCP segments. To use this option, you must also enable "Allow
subdissectors to reassemble TCP streams" in the TCP protocol settings.

So TCP reassembly just take the first 5 bytes, which matches the reassembly
info:

5 Reassembled TCP Segments (65 bytes): #10(16), #12(18), #14(25), #16(1),
#18(5)
  Frame: 10, payload: 0-15 (16 bytes)
  Frame: 12, payload: 16-33 (18 bytes)
  Frame: 14, payload: 34-58 (25 bytes)
  Frame: 16, payload: 59-59 (1 byte)
  Frame: 18, payload: 60-64 (5 bytes)
  Segment count: 5
  Reassembled TCP length: 65
  Reassembled TCP Data: 485454502f312e3120323030204f4b0a436f6e74656e742d...

In this context, tvb_reported_length_remaining() reports the remaining length
for the reassembled segment, not from the original packet, so the behavior
seems OK to me (unless I missed something).
What you watn to achieve would require a rework of
req_resp_hdrs_do_reassembly() and is not related to a bug in
tvb_reported_length_remaining() IMHO.

---

      You are receiving this mail because:

• You are watching all bug changes.