Wireshark-dev: Re: [Wireshark-dev] Add restrictions to arguments of dumpcap
From: Michael Tüxen <Michael.Tuexen@xxxxxxxxxxxxxxxxx>
Date: Thu, 7 May 2009 16:18:21 -0400
On May 7, 2009, at 4:04 PM, Nathan Jennings wrote:

On 5/7/2009 3:26 PM, Michael Tüxen wrote:

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


Sorry, I forgot about the other parameters...

If "link_type" is required, I think you have the order of those correct, i.e. the user isn't required to provide "snap_length", as it's the last
parameter, which defaults to zero/65535.

So is "link_type" required?
No. These are optional. That is why I put them at the end...


If not, there'd be an issue with a parameter ordering requirement since
both "link_type" and "snap_length" would be optional.

This starts down the parsing/coding/usability "slippery slope" of
overloading "-i", but I can't think of another way other than requiring
at least an empty parameter, e.g. ",,".

So, for example, if you have:

Interface  : dag0:2
Filter     : sctp && host 1.2.3.4
Link-type  : <default>
Snap-length: 256

you'd use:

dumpcap -n -i dag0:2,"sctp && host 1.2.3.4",,256 -i en0
Yes, that was what I had in mind.

The real important point for me is that we extend the current
behaviour....


-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