Home page logo
/

wireshark logo Wireshark mailing list archives

Re: [WARNING - NOT VIRUS SCANNED] Negative delta with UDP / SIP conversation
From: M Holt <m.iostreams () gmail com>
Date: Thu, 20 Jun 2013 14:20:48 -0700

Guy,

That makes sense -- I didn't even consider the multicore issue.  That's
exactly the problem that's occuring.

Pascal,

Awesome tool!  I wasn't aware of that!

Thanks to both of you!

 -- Mike


On Thu, Jun 20, 2013 at 2:14 PM, Pascal Quantin <pascal.quantin () gmail com>wrote:

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

___________________________________________________________________________
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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]