ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

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

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