[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

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