Wireshark mailing list archives
Re: tshark option for reassembled fragment output
From: Evan Huus <eapache () gmail com>
Date: Wed, 27 Mar 2013 22:38:00 -0400
On Wed, Mar 27, 2013 at 7:10 PM, Hadriel Kaplan <HKaplan () acmepacket com> wrote:
On Mar 27, 2013, at 5:44 PM, Evan Huus <eapache () gmail com> wrote:On Wed, Mar 27, 2013 at 2:43 PM, Hadriel Kaplan <HKaplan () acmepacket com> wrote:On Mar 27, 2013, at 1:57 PM, Evan Huus <eapache () gmail com> wrote:-d filtering is done when displaying, and has no effect on the internal dissection at all (note this does not force 2 passes).Actually I'm pretty sure Wireshark *does* perform two passes when a display filter is applied from the command line. It performs the first-pass on reading the file during which it applies a read-filter if supplied as well as a display-filter if supplied, and it does a second display-filter and dissection pass during loading of the GUI's packet-store (which was filled by whatever passed the first pass).I think this is just a potential optimization in Wireshark, not required behaviour. It shouldn't (?) materially affect my proposal.I guess my point is the reason some of these things work in Wireshark and not tshark is because Wireshark always performs two passes.
Wireshark has an updatable GUI, so it can do as many passes as it wants and just keep changing what it shows. Tshark doesn't have this ability.
If Wireshark didn't perform two passes, and if tshark doesn't with the "-Y", then some things will not work.
I understand that.
So why make it optional?
Because -2 causes tshark to buffer, which we shouldn't be imposing on the user 'by accident'. Additionally, if we keep -2 a separate option then -d will be usable during a live capture, which fixes another long-standing issue in tshark.
Just have '-Y' always do a two-pass analysis. Otherwise there's no real difference between '-R' and '-Y', unless '-2' is also set.
As per previous, -d (or -Y or whatever) should be usable during live capture, while -R is not.
For example, bug 8529 is that using a '-R icmp.resp_in' filter doesn't work in tshark. It doesn't work because the 'icmp.resp_in' field isn't set until later... in the second pass. The same would be true in Wireshark - it wouldn't display the ICMP requests if it didn't run through two passes, because in the first pass none of them have that field set. In tshark it doesn't work even with the "-2" option set, but that's because the "-R" is really a read filter for all intents and purposes, not a display filter. So in the current two-pass mode in tshark, the '-R icmp.resp_in' filters out ALL the frames in the first pass (since none of them have that field yet), so that there are no frames remaining to even be checked in the second pass. The same thing would happen in wireshark, if you do "wireshark -r <file> -R icmp.resp_in" nothing will show up. [note: Interestingly in Wireshark if you either do "wireshark -r <file> -d icmp.resp_in" or set that display-filter before opening the file within the GUI, nothing shows up either at first... but if you clear the display filter inside the gui after the file is open and re-apply the filter, the correct frames show up. But that's because of what I had said earlier: it performs a first-pass on reading the file with the read-filter and display-filter, and a second pass while loading the GUI packet-store which was filled by whatever passed the first-pass, which won't contain anything in this case because the ICMP requests won't pass this display-filter in the first pass.]
Presumably this is a bug - in the first pass wireshark should ignore the display filter, and only apply that on the second pass. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Re: tshark option for reassembled fragment output, (continued)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 08)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 09)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 27)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 27)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 27)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 27)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 27)
- Re: tshark option for reassembled fragment output Christopher Maynard (Mar 27)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 27)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 27)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 27)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 27)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 28)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 28)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 28)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 28)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 29)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 29)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 28)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 27)