On Thu, Aug 01, 2019 at 02:47:38PM +0200, Pablo Neira Ayuso wrote:
> On Thu, Aug 01, 2019 at 02:41:07PM +0200, Phil Sutter wrote:
> > Hi,
> >
> > 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:
> [...]
> > > I think users will end up using --arp and --bridge for this. I myself
> > > will not remember this -0 and -1 thing.
> >
> > That's correct. So I guess changing cmdline flags to -a/-b makes sense
> > either way.
>
> In the rule side, getopt_long() is already pretty overloaded, just
> double check these are spare.
This is only about xtables-monitor cmdline, or am I missing something?
> > > 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.
> >
> > I would omit the prefix from output if a family was selected. For
> > unfiltered xtables-monitor output, I would change the prefix to
> > something more readable, e.g.:
> >
> > 'ip: ',
> > 'ip6: ',
> > 'arp: ',
> > 'eb: '
> >
> > What do you think?
>
> Probably use the long option name, which seems more readable to me:
>
> EVENT: --ipv4 -t filter -A INPUT -j ACCEPT
Ah, good idea!
> I like that the event is printed using the {ip,...}tables syntax.
OK. --arp/--bridge won't work there, obviously. We could of course try
to change that, but I guess it's not feasible. Also, IIRC 'iptables -6'
was buggy in that it should fail but does not. This is a compatibility
issue I didn't get to fix yet.
Cheers, Phil
