ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

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

From: Miroslav Rovis <miro.rovis@xxxxxxxxxxxxxxxxx>
Date: Fri, 17 Mar 2017 16:28:52 +0100
On 170317-11:29+0000, Graham Bloice wrote:
> 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)
[...]
> > >
> > > ((!(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).
I haven't used "Export PDUs to File" yet. It wasn't close at hand
finding what PDU is, since there is no string "protocol data unit" to be
found in:
https://www.wireshark.org/docs/wsug_html/
nor the string "Export PDU"
Found string "protocol data unit (PDU)" only in:
https://www.wireshark.org/docs/wsdg_html/
and in:
https://wiki.wireshark.org/PDU
but am uncertain I to "Export PDUs to File" (which of course,
I see under "File" in Wireshark. Probably by giving the frame.number...
and OSI layer 7... Tried, didn't get much. Not clear to me...

> > To filter out frames by number you can also use "not frame.number==1310
> > and not frame.number==1484".
I know that. I used that first, and the wrong packets were removed just
like later with frame.time_relative
(
but the fact that Wireshark, when packet 1070 is selected (on this
morning's, see below, dump_170317_0928_g0n.pcap.O), when you
right-click, "Prepare a filter" and then left-click on "Not selected"
choses: !(frame.time_relative == 33.105837782) ... Aah! I see now. It
depends on where you right clicked in Wireshark... Sorry! Anyway (just
to finish my thought), that made me think the frame.time_relative was
preferred way... 

> > Can you try to prepare a smaller capture that can reproduce the issue
> > which does not contain sensitive passwords?
I've started work on that this morning, but was unwell. Will continue.

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

Thanks! Yes, I knew about editcap, but for months I had been able to use that
method that I described. It worked just faultlessly on many occasions.
Until recently.

Will be back as soon as I will be able to, with this morning's example,
complete, with a fake password.

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

Attachment: signature.asc
Description: Digital signature