Ask Your Question
0

Frame number & Frame time & Frame.time_delta

asked 2021-08-02 02:46:58 +0000

7ACE gravatar image

hello,

How is the frame number defined in wireshark? Is the packet number based on the order in which the packets appear in the capture file?

Is the frame timestamp added by WinPcap/Npcap/Libpcap?

So why would frame.time_delta be negative in some cases?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2021-08-02 06:07:39 +0000

Guy Harris gravatar image

How is the frame number defined in wireshark? Is the packet number based on the order in which the packets appear in the capture file?

Yes.

Is the frame timestamp added by WinPcap/Npcap/Libpcap?

Libpcap (including the libpcap component of WinPcap/Npcap) uses a mechanism in the OS kernel to capture packets. (On UN*Xes, the OS itself provides the mechanism; on Windows, WinPcap and Npcap also provide a driver that runs in the OS kernel, atop the NDIS mechanism provided by Windows, to grab packets and provide them to libpcap.)

On all but some platforms (HP-UX, for example), the kernel mechanism supplies time stamps, which libpcap provides to the program using it. (On HP-UX, libpcap has to make a separate system call to get the current time.)

So why would frame.time_delta be negative in some cases?

For one thing, either the time stamp mechanism in the OS kernel could go backwards if the system time is explicitly changed, or the mechanism providing packets to libpcap could do so in an order other than strict time order.

At least on a multiprocessor machine (including a multi-core machine, i.e. "chip multiprocessing"), if a single CPU doesn't handle all packet arrivals from a given network adapter, two packets A and B, with B arriving at the network adapter after A, could be processed by two different CPUs, and packet A could get delayed enough that the CPU processing packet B could put it in a packet queue before the CPU processing packet A does; if the two packets were time stamped before that, this could result in packets being out of time stamp order in the queue, and being provided to libpcap out of time stamp order.

(At least at one point this did happen on occasion on Linux. That was a while ago, so that might have been cleaned up since then. As I remember, that happened back when multiprocessor machines were exotic high-end workstations and servers, rather than smartwatches.)

If this is a significant problem on some platform, libpcap could be changed to queue up packets for a short period of time, and deliver them "out of order" - i.e., in an order other than the one in which the OS kernel provided them to libpcap - if the kernel provided them out of time stamp order.

edit flag offensive delete link more

Comments

Thank you so much for your clear explanation!

7ACE gravatar image7ACE ( 2021-08-02 07:04:09 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2021-08-02 02:46:58 +0000

Seen: 5,354 times

Last updated: Aug 02 '21