On Tue, Sep 03, 2024 at 04:53:46PM +0200, Ahelenia Ziemiańska wrote:
> On Tue, Sep 03, 2024 at 10:22:09AM +0200, Pablo Neira Ayuso wrote:
> > On Tue, Sep 03, 2024 at 04:16:21AM +0200, Ahelenia Ziemiańska wrote:
> > > The manual says
> > > COMMANDS
> > > These options specify the particular operation to perform.
> > > Only one of them can be specified at any given time.
> > >
> > > -L --dump
> > > List connection tracking or expectation table
> > >
> > > So, naturally, "conntrack -Lo extended" should work,
> > > but it doesn't, it's equivalent to "conntrack -L",
> > > and you need "conntrack -L -o extended".
> > > This violates user expectations (borne of the Utility Syntax Guidelines)
> > > and contradicts the manual.
> > >
> > > optarg is unused, anyway. Unclear why any of these were :: at all?
> > Because this supports:
> > -L
> > -L conntrack
> > -L expect
> Well that's not what :: does, though; we realise this, right?
>
> "L::" means that getopt() will return
> "-L", "conntrack" -> 'L',optarg=NULL
> "-Lconntrack" -> 'L',optarg="conntrack"
> and the parser for -L (&c.) doesn't... use optarg.
Are you sure it does not use optarg?
static unsigned int check_type(int argc, char *argv[])
{
const char *table = get_optional_arg(argc, argv);
and get_optional_arg() uses optarg.
> You don't parse the filter (table name? idk.) with getopt at all;
> you can test this /right now/ by running precisely the thing you outlined:
> # conntrack -L > /dev/null
> conntrack v1.4.7 (conntrack-tools): 137 flow entries have been shown.
> # conntrack -L expect > /dev/null
> conntrack v1.4.7 (conntrack-tools): 0 expectations have been shown.
> # conntrack -Lexpect > /dev/null
> conntrack v1.4.7 (conntrack-tools): 152 flow entries have been shown.
> and getopt returns, respectively
> 'L',optarg=NULL
> 'L',optarg=NULL; argv[optind]="expect"
> 'L',optarg="expect"
> ...and once again you discard the optarg for 'L' &c.
