Wireshark mailing list archives
Re: Filtering on (negated) frame.time_relative filters out wrong frame.number
From: Peter Wu <peter () lekensteyn nl>
Date: Fri, 17 Mar 2017 12:23:45 +0100
On Thu, Mar 16, 2017 at 11:57:00PM +0100, Miroslav Rovis wrote: [..]
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 () wireshark org> 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
Rather than dumping the tshark -V output, what about using File -> "Export PDUs to File"? Then you also strip the TLS layer (since redaction of the HTTP layer would otherwise be pretty useless when you have the TLS session secrets and the encrypted data). To filter out frames by number you can also use "not frame.number==1310 and not frame.number==1484". Can you try to prepare a smaller capture that can reproduce the issue which does not contain sensitive passwords? -- Kind regards, Peter Wu https://lekensteyn.nl ___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-users Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- Filtering on (negated) frame.time_relative filters out wrong frame.number Miroslav Rovis (Mar 16)
- Re: Filtering on (negated) frame.time_relative filters out wrong frame.number Peter Wu (Mar 17)
- Re: Filtering on (negated) frame.time_relative filters out wrong frame.number Graham Bloice (Mar 17)
- Re: Filtering on (negated) frame.time_relative filters out wrong frame.number Miroslav Rovis (Mar 17)
- Re: Filtering on (negated) frame.time_relative filters out wrong frame.number Miroslav Rovis (Mar 17)
- Re: Filtering on (negated) frame.time_relative filters out wrong frame.number Miroslav Rovis (Mar 18)
- Re: Filtering on (negated) frame.time_relative filters out wrong frame.number Graham Bloice (Mar 17)
- Re: Filtering on (negated) frame.time_relative filters out wrong frame.number Peter Wu (Mar 17)