On Wed, Mar 27, 2013 at 7:10 PM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
>
> On Mar 27, 2013, at 5:44 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>> On Wed, Mar 27, 2013 at 2:43 PM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
>>>
>>> On Mar 27, 2013, at 1:57 PM, Evan Huus <eapache@xxxxxxxxx> 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.
