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 <[EMAIL PROTECTED]> 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 > _______________________________________________ Wireshark-users mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-users
