Wireshark-users: [Wireshark-users] X25 reassembly when presenting out of order packets
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
