Ask Your Question
0

Time Display Format

asked 2023-05-10 19:05:59 +0000

I've captured some pings between two computers and sorted them by "Src addr" with the time display precision set to "Microseconds" and we see:

30  2023-05-10 11:16:41.028043  192.168.1.101       192.168.1.1         ICMP    98  Echo (ping) request  id=0x001d, seq=1/256, ttl=64 (reply in 31)
46  2023-05-10 11:16:42.030052  192.168.1.101       192.168.1.1         ICMP    98  Echo (ping) request  id=0x001d, seq=2/512, ttl=64 (reply in 47)

So the time between item 30 and 46 is 1.0049622 seconds. If I then change the Time Display Format using "Menu -> View -> Time Display Format -> Seconds Since Previous Displayed Packet" I expect time Time column for No. 46 to display 1.002009 it doesn't, it displays 0.086390:

30  0.492581    192.168.1.101       192.168.1.1         ICMP    98  Echo (ping) request  id=0x001d, seq=1/256, ttl=64 (reply in 31)
46  0.086390    192.168.1.101       192.168.1.1         ICMP    98  Echo (ping) request  id=0x001d, seq=2/512, ttl=64 (reply in 47)

And 0.086390 is the time between No. 45 and 46 i.e. "Seconds Since Previous Captured Packet":

45  0.007271    fe80::ba27:ebff:fe73:ae23       ff02::16            ICMPv6  110 Multicast Listener Report Message v2
46  0.086390    192.168.1.101       192.168.1.1         ICMP    98  Echo (ping) request  id=0x001d, seq=2/512, ttl=64 (reply in 47)

So this appears to be a bug in Wireshark, should I file a bug report or am I mistaken on what "Seconds Since Previous Displayed Packet" should do?

Here is the Wireshark version info from the "About" dialog box:

Version 4.0.5 (Git v4.0.5 packaged as 4.0.5-1).
Copyright 1998-2023 Gerald Combs <[email protected]> and contributors.

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Compiled (64-bit) using GCC 12.2.1 20230201, with GLib 2.76.1, with PCRE2, with zlib 1.2.13, with Qt 5.15.9, with libpcap, with POSIX capabilities (Linux), with libnl 3, with Lua 5.2.4, with GnuTLS 3.8.0 and PKCS #11 support, with Gcrypt 1.10.2-unknown, with Kerberos (MIT), with MaxMind, with nghttp2 1.52.0, with brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.10.3, without libsmi, with QtMultimedia, without automatic updates, with SpeexDSP (using system library), with Minizip, with binary plugins. 

Running on Linux 6.3.1-arch1-1, with AMD Ryzen 9 3900X 12-Core Processor (with SSE4.2), with ...
(more)
edit retag flag offensive close merge delete

Comments

(Git v4.0.5 packaged as 4.0.5-1)

...

Running on Linux ...

Is this a version of Wireshark provided by your Linux distribution? If so, what version, of what distribution, is that?

Guy Harris gravatar imageGuy Harris ( 2023-05-11 05:20:43 +0000 )edit

Yes I'm running a recently updated Arch Linux and the kernel is 6.3.1.

winksaville gravatar imagewinksaville ( 2023-05-11 21:18:53 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2023-05-12 02:08:52 +0000

Jim Young gravatar image

The notion of "Seconds Since Previous Displayed Packet" is based on the order of the frames in the capture file and differs from "Seconds Since Previous Captured Packet" only when packets are filtered. This value is not affected by sort order.

In your original example if you apply a display filter of ip.src == 192.168.1.101 you should see the expected value of 1.002009 between frames 30 and 46 regardless of what column you sort the filtered packets on.

Without filtering, to see the elapsed time between two arbitrary packets you can switch the time format to "Seconds Since First Captured Packet" and then use the Edit -> Set/Unset Time Reference menu option to set *REF* on frame 30 to read the desired elapsed time to frame 46.

edit flag offensive delete link more

Comments

Thanks for the explanation, but it is not obvious and in the docs I read I didn't see that, of course that could be my problem. Personally, To me this feels like a bug, in your opinion should I create an issue?

winksaville gravatar imagewinksaville ( 2023-05-13 04:05:59 +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: 2023-05-10 19:05:59 +0000

Seen: 224 times

Last updated: May 12 '23