Wireshark · Wireshark-users: [Wireshark-users] Filtering on (negated) frame.time_relative filters out wrong frame.number

[Miroslav Rovis <miro.rovis@xxxxxxxxxxxxxxxxx>]

Hi!

I checked the:

https://bugs.wireshark.org/bugzilla/buglist.cgi?quicksearch=frame.time_relative

and I got:

"From there to here,
from here to there,
funny things
are everywhere."
  — Dr. Seuss

"Except your bug.
It is not here.
It is not there!
Oh dear! OH DEAR!"
  — Bugzilla

So maybe it's a good thing to try and explain what issue I have.

I like to prepare traces (and other stuff) when I have issues. Pretty
often it's been stuff like login issues to forums and similar. In which
case what's most needed is get the packet with the password cut out from
the trace before publishing, obviously.

The version:

$ wireshark --version
Wireshark 2.2.5 (wireshark-2.2.5)

Copyright 1998-2017 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with Qt 5.7.1, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with GLib 2.50.3, with zlib 1.2.11, with SMI 0.5.0, without
c-ares, with Lua 5.1.5, with GnuTLS 3.5.10, with Gcrypt 1.7.6, without Kerberos,
without GeoIP, with QtMultimedia, without AirPcap.

Running on Linux 4.9.13-hardened-r1-170310_23, with locale en_GB.utf8, with
libpcap version 1.8.1, with GnuTLS 3.5.10, with Gcrypt 1.7.6, with zlib 1.2.11.
AMD Phenom(tm) II X4 965 Processor

Built using gcc 5.4.0.
$ 

And downgrading to 2.2.4 didn't chase the issue away. The repeated test
below I'll do with 2.2.4.

Either Wireshark or Tshark, issue is (almost always with Wireshark,
always with Tshark) reproducible here. [1]

On this trace [2]:
dump_170316_1529_g0n.pcap (for obvious reasons not yet published)
, that I need to take away the packets (two of them) containing
password, I put this filter into the filter track:

((!(frame.time_relative == 159.123717557)) && (!(frame.time_relative == 188.863380487)))
because upon perusing the trace, I saw that password containing packets
were:
1310 and 1484

The same in Tshark (which I'm going to repeat the test for the purpose
of reporting what *could* be a bug:

$ mv -iv dump_170316_1529_g0n.pcap \
    dump_170316_1529_g0n.pcap.O       # because I'll eventually publish
                                      # not the original (".O"), but the
                                      # trace without the password

The dump_170316_1529_g0n_SSLKEYLOGFILE.txt below contains just the keys for
the trace.
$ tshark -o "ssl.keylog_file: dump_170316_1529_g0n_SSLKEYLOGFILE.txt" -r \
    dump_170316_1529_g0n.pcap.O  -Y \
    '(!(frame.time_relative == 159.123717557))&&(!(frame.time_relative == 188.863380487))' \
    -w dump_170316_1529_g0n.pcap

( The same can be gotten by "Export Specified Packets" in Wireshark,
after enabling that filter. )

I'll right now execute the commands above.

Did it. I have these files now:

$ ls -l dump_170316_1529_g0n.pcap.O dump_170316_1529_g0n.pcap
-rw-r--r-- 1 miro miro 1107724 2017-03-16 23:04 dump_170316_1529_g0n.pcap
-rw-r--r-- 1 miro miro 1109492 2017-03-16 15:35 dump_170316_1529_g0n.pcap.O
$

Let's see first what (just one of the two frames above) contains:

$ tshark -o "ssl.keylog_file: dump_170316_1529_g0n_SSLKEYLOGFILE.txt" -r \
    dump_170316_1529_g0n.pcap.O -V -Y \
    '(frame.time_relative == 159.123717557)' \
    > dump_170316_1529_g0n.pcap.O_frame.time_relative_159.123717557
$ cat dump_170316_1529_g0n.pcap.O_frame.time_relative_159.123717557 | \
    sed 's/xxxxxxxxxx/mypassword/g' \
    > dump_170316_1529_g0n.pcap.O_frame.time_relative_159.123717557r # r=real
                                                         # (just my renaming
                                                         # scheme)
$ mv -iv  dump_170316_1529_g0n.pcap.O_frame.time_relative_159.123717557r \
    dump_170316_1529_g0n.pcap.O_frame.time_relative_159.123717557

Pls. find it gzip'd in is own attachment.

But it starts like this:

Frame 1310: 826 bytes on wire (6608 bits), 826 bytes captured (6608 bits) on interface 0
    Interface id: 0 (any)
    Encapsulation type: Linux cooked-mode capture (25)
    Arrival Time: Mar 16, 2017 15:32:01.682004988 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1489674721.682004988 seconds
    [Time delta from previous captured frame: 1.090888249 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 159.123717557 seconds]

And it ends like this:

    Form item: "user[password]" = "mypassword"
        Key: user[password]
        Value: mypassword
    Form item: "user[password_confirmation]" = "mypassword"
        Key: user[password_confirmation]
        Value: mypassword

which is all correct so far.

In the newly made PCAP:

$ tshark -o "ssl.keylog_file: dump_170316_1529_g0n_SSLKEYLOGFILE.txt" \
    -r dump_170316_1529_g0n.pcap -V -Y \
    '(frame.time_relative == 159.123717557)'
$
( empty string)

that frame.time_relative is not to be found. But what does frame,
hmmmh... let me see... let me see... The same 1310 frame.number it is!

But what does '(frame.number == 1310)' contain?

$ tshark -o "ssl.keylog_file: dump_170316_1529_g0n_SSLKEYLOGFILE.txt" \
    -r dump_170316_1529_g0n.pcap -V -Y '(frame.number == 1310)' \
    > dump_170316_1529_g0n.pcap_frame.number_1310
$ cat dump_170316_1529_g0n.pcap_frame.number_1310 \
    | sed 's/xxxxxxxxxx/mypassword/g' \
    > dump_170316_1529_g0n.pcap_frame.number_1310r
$ mv -iv dump_170316_1529_g0n.pcap_frame.number_1310r \
    dump_170316_1529_g0n.pcap_frame.number_1310

Pls. find it gzip'd in is own attachment.

But it starts like this:

Frame 1310: 826 bytes on wire (6608 bits), 826 bytes captured (6608 bits) on interface 0
    Interface id: 0 (any)
    Encapsulation type: Linux cooked-mode capture (25)
    Arrival Time: Mar 16, 2017 15:32:01.682039650 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1489674721.682039650 seconds
    [Time delta from previous captured frame: 1.090922911 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 159.123752219 seconds]

which looks (and maybe isn't) all correct but only for the start, I'm afraid.

Because it ends like this:

    Form item: "user[password]" = "mypassword"
        Key: user[password]
        Value: mypassword
    Form item: "user[password_confirmation]" = "mypassword"
        Key: user[password_confirmation]
        Value: mypassword

Indeed, the diff shows it's the same packet!

$ diff -u dump_170316_1529_g0n.pcap.O_frame.time_relative_159.123717557 \
    dump_170316_1529_g0n.pcap_frame.number_1310
--- dump_170316_1529_g0n.pcap.O_frame.time_relative_159.123717557    2017-03-16 23:09:22.254289694 +0100
+++ dump_170316_1529_g0n.pcap_frame.number_1310    2017-03-16 23:24:17.111209568 +0100
@@ -1,12 +1,12 @@
 Frame 1310: 826 bytes on wire (6608 bits), 826 bytes captured (6608 bits) on interface 0
     Interface id: 0 (any)
     Encapsulation type: Linux cooked-mode capture (25)
-    Arrival Time: Mar 16, 2017 15:32:01.682004988 CET
+    Arrival Time: Mar 16, 2017 15:32:01.682039650 CET
     [Time shift for this packet: 0.000000000 seconds]
-    Epoch Time: 1489674721.682004988 seconds
-    [Time delta from previous captured frame: 1.090888249 seconds]
+    Epoch Time: 1489674721.682039650 seconds
+    [Time delta from previous captured frame: 1.090922911 seconds]
     [Time delta from previous displayed frame: 0.000000000 seconds]
-    [Time since reference or first frame: 159.123717557 seconds]
+    [Time since reference or first frame: 159.123752219 seconds]
     Frame Number: 1310
     Frame Length: 826 bytes (6608 bits)
     Capture Length: 826 bytes (6608 bits)
$

Of course, not being an expert in these matters, I'm not claiming it's
and issue with Wireshark... Even though it looks like it is, to me...

...I've always been able to cut out password containing frames like
this...  But not with these (relatively) latest versions...

So what could this be?

Regards!

( Pls. allow possible errata in a later email. )

---
[1] I'm a little unwell, also busy with other stuff, I'll try and do
more if necessary, but can't promise.

[2] It seems I can't cut out packets with precision anymore, yet... The
trace in question will be at:
http://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/
( non-existent link at the time of posting this email to Wireshark ML )
but maybe not exactly within hours... Don't know how soon...
You can look up (the later dirs might be worth of newbie readers' time)
other stuff at
http://www.croatiafidelis.hr/foss/cap/
in the meantime.

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr

Attachment: dump_170316_1529_g0n.pcap.O_frame.time_relative_159.123717557.gz
Description: Binary data

Attachment: dump_170316_1529_g0n.pcap_frame.number_1310.gz
Description: Binary data

Attachment: signature.asc
Description: Digital signature