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.)
Powered by MHonArc 2.6.10