On Sat, Mar 9, 2013 at 12:27 AM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
>
> On Mar 8, 2013, at 6:20 PM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:
>
>> Note that someone did find a use case for not saving those dependencies: for when Wireshark got the dependencies wrong (due to, in that case, packet duplication):
>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7667
>
> Yeah, a good/nasty example. In fact, that makes me think there might even be a use-case for specifying both a read and a display filter, separately, in tshark.
>
> So to bring it back full-circle, does anyone object to making the new ability to include dependent frames in exported info as a new '-Y <display filter>' option? (the 'Y' is for 'displaY', Wireshark's '-d' is used for something else in tshark)
I would think it would be better to move the current -d to something
else. Command-line flags should be consistent between Wireshark and
Tshark, at least where they have the same meaing.
> It would not support live capture, only file input. It would not print out the dependents to stdout, but would to PDML/CSV/whatever. Similar to the current -R option, -Y would not re-number the frames, which -2 does do.
>
> If both "-R <read filter>' and '-Y <display-filter>' are specified, then it would run the read filter on the first pass, and the display on the second pass. For example, this would let you do things like:
>
> tshark -r input.pcap -R 'eth.src==00:10:20:30:40:50' -Y 'mp2t' -w output.pcap
>
> ...and you would get the mp2t frames and their dependent fragments, but only for ones from that source Ethernet MAC address.
>
> The other question is if it should deprecate the '-2', or if '-2' should be left as it is now.
My understanding would be that we would end up with -R for read
filters, -d for display filters and -2 which can be added to either
for two-pass analysis (which also enables the reassembly exporting).
There should be no need for an additional flag except as something to
move the current -d to.
Evan