Re: Filtering on (negated) frame.time_relative filters out wrong frame.number

[Graham Bloice <graham.bloice () trihedral com>]

On 17 March 2017 at 11:23, Peter Wu <peter () lekensteyn nl> 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 () 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?
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

___________________________________________________________________________
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