Re: tshark option for reassembled fragment output

[Hadriel Kaplan <HKaplan () acmepacket com>]

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.  If Wireshark didn't perform two passes, and if tshark doesn't with the "-Y", then some things 
will not work.  So why make it optional?  Just have '-Y' always do a two-pass analysis.  Otherwise there's no real 
difference between '-R' and '-Y', unless '-2' is also set.

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

-hadriel

___________________________________________________________________________
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