Wireshark mailing list archives
Re: Filtering on (negated) frame.time_relative filters out wrong frame.number
From: Miroslav Rovis <miro.rovis () croatiafidelis hr>
Date: Thu, 27 Apr 2017 18:56:51 +0200
( should the subject be changed to: Filtering on frame.number filters out wrong, in *shark, editcap ? ) Because, in my machine...: (but first the quote, complete, with one interrupting remark) On 170317-11:29+0000, Graham Bloice wrote:
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> andcontributors.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 PARTICULARPURPOSE.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, withoutKerberos,without GeoIP, with QtMultimedia, without AirPcap. Running on Linux 4.9.13-hardened-r1-170310_23, with locale en_GB.utf8,withlibpcap version 1.8.1, with GnuTLS 3.5.10, with Gcrypt 1.7.6, with zlib1.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 1484Rather 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
(this remark:) and I followed the above recommendation, but...
-- 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
[(but)] --...but...-- [(first the quote, complete)], and next should be the missing info so that our kind developers, as well as the readers generally) quickly connect the old thread (in case this email causes a disruption in how web presents it): Here: ( still the same subject as this very email ) https://www.wireshark.org/lists/wireshark-users/201703/msg00030.html is where I started trying to tell about this issue. And here: https://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/ ( the most, at this time, being in the last page of March: https://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/git-devuan-mail-3.php ) Pls. allow me the luxury to just continue from what I have already explained in the linked places, (very much) without repeating. Thank you. ...And I followed the above recommendation, but... same buggy behavior I get. And now that new buggy stuff (IMO) that I get. ( And I (a customer^Wuser) had even told one of you, Jeff Morriss, that the bug of the then thread and the then report wasn't fixed, and I was right back then (so pls. devs and anybody, try and check this more closely): `tshark -T fields -e data -qz follow,ssl,raw,0` crashes in versions after 2.0.x https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12616#c7 ) Because, in my machine, with: $ tshark -v TShark (Wireshark) 2.2.6 (wireshark-2.2.6) 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 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.11, with Gcrypt 1.7.6, without Kerberos, without GeoIP. Running on Linux 4.9.22-hardened-170417_13, with locale en_GB.utf8, with libpcap version 1.8.1, with GnuTLS 3.5.11, with Gcrypt 1.7.6, with zlib 1.2.11. AMD Phenom(tm) II X4 965 Processor Built using gcc 5.4.0. $ after having run these commands... (all of these are real-life pastes, just the prompt is reduced to only "$"): $ editcap dump_170317_0928_g0n.pcap dump_170317_0928_g0n_EDIT-1069.pcap 1069 $ editcap dump_170317_0928_g0n.pcap dump_170317_0928_g0n_EDIT-1070.pcap 1070 $ editcap dump_170317_0928_g0n.pcap dump_170317_0928_g0n_EDIT-1071.pcap 1071 $ editcap dump_170317_0928_g0n.pcap dump_170317_0928_g0n_EDIT-1069-1070.pcap 1069 1070 $ editcap dump_170317_0928_g0n.pcap dump_170317_0928_g0n_EDIT-1070-1071.pcap 1070 1071 $ editcap dump_170317_0928_g0n.pcap dump_170317_0928_g0n_EDIT-1069-1070-1071.pcap 1069 1070 1071 $ ls -ABgotr | tail -6 -rw-r--r-- 1 889260 2017-04-27 17:52 dump_170317_0928_g0n_EDIT-1069.pcap -rw-r--r-- 1 888512 2017-04-27 17:52 dump_170317_0928_g0n_EDIT-1070.pcap -rw-r--r-- 1 888512 2017-04-27 17:52 dump_170317_0928_g0n_EDIT-1071.pcap -rw-r--r-- 1 888416 2017-04-27 17:53 dump_170317_0928_g0n_EDIT-1069-1070.pcap -rw-r--r-- 1 887668 2017-04-27 17:53 dump_170317_0928_g0n_EDIT-1070-1071.pcap -rw-r--r-- 1 887572 2017-04-27 17:53 dump_170317_0928_g0n_EDIT-1069-1070-1071.pcap $ ...I check, and see that...: $ for i in $(ls -1 dump_170317_0928_g0n_EDIT-*.pcap); do ls -l $i ; tshark -r $i | grep sign_in | grep www-form-urle ; echo "---" ; done ; -rw-r--r-- 1 miro miro 887572 2017-04-27 17:53 dump_170317_0928_g0n_EDIT-1069-1070-1071.pcap --- -rw-r--r-- 1 miro miro 888416 2017-04-27 17:53 dump_170317_0928_g0n_EDIT-1069-1070.pcap 1069 33.105854500 192.168.1.4 → 78.26.97.141 HTTP 812 POST /users/sign_in HTTP/1.1 (application/x-www-form-urlencoded) --- -rw-r--r-- 1 miro miro 889260 2017-04-27 17:52 dump_170317_0928_g0n_EDIT-1069.pcap 1069 33.105837782 192.168.1.4 → 78.26.97.141 HTTP 812 POST /users/sign_in HTTP/1.1 (application/x-www-form-urlencoded) --- -rw-r--r-- 1 miro miro 887668 2017-04-27 17:53 dump_170317_0928_g0n_EDIT-1070-1071.pcap --- -rw-r--r-- 1 miro miro 888512 2017-04-27 17:52 dump_170317_0928_g0n_EDIT-1070.pcap 1070 33.105854500 192.168.1.4 → 78.26.97.141 HTTP 812 POST /users/sign_in HTTP/1.1 (application/x-www-form-urlencoded) --- -rw-r--r-- 1 miro miro 888512 2017-04-27 17:52 dump_170317_0928_g0n_EDIT-1071.pcap 1070 33.105837782 192.168.1.4 → 78.26.97.141 HTTP 812 POST /users/sign_in HTTP/1.1 (application/x-www-form-urlencoded) --- $ ...[I see that] most of those got the frame.number's wrong... If I write even more, it could be actually less useful. So what I will now do, is... no I won't, I'll first ask if I can or need do so, I won't attach all these: dump_170317_0928_g0n_EDIT-1069.pcap dump_170317_0928_g0n_EDIT-1070.pcap dump_170317_0928_g0n_EDIT-1071.pcap dump_170317_0928_g0n_EDIT-1069-1070.pcap dump_170317_0928_g0n_EDIT-1070-1071.pcap dump_170317_0928_g0n_EDIT-1069-1070-1071.pcap but just this one I'll attach: dump_170317_0928_g0n_EDIT-1070.pcap since the command line used to get them/it is clearly reported. I'm not saying it's Wireshark, could be something it uses, and I, at least in theory, could be owned (it really doesn't look so to me)[1], but these are what I get with those commands. And in the next mail I could attach any other of the bunch, if it were needed. Yeah, that's best. I checked all the new bugs/fixes/CVE's (all the 70 or so pages in one palemoon command I opened) and I think in none is there mention of frame.number, so this (?) bug (Wireshark of some other's that it be) is not in Wireshark bugzilla... Ah, while the SSL-keys are still the same, it's not a big deal to attach them handy too: dump_170317_0928_g0n_SSLKEYLOGFILE.txt (how else could you find the 'fakepassword' string?) A couple of hours spent to put this together may not suffice for my slowness, allow ERRATA later in the thread. Regards! --- [1] Pls. devs or any readers, even a confirmation that this does not happen in someone else's boxes is also useful to me. My Wireshark just consistently gets the frame.number's wrong... And it never used to be the case... In case of no reports, I will then try and ask in Gentoo Bugzilla about it... Something is causing this... -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr
Attachment:
dump_170317_0928_g0n_SSLKEYLOGFILE.txt
Description:
Attachment:
dump_170317_0928_g0n_EDIT-1070.pcap
Description:
Attachment:
signature.asc
Description: Digital signature
___________________________________________________________________________ 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:
- Re: Filtering on (negated) frame.time_relative filters out wrong frame.number Miroslav Rovis (Apr 27)
- <Possible follow-ups>
- Re: Filtering on (negated) frame.time_relative filters out wrong frame.number Miroslav Rovis (Apr 28)