We just got another bug on what I believe is exactly the same issue:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8529
Do we have at least a rough consensus on what the correct behaviour is?
On Sat, Mar 9, 2013 at 7:48 AM, Evan Huus <eapache@xxxxxxxxx> wrote:
> 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