Guy Harris wrote:
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.
As I didn't know, where this settings of the srcport/destport fields are
used, I didn't wanted to screw up things.
But as you you now telling me this isn't used at all, I will comment out
this things at all places in packet-clnp.c,
... and add a comment about the reason why :-)
I just tried to remove the setting in the DT_TPDU (data transport
protocol data unit), which fixes the problem :-)
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...).
... will be an extremely annoying case to handle, if it should happen :-(
So it might be a good idea to have a "complete" implementation for this
conversation topic.
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).
I will ask my collegue to send me a somewhat more complete capture (I'm
sure he can send me one),
as the capture I currently have is only transporting user data
"DT_TPDU". A trace including connection establishing and disconnection
will be a lot more helpful for testing purposes :-)
Thanks a lot for the quick and detailed response :-)))
Regards, ULFL