On Thu, Sep 11, 2003 at 07:33:55AM +0000, Sid Sid wrote:
> >No, frames 10, 12, 14, and 16 are the segments of a segmented PDU to
> >dst-ref 0x0001. Frame 8 is a non-segmented PDU to dst-ref 0x0101 (i.e.,
> >it's going in the other direction).
> >
> >The problem is that the reassembly code assumes that sequence numbers in a
> >segmented packet start at 0; unfortunately, the sequence numbers in COTP
> >are PDU numbers, and those are connection sequence numbers that increase
> >sequentially, so the first segment of a segmented PDU doesn't have a
> >sequence number that starts at 0.
> >
> >That will require more work in the reassembly code to fix.
> >
> Do you have a plan to fix it ?
> I guess it will be very useful because high level dissector can't show
> properly session data PDUs which are always segmented on COTP level. Only
> short one - connection request/confirm/refuse and so on.
> Pretty useless dissector, isn't ?
> I have a plan to develop dissectors for next levels - including
> association,ACSE,FTAM etc.
> I reckon it is imposible without good COTP reassembling.
I've checked in a change to the COTP dissector to make it assume that
COTP packets are in order and not to use the sequence number at all when
doing reassembly; that won't handle out-of-sequence packets correctly,
but it handles in-sequence reassembly a *lot* better, and probably
doesn't handle out-of-sequence reassembly much worse (the only time the
old code handled reassembly correctly at all was when the first segment
in the segmented TPDU had a sequence number of 0).
It fixes the reassembly problems with that capture, as well as with some
other captures that have been sent to the list.