On Wed, Jan 28, 2004 at 08:59:03PM +0100, Ulf Lamping wrote:
> Just debugged a bit, points me to the following problem:
> ISO8073 packets are "usually" used on top of Ethernet II, not on top of
> TCP as in this special case. As this is true, the packet_info srcport
> and destport fields are used
> to carry the somewhat equally src_ref and dest_ref info from the ISO
> packets. This is ok when used with ISO8073 only (see packet_clnp.c line
> 872 for details).
>
> As the packets "making problems" are using TCP *and* ISO8073, we get a
> conflict here, as both protocols tries to use this port fields to store
> their info in.
>
> I'm not sure, what the storing of the src_ref / dest_ref fields is good
> for. This might be helpful for the conversation stuff, but I don't have
> much knowledge of this things.
That was added as part of a checkin that added support for COTP
reassembly, but the reassembly code doesn't use it.
(COTP reassembly doesn't work correctly, as the reassembly code can't
handle transport-layer reassembly when the sequence number is
connection-wide rather than being a sequence number within a fragmented
packet - and it also doesn't handle port numbers, as it doesn't even
look at them.
We probably need something similar to what is done for TCP reassembly,
for use by COTP - and, I think, NDPS, which runs atop SPX.)
I think a short term workaround would be to remove the stuff to set
"pinfo->srcport" and "pinfo->destport" in the COTP dissector.
In the long term, perhaps there should be, attached to the packet_info
structure, a stack of "potential conversations", giving addresses and
port numbers of both endpoints, and there should be menu items for:
filter conversation;
follow conversation;
where "filter conversation" would filter the display to show only
packets in that conversation and "follow conversation" would do a
"Follow TCP Stream" equivalent for the conversation (or perhaps only for
TCP conversations, for now) and possibly *not* filter the display (if I
just want to filter a conversation, the window popped up by "Follow TCP
Stream" is unnecessary, and people have complained about "Follow TCP
Stream" filtering the display).
The trick there is that the menu would have to handle *multiple*
conversations, as you might have more than one conversation (even more
than one TCP stream is possible, e.g. with
TCP-over-IP-over-X.25-over-TCP; admittedly, that's somewhat of a
perverse case, and probably an extremely unlikely case, but...).
> P.S: I can send an example capture file for this!
That might be useful for testing features such as the stuff I describe,
as well as for other testing (e.g., regression testing).