On Wed, Jan 28, 2004 at 08:59:03PM +0100, Ulf Lamping wrote:As I didn't know, where this settings of the srcport/destport fields are used, I didn't wanted to screw up things.
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.
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 :-)
... will be an extremely annoying case to handle, if it should happen :-(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...).
So it might be a good idea to have a "complete" implementation for this conversation topic.
I will ask my collegue to send me a somewhat more complete capture (I'm sure he can send me one),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).
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
_______________________________________________ Ethereal-dev mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-dev
