Wireshark-users: Re: [Wireshark-users] Out of sequence packets
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Tue, 28 Apr 2009 19:14:52 +0200
Hello Alan,
I hear you, and indeed it's great that Wireshark can do that. Improving defragmentation is a Good Thing(sm), as long is it's not in the way of looking at the frames on the wire. 

Thanx,
Jaap

Alan Jay Weiner wrote:

Hi Jaap,
I see the design goal gap as you describe, but I disagree with your view of
'test equipment' and how it relates to Wireshark.

As I see it, Wireshark is most definitely 'test equipment' - one which
operates at the packet level (as you describe) but also is able to decode
higher protocol levels.  Indeed, that ability is one of its great strengths!

Wireshark is first and foremost a packet sniffer; nothing should interfere
with that.

However, Wireshark already goes much beyond simple packet capture, including
putting together fragmented TCP packets.  It just doesn't handle the case of
the first packet not being received first (the case the original poster is
seeing).  Improving the defragmenting logic - especially for TCP - seems
useful to me, even when it occurs infrequently.

- 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 Jaap Keuter
Sent: Monday, April 27, 2009 12:44 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Out of sequence packets

Hi,

I think you have to be very aware of the design goal of the application at
hand. Wireshark, as a packet sniffer, has the design goal of showing you the frames as they travel on the network medium. That is a very low level approach, well below eg. the TCP layer (I come back to that later).
As you describe a generic term 'test equipment' I see it as an end device application emulation, which, like the real end device of the observed communications, shows what the application communicates and how this is interpreted. You understand that this is a (very) high level approach to network communications, which sits on top of multiple complicated layers of communications software, eg IP and TCP. 

You see there's a gap between the two described design goals. Indeed
Wireshark tries to provide some of the features of your 'test equipment' but it is inherently hindered by the fact that it has to perform first and foremost at the network medium layer. It will therefore never be able to serve your goal as 'test equipment'. 

Note that this is true for all kinds of low level tools, like sniffers and
IDS. See how this has been identified as a fundamental problem and used by tools like SniffJoke: http://www.delirandom.net/sniffjoke/ 

Thanx,
Jaap


Alan Jay Weiner wrote:

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.