I've checked several kind of captured files(CMIP,FTAM,MMS on CLNP/RFC1006) -
COTP dissector is assembling fragmented pdu very well(Probably, because I
haven't file with retransmitting).
From: Guy Harris <[email protected]>
Reply-To: Ethereal development <[email protected]>
To: Ethereal development <[email protected]>
CC: [email protected]
Subject: Re: [Ethereal-dev] Need help with protocol that spans multiple
Date: Sat, 19 Jun 2004 18:26:32 -0700
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
> 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
> dropped packets are probably rare, it'd probably be *less* incorrect
> 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
> 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.
Ethereal-dev mailing list
MSN 8 with e-mail virus protection service: 2 months FREE*