On Fri, Apr 16, 2004 at 12:22:45PM -0700, Guy Harris wrote:
> Herbert Falk said:
> > Thus, except for out-of-sequence packets, I believe for TP2-TP4 the
> > current code is OK.
>
> I have captures on which it fails, and so does Yuriy. It would be
> correctly only if, for all segmented TPn packets, the first segment has a
> sequence number of 0, the second segment has a sequence number of 1, and
> so on - which is not the case, because that sequence number is a
> transport-layer sequence number for the whole connection.
>
> > If TRUE, then I would suggest creating a TP0 dissector function module
> > (basically a duplicate of the current COTP dissector) but using
> >
> > "fragment_add_seq_next()"
>
> No, just change the COTP code to *ALWAYS* use "fragment_add_seq_next()".
> and use it for TP0 through TP4.
>
> That'd be correct for TP0; it would be incorrect for transport layers
> where the sequence number is significant, but, as out-of-order delivery or
> dropped packets are probably rare, it'd probably be *less* incorrect than
> the current code! (NetBIOS-over-802.2 reassembly has the same problem -
> it just uses "fragment_add_seq_next()", but packets *could* be sent out of
> order, or dropped.)
I've checked in a change to make the COTP dissector use
"fragment_add_seq_next()" for reassembly - for TP0 through TP4. This
fixes misreassembly with some non-TP0 captures, so doing so for all
transport layers, not just TP0, is the right thing to do.