Wireshark

  • Riverbed Technology
  • WinPcap
the world's foremost network protocol analyzer
  • Wireshark
    • About
    • Download
    • Blog
  • Get Help
    • Ask a Question
    • FAQs
    • Documentation
    • Mailing Lists
    • Online Tools
    • Wiki
    • Bug Tracker
  • Develop
    • Get Involved
    • Developer's Guide
    • Browse the Code
    • Latest Builds

Wireshark-dev: Re: [Wireshark-dev] Add restrictions to arguments of dumpcap

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next


From: Michael Tüxen <Michael.Tuexen@xxxxxxxxxxxxxxxxx>
Date: Thu, 7 May 2009 15:26:18 -0400

On May 7, 2009, at 2:34 PM, Nathan Jennings wrote:

On 5/7/2009 9:10 AM, Sébastien Tandel wrote:
On Thu, May 7, 2009 at 03:05, Stephen Donnelly <stephen@xxxxxxxxxx> wrote:

Aaron Turner wrote:
On Wed, May 6, 2009 at 8:59 PM, Michael Tüxen
<Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
On May 6, 2009, at 3:40 PM, Aaron Turner wrote:
I think this is confusing to many people and is more likely to have
unintended consequences.   Most users don't consider CLI option
ordering to have special meaning.  Personally, I prefer Stephen's
suggestion of directly linking the filter to the interface ala -i
en0:"sctp && host a.b.c.d" if you want to get fancy.

It also means the old style cli args could easliy be grand- fathered in
(any interface without a specific filter uses the global filter).

Completely agree to define something which is explicitly linked to which
interface the filter belongs. Ordering parameters is not intuitive.


I you do decide to go this way, ':' might not be the best delimiter
character to use. It is already used in libpcap interface names and
could cause parsing headaches.

I think some OSes use ':' in vlan interface names? Also ':' is used in
dag interface names to indicate sub streams, e.g. "dag0:2".


':' is indeed confusing. It is used by Linux to define virtual interfaces
like eth0:1


I had also thought of suggesting ":", but see the overloading problem
now as Stephen D. pointed out... which reminded me of maybe another
potential clash:

From a "preferences" file:

<... snip ...>
# Interface descriptions.
# Ex: eth0(eth0 descr),eth1(eth1 descr),...
capture.devices_descr: \Device\NPF_{"Windows-string"}(Intel NIC)
</snip>

... although I can't think of a clash with this off-hand right now.

Maybe this is better?:

dumpcap -n -i dag0:2,"sctp && host 1.2.3.4" -i en0

In the parser, you should probably check for and allow use of single
quotes too (e.g. shell scripts), like:

dumpcap -n -i dag0:2,'sctp && host 1.2.3.4' -i en0
But we also have -y and -s... So taking this path requires something
like
-i interface_name,capture_filer,link_type,snap_length
How does this look like?


So any trailing capture filter on the command-line would apply to
interfaces that do *NOT* have a format like:

<interface_name>,<filter_string>

-Nathan
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe



  • Follow-Ups:
    • Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
      • From: Aaron Turner
    • Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
      • From: Nathan Jennings
    • Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
      • From: Guy Harris
  • References:
    • [Wireshark-dev] Add restrictions to arguments of dumpcap
      • From: Michael Tüxen
    • Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
      • From: Aaron Turner
    • Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
      • From: Michael Tüxen
    • Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
      • From: Aaron Turner
    • Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
      • From: Stephen Donnelly
    • Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
      • From: Sébastien Tandel
    • Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
      • From: Nathan Jennings
  • Prev by Date: Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
  • Next by Date: Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
  • Previous by thread: Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
  • Next by thread: Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
  • Index(es):
    • Date
    • Thread

Wireshark and the "fin" logo are registered trademarks of the Wireshark Foundation