Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: [Wireshark-dev] tcp_dissect_pdus

From: "John R." <jhoger@xxxxxxxxx>
Date: Wed, 6 Sep 2006 15:48:55 -0700
I have an issue with desegmentation of packets: if the minimal header
required to judge length is broken across TCP segments A and B, at
segment A it decides properly to return expecting the remainder of the
minimal header. In my problem case, the next tcp segment to arrive has
the remainder of this packet and several others. It calls my pdu
measurement routine which through printf's I've determined is properly
returning the length of the full PDU.

But at this point, based on printf's tcp_dissect_pdus thinks the
length_remaining is 5 (the length of my minimal header), but based on
the packet display I would expect it to have many more bytes. Anyway
it sets up pinfo desegment offset, len expecting the remainder of the
packet. But it never attempts to dissect this 5 bytes. Instead the
next time tcp_dissect_pdus is called it proceeds to dissect the rest
of segment B as if the 5 bytes after the 5 byte header are a header
when they are actually payload.

Once segment B appears should tcp_dissect_pdus stay in the dissect
loop until all packets within it are decoded? Or is it okay for
tcp_dissect_pdus to return here?

How do the length variables within the tvb get set up? I guess that
the problem is that somehow the tvb contains wrong length values in
this case so length_remaining is calculated wrongly and
tcp_dissect_pdus returns without processing the now complete packet.

What function calls my outer dissector that calls tcp_dissect_pdus?
Maybe I can look there next. I am working with a proprietary plugin,
but at this point I have tracked the problem down to general wireshark
code. My pdu length measurement routine is definitely correct: it does
use the "offset" value passed into it, and I have printf'd the value
so I know it is returning the right number in the problem case.

The problem does not appear to be in tcp_dissect_pdus itself, but in
the outer defragmentation engine.

One data point: not all cases where a pdu header is split across
segments exhibits this issue. But within a given trace, the cases
where it does occur is 100% repeatable (i.e. the misdissected packets
appear at the same point in a given trace every time).

-- John.