Re: [WARNING - NOT VIRUS SCANNED] Negative delta with UDP / SIP conversation

[Pascal Quantin <pascal.quantin () gmail com>]

2013/6/20 Guy Harris <guy () alum mit edu>

> On Jun 20, 2013, at 1:48 PM, M Holt <m.iostreams () gmail com> wrote:
>
> > In my attached capture, there are 8 packets which were filtered based on
> Call-ID.  Packet number 2 should be the beginning of the conversation,
> based on the little diagram above, but Wireshark is displaying this packet
> as number 2, even though it has a negative delta from packet 1.
> > Based on this, I have two questions:
> >
> >  1.  How does frame data get populated?  In other words, how does
> Wireshark know that frame 10, is not frame 9?  Previously, I had thought
> this was always based on time, but that is clearly not the case.
>
> It's based on the order in the capture file.  Frame N is the Nth packet in
> the capture file.
>
> >  2. In this specific example, what is causing Wireshark to re-order
> packets?
>
> Presumably you mean "what is causing Wireshark *not* to re-order packets?"
>
> Wireshark shows packets in the order to which they're written to the
> capture file; for a live Wireshark capture, that's the order in which
> libpcap/WinPcap delivers them to dumpcap, which is, in turn, the order in
> which the OS's underlying packet capture mechanism, whatever that might be,
> delivers them to libpcap (on UN*X) or the order in which Windows's NDIS
> delivers them to the WinPcap driver (on Windows).
>
> So the packets are out of order in the capture file; if you captured this
> with Wireshark (or some other tool using libpcap/WinPcap), the underlying
> packet capture mechanism delivered them out of order.
>
> Did you capture it on a multicore (multiprocessor) system running Linux?
>  At least some versions of Linux would cheerfully deliver packets to a
> socket, including a PF_PACKET socket (that being the "underlying packet
> capture mechanism" on Linux), out of strict time order (I suspect one
> packet was being processed by one core and another packet was being
> processed by another core, and the one that processed the later-arriving
> packet managed to finish, by queueing up the packet, sooner).

Hi,

I have nothing more to add to Guy's really good explanation. But if you are
using Wireshark 1.10.0, be aware that it comes bundled with a small utility
(found in the installation folder) allowing you to reorder a capture file
according to the packets timestamp. Simply do:
reordercap sip.dmp sip_reordered.dmp

Best regards,
Pascal.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe