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

Ethereal-dev: Re: [Ethereal-dev] Need help with protocol that spans multiple TVBs

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Sid Sid" <ysidelnikov@xxxxxxxxxxx>
Date: Fri, 16 Jul 2004 10:05:35 +0000
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).

Thank you.

From: Guy Harris <gharris@xxxxxxxxx>
Reply-To: Ethereal development <ethereal-dev@xxxxxxxxxxxx>
To: Ethereal development <ethereal-dev@xxxxxxxxxxxx>
CC: ysidelnikov@xxxxxxxxxxx
Subject: Re: [Ethereal-dev] Need help with protocol that spans multiple TVBs
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 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.

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus