> As I read that this problem is quite rare maybe it's useless
Even though it might be a rare occurrence, the original poster is seeing it;
evidence that the case can occur in real life. As Wireshark is test
equipment, I argue that it *should* handle such cases.
My personal feeling is that Wireshark could/should be configurable - a
setting to configure how large a buffer is allocated for holding
out-of-sequence packets; i.e., how late the first packet may be in order to
still put everything together.
That said, I realize it's easy to create work for someone else; since I'm
not jumping up to do the work my opinion carries less weight.
(btw, I make the same argument about our own products; as test equipment we
should handle (and/or be able to generate) every odd, bad, messed-up,
whatever... :)
- Al Weiner -
----------------------------------------------------------------------------
Alan Jay Weiner / Valid8.com, Inc. - Conform, Perform & Excel(tm)
500 W Cummings Park, Suite #2700, Woburn, MA 01801, USA
a.weiner@xxxxxxxxxx / Tel:+1-781-938-1221 x112, Fax +1-781-207-0550
http://www.VALID8.com
-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Matthieu Patou
Sent: Sunday, April 26, 2009 4:49 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Out of sequence packets
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.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
