Wireshark-users: [Wireshark-users] Filtering on (negated) frame.time_relative filters out wrong f
From: Miroslav Rovis <miro.rovis@xxxxxxxxxxxxxxxxx>
Date: Thu, 16 Mar 2017 23:57:00 +0100
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
- Follow-Ups:
- Prev by Date: Re: [Wireshark-users] windows 10 / udp packet loss, off-topic ?
- Next by Date: Re: [Wireshark-users] FW: Wireshark 1.10.5
- Previous by thread: Re: [Wireshark-users] windows 10 / udp packet loss, off-topic ?
- Next by thread: Re: [Wireshark-users] Filtering on (negated) frame.time_relative filters out wrong frame.number
- Index(es):