http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1124
------- Comment #4 from jhoger@xxxxxxxxx 2006-09-28 22:25 GMT -------
Still looking at desegmentation of PDUs combined into a single TCP segment...
I've come to the conclusion that desegmentation by desegment_tcp that involves
at one point returing pinfo->desegment_len as shorter than the actual PDU
length in a previous packet so that you can get sufficient bytes to actually
measure the PDU when the next one comes simply doesn't work. Although your
dissector gets called once the initial estimate of PDU length is achieved, the
updated pinfo->desegment_len is ignored. It has nothing to do with
tcp_dissect_pdus.
If I'm right, then just about every module that depends on desegment_tcp (at
the very least those that depend on tcp_dissect_pdus) is broken under the
condition that minimal headers cross tcp packet boundaries. Where I run into
this case is with a slow client where the server buffers stuff up for a while.
Data gets chunked out in ~1500 byte increments when the window opens back up,
and so the packets get chopped up fairly randomly and often within the minimal
header.
All that said, I have a hack that I seems to work for me:
In tcp_dissect_pdus, if there are not sufficient bytes to determine the PDU
length I return a large number instead of the number of bytes remaining in the
minimal header. The other thing I had to do to make this work is that in
desegment_tcp, right after finding a matching msp, I changed the fragment_add()
to always pass more_frags as false. This forces that we always generate a
ipfd_head and offer the packet to the application level protocol dissector.
I doubt this is a proper solution to the problem however so I'm going to leave
this bug open.
--
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.