On 04/26/2009 10:33 PM, Sake Blok wrote:
On Sun, Apr 26, 2009 at 10:13:30PM +1000, Martin Visser wrote:
On Sun, Apr 26, 2009 at 7:50 PM, Matthieu Patou
<mat+Informatique.Wireshark@xxxxxxxxx> wrote:
Some of the dissected protocols for instance HTTP also allow you to
have visibility of the whole object, as long it is complete, even if
it is made up of out of order or duplicate packets.
My protocol (LDAP with SASL) is able to cope with this out of order
packets, but wireshark not and that's particulary bad when you have
encrypted data with rc4 (like it's my case) because as you are not able
to decode it and due to this you lose the synchronisation with the
(de)cipher and you are not able to decode subsequent LDAP request as
well (well until the caller unbind and restart a new bind).
Which is true for every packet *except* the first packet of a PDU. If
that packet is received out-of-order, Wireshark is not able to dissect
that PDU as it is fed with faulty information.
This is the case I believe Matthieu was refering to :
In fact it's not the second one before the first one but the forth ....
reorder packets (ie. if you have sequence 1341 before sequence 1 then
you're caught).
I was looking at the TCP dissector this afternoon to see how easy it
would be to park a packet in the defragmentation queue when a previous
packet has been lost (due to out-of-order) and a new PDU was expected.
This should solve the issue (unless the packet was not out-of-order, but
really lost).
Unfortunately I was not yet able to find a way to do that. If anyone has
an idea, feel free :-)
Sake I don't know in the general case but in my case I've got a packet x
saying next sequence xxx and unfortunately next packet in the same
direction with the same port (source and dest) has the sequence yyy.
Then we can decide to park it and do so for every packet before finding
the one with sequence xxx, then we put missing packet in places ...
Well it seems simple in a mail ...
As I read that this problem is quite rare maybe it's useless
Matthieu.
