Wireshark · Wireshark-users: Re: [Wireshark-users] Out of sequence packets

["Alan Jay Weiner" <a.weiner@xxxxxxxxxx>]

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.
>
___________________________________________________________________________
> 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
> 
>
___________________________________________________________________________
> 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

___________________________________________________________________________
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