Started this on the Users mailing list, but this now an issue for the Dev list.
I see two solutions:
A. make sure tcp feeds xot and thereby x25 only packets in order.
+ minor changes to xot/x25, could help other dissectors
- will not present info for packets out-of-order
- no natural implementation in TCP as I see it
- no information for packets out of order
B. Let xot "peek" into x25 and request complete x25 packet sequences
+ only changes to x25/xot
+ possible solution
- all affected protocols need separate implementations
- do not like to mix layers and let xot know about x25
Will probably start working on solution B unless someone has a better idea)
(and for the xot weirness I mentioned, this is a bug for heuristic
dissectors and the tcp dissector. Put a solution in
Bug 2103 TCP dissector fail to handle heuristic dissectors for mult
segments (XOT).)
Gerhard
On Dec 12, 2007 2:16 PM, Gerhard Olsson <gerhard.nospam@xxxxxxxxx> wrote:
> Applications using i.e. TCP expects to get the data in a stream.
> However, Wireshark may not see the data in the correct order and tries
> to present data as they arrive.
> I have not found out how it is supposed to work: Is the "stream" or
> the packets as they arrive supposed to be sent to next level?
>
> It seems like packets are presented as they arrive. I have opened
> http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2091 to handle a
> problem presenting X25. There it seems as as packets are presented as
> they arrive. An example, where X25 is transported in
> XOT-TCP-IP-Ethernet
> e1. X25 packet x3 is received, with More bit set [presented OK]
> e2. X25 packet x4 is received, with M=0 [presented OK, reassembly to
> next level]
> e3. TCP retransmit of packet e1 (M=1) [NOK, see below]
> e4. X25 packet x5 M=0 [NOK]
>
> Wireshark assumes that packet x3 is preceding packet x5 so Wireshark
> presents packet e4 as a resembled X25 packet using e3-e4 (x3,x5) which
> is not correct. This information is also forwarded to upper layers so
> upper layers fail.
>
> Is this a problem in X25 only or a general problem?
> X25 uses the reassembly library, but that will only work if the
> packets arrive in order. I see no way to make a safe reassembly in X25
> dissector when the TCP info is gone.
> I am working on a hack that ignores reassembling packets that arrive
> out of order, but that creates other problems.
> There seems to be some problems in xot as well with xot headers
> spanning several IP packets, but that is not yet investigated (the xot
> dissector is very simple though, I doubt the packet is there).
>
> I use primary Wireshark in Solaris, tested this with 0.99.5 and svn as
> of yesterday. Some runs in Windows 0.99.6 and 0.99.7.pre2 as well.
>
>
> Any hints like a "reference implementation" to compare xot/x25 with?
>
> --
> Gerhard
>
