On Sat, Mar 9, 2013 at 12:27 AM, Hadriel Kaplan <hkap...@acmepacket.com> wrote: > > On Mar 8, 2013, at 6:20 PM, Jeff Morriss <jeff.morriss...@gmail.com> 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 ___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe
