Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 37802: /trunk/ /trunk/: capture.c du

From: Michael Tüxen <Michael.Tuexen@xxxxxxxxxxxxxxxxx>
Date: Tue, 28 Jun 2011 08:31:30 +0200
On Jun 28, 2011, at 4:45 AM, Guy Harris wrote:

> 
> On Jun 27, 2011, at 12:13 PM, Michael Tüxen wrote:
> 
>> It is fixed in r37806. The currently
>> tshark -i lo0 -i en0 -f icmp sctp
>> will use sctp as the default capture filter. This means that the above is the same as
>> tshark -f sctp -i lo0 -i en0 icmp
>> or
>> tshark -i lo0 -f sctp -i en0 icmp
> 
> So does a "-f" filter apply to the interface specified immediately *before* the "-f" flag or to the interface specified immediately *after* the "-f" flag?
A "-f" filter specified before the first interface is the default filter.
A "-f" filter specified not before the first interface applies only the the
interface immediately before the "-f" flag.
I'm currently not enforcing that a given default is actually used for at
least one interface.

This applies to tshark, dumpcap, and wireshark. Only tshark supports a final
filter argument. So currently I use it as another way of specifying a default
and consider it an error to give the default twice (once with an initial -f
and another time with the argument).

However, this makes "tshark -i lo0 -f icmp sctp", which is invalid in earlier
versions.
> 
> And are users likely to remember which one is the case, and are most or all of them likely to consider one of the two the "obvious" right answer?
I could imagine that users using the filter argument expect the filter
to be used on each interface. So it might make sense to require that
no -f argument is given at all when using the filter argument. This would
also make "tshark -i lo0 -f icmp sctp" invalid as it is in earlier versions.

Could you live with that?

Best regards
Michael
> 
>> However,
>> tshark -i lo0 -f sctp icmp
>> does not result in an error anymore.
>> If we want to keep that behavior, then we must require that no interface specific
>> capture filter is used when the filter as an argument is given. Which behavior
>> do you prefer?
> 
> Report an error off
> 
> 	1) a default capture filter was supplied
> 
> but
> 
> 	2) all interfaces on which you're capturing had explicit capture filters supplies, so that the default capture filter doesn't apply to any interfaces.
> ___________________________________________________________________________
> 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
>