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 the bug
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1124 open.
Thanks,
-- John.
