On Mon, Apr 12, 2004 at 12:40:46PM +0000, Sid Sid wrote:
> So I think we should leave presentation dissector as is and modify ACSE
> dissector for calling MMS dissector.
> Guy, should I send it as patch ?
Yes, although, ideally, the ACSE dissector should perhaps have a
string-based dissector table for the OID of the protocol using ACSE, so
that dissectors for those protocols can just register in the dissector
table, rather than having the ACSE dissector have a hard-wired
association of OIDs with dissectors.
> Regarding dissegmentation problem - I'm scrutinizing it right now.
> As far as I can see problem is in CLNP/COTP dissector.I can't say where
> right now but I'm working.
The problem is that the COTP reassembly code, in effect, assumes that the
TPDU number for the first segment of a segmented TPDU has a TPDU number
of 0, the next one has a TPDU number of 1, and so on.
TP0 is what's used atop TPKT (as TCP takes care of all packet drops,
out-of-sequence delivery, checksumming, etc.); I don't see anything
immediately obvious to indicate what should be done about the TPDU
numbers (which aren't used for TP0), but it appears that the
implementation being used in the capture in question uses 0 for all
TPDUs.
This means that TPDU reassembly won't work.
(It also won't work for TP1, TP2, TP3, or TP4, because, in those
classes, the sequence number starts at 0 in the first DT TPDU but
increases for each DT TPDU in the connection - it doesn't get reset for
each segmented TPDU to start at 0.)
The COTP dissector should perhaps, for now, use
"fragment_add_seq_next()" rather than "fragment_add_seq_check()"; this
won't work with out-of-order TPDUs or retransmissions, but in the normal
case it should work. (We ultimately probably need a form of reassembly
that actually uses the sequence number the way it should be used for
transport protocol sequence numbers, and should use that, which should
be able to handle at least some retransmissions and out-of-order TPDUs.)
