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. _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
