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

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