http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1200
------- Comment #7 from ronniesahlberg@xxxxxxxxx 2006-11-07 10:20 GMT -------
ah. ok. I did those changed that broke this but it was a bugfix. really!The
change that causes this is in packet-tcp.c Previously, before part of the
rewrite of tcp reassembly there was actually a bug in the tcp reassembly
routines.The bug was that when reassembling a TCP the reassembly would always
add the entire tcp segment to reassembly even if only part of the segment was
required.This caused reassembly to break for some scenarios where the PDUs were
completely unaligned to the tcp segment boundaries and for example when the
first x bytes contained the tail of a previous PDU being reassembled and the
last x bytes of the segment contained the start of a new PDU that also needed
to be reassembled.When the reassembly code was redone this bug was fixed so
that when reassembly only needed x bytes from the next segment, it would only
get x bytes. And the rest of the segment would be dissected and handled as
normal.This worked really well and solved some previous failures to do correct
reassembly.However, HTTP is a bit special. HTTP when doing reassembly does not
use tcp_dissect_pdus() and instead does its own reassembly signalling. (or
rather req_resp_hdrs.c does)The HTTP dissector when doing reassembly does this
by asking most of the time for just a single byte at a time.With the old
buggy code this didnt matter, the tcp reassembly code would ignore the 1 byte
requested and reassemble the entire segment anyway so this suboptimal
behaviour in http did not show up.I.e. the HTTP reassembly bug/suboptimality
and the tcp reassembly bug went hand in hand and cancelled eachother
out.However now with the fixed tcp reassembly code, this causes a real issue
for HTTP.Reassembling a large HTTP packet one byte at a time is suboptimal and
will be slow.The issue needs more study but should be resolved in HTTP and not
TCP imho.The solution could be to try to use tcp_dissect_pdus() whenever
possible in HTTP (if we have a content-length) or to teach the tcp reassembly
about "DESEGMENT_ONE_MORE_SEGMENT" and implement this in tcp reassembly and at
the same time refactor the http dissector to always ask for this many bytes of
reassembly and not just one byte at a time.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.