Re: [iptables PATCH 4/5] xtables-monitor: Support ARP and bridge families

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Thu, Aug 01, 2019 at 02:30:40PM +0200, Pablo Neira Ayuso wrote:
> On Thu, Aug 01, 2019 at 02:00:48PM +0200, Phil Sutter wrote:
> > On Thu, Aug 01, 2019 at 01:20:50PM +0200, Pablo Neira Ayuso wrote:
> > > On Wed, Jul 31, 2019 at 06:39:14PM +0200, Phil Sutter wrote:
> > >  @@ -565,6 +574,8 @@ static const struct option options[] = {
> > > >  	{.name = "counters", .has_arg = false, .val = 'c'},
> > > >  	{.name = "trace", .has_arg = false, .val = 't'},
> > > >  	{.name = "event", .has_arg = false, .val = 'e'},
> > > > +	{.name = "arp", .has_arg = false, .val = '0'},
> > > > +	{.name = "bridge", .has_arg = false, .val = '1'},
> > > 
> > > Probably?
> > > 
> > > -A for arp.
> > > -B for bridge.
> > > 
> > > so users don't have to remember? -4 and -6 are intuitive, I'd like
> > > these are sort of intuitive too in its compact definition.
> > > 
> > > Apart from that, patchset looks good to me.
> > 
> > I had something like that (-a and -b should still be free), but then
> > discovered that for rules there was '-0' prefix in use when printing arp
> > family rules. Should I change these prefixes also or leave them as -0
> > and -1? I guess most importantly they must not clash with real
> > parameters.
> 
> You can just leave them as is if this is the way this is exposed in
> rules. Not sure what the logic behing -0 and -1 is, this is not
> mapping to NFPROTO_* definitions, so it looks like something it's been
> pulled out of someone's hat :-)
> 
> I think users will end up using --arp and --bridge for this. I myself
> will not remember this -0 and -1 thing.

Probably exposing:

iptables-monitor
ip6tables-monitor
arptables-monitor
ebtables-monitor

although this will not solve the problem that we are discussing here,
I think having those around would be nice.

The xtables-monitor variant still will need to sort out the -0 and -1
thing that we're discussing here.

> Feel free to explore any possibility, probably leaving the existing -0
> and -1 in place if you're afraid of breaking anything, add aliases and
> only document the more intuitive one. If you think this is worth
> exploring, of course.