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

[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 17 March 2017 at 11:23, Peter Wu <peter@xxxxxxxxxxxxx> wrote:

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@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

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?

Or use editcap to drop the packets;

  editcap infile outfile packet#1 packet#2

See the man page here: https://www.wireshark.org/docs/man-pages/editcap.html

--

Graham Bloice