bug: nft -n still shows "resolved" values for iif and oif

bug: nft -n still shows "resolved" values for iif and oif

[Christoph Anton Mitterer]

Hey.

E.g.:
# nft list ruleset
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state { established, related } accept
		iif "eth0" accept
	}
}
#  nft -n list ruleset
table inet filter {
	chain input {
		type filter hook input priority 0; policy drop;
		ct state { 0x2, 0x4 } accept
		iif "eth0" accept
	}
}


IMO especially for iif/oif, which hardcode the iface ID rather than
name, it would IMO be rather important to show the real value (that is
the ID) and not the resolved one... so that users aren't tricked into
some false sense (when they should actually use [io]ifname.

Maybe one could however always resolv it for lo, if that is truly
always ID 1, as I've been told.


Thanks,
Chris.


[0] https://lore.kernel.org/netfilter/aNPhP63SyX2ofE92@strlen.de/T/#m15841db7bf5bb588483fdd3576d70af7a71f5555

Re: bug: nft -n still shows "resolved" values for iif and oif

[Fernando Fernandez Mancera]

On 9/24/25 11:48 PM, Christoph Anton Mitterer wrote:
> Hey.
> 
> E.g.:
> # nft list ruleset
> table inet filter {
> 	chain input {
> 		type filter hook input priority filter; policy drop;
> 		ct state { established, related } accept
> 		iif "eth0" accept
> 	}
> }
> #  nft -n list ruleset
> table inet filter {
> 	chain input {
> 		type filter hook input priority 0; policy drop;
> 		ct state { 0x2, 0x4 } accept
> 		iif "eth0" accept
> 	}
> }
> 
> 
> IMO especially for iif/oif, which hardcode the iface ID rather than
> name, it would IMO be rather important to show the real value (that is
> the ID) and not the resolved one... so that users aren't tricked into
> some false sense (when they should actually use [io]ifname.
> 

Hi,

AFAICS, the current -n is just a combination of '--numeric-priority 
--numeric-protocol --numeric-time'. Although, the message displayed when 
using --help is misleading.

-n, --numeric                   Print fully numerical output.

I propose two changes:

1. Adjust the description when doing --help
2. Introduce a new "--numeric-interface" which prevents resolving iif or 
oif.

Another possible solution could be to use --numeric to do not resolve 
iif/oif but then it would mean we should not resolve ANYTHING as "Print 
fully numerical output." mentions.

What do you think? I can send a patch and test it.

Thanks,
Fernando.

> Maybe one could however always resolv it for lo, if that is truly
> always ID 1, as I've been told.
> 
> 
> Thanks,
> Chris.
> 
> 
> [0] https://lore.kernel.org/netfilter/aNPhP63SyX2ofE92@strlen.de/T/#m15841db7bf5bb588483fdd3576d70af7a71f5555
> 

Re: bug: nft -n still shows "resolved" values for iif and oif

[Pablo Neira Ayuso]

On Thu, Sep 25, 2025 at 02:36:15PM +0200, Fernando Fernandez Mancera wrote:
> 
> 
> On 9/24/25 11:48 PM, Christoph Anton Mitterer wrote:
> > Hey.
> > 
> > E.g.:
> > # nft list ruleset
> > table inet filter {
> > 	chain input {
> > 		type filter hook input priority filter; policy drop;
> > 		ct state { established, related } accept
> > 		iif "eth0" accept
> > 	}
> > }
> > #  nft -n list ruleset
> > table inet filter {
> > 	chain input {
> > 		type filter hook input priority 0; policy drop;
> > 		ct state { 0x2, 0x4 } accept
> > 		iif "eth0" accept
> > 	}
> > }
> > 
> > 
> > IMO especially for iif/oif, which hardcode the iface ID rather than
> > name, it would IMO be rather important to show the real value (that is
> > the ID) and not the resolved one... so that users aren't tricked into
> > some false sense (when they should actually use [io]ifname.
> > 
> 
> Hi,
> 
> AFAICS, the current -n is just a combination of '--numeric-priority
> --numeric-protocol --numeric-time'. Although, the message displayed when
> using --help is misleading.
> 
> -n, --numeric                   Print fully numerical output.
> 
> I propose two changes:
> 
> 1. Adjust the description when doing --help
> 2. Introduce a new "--numeric-interface" which prevents resolving iif or
> oif.

I wonder if there is a use-case for this.

> Another possible solution could be to use --numeric to do not resolve
> iif/oif but then it would mean we should not resolve ANYTHING as "Print
> fully numerical output." mentions.
> 
> What do you think? I can send a patch and test it.

It would good to check if there are more datatypes that are hiding a
number value behind to decide what to do with -n/--numeric.

Re: bug: nft -n still shows "resolved" values for iif and oif

[Fernando Fernandez Mancera]

On 9/25/25 4:07 PM, Pablo Neira Ayuso wrote:
> On Thu, Sep 25, 2025 at 02:36:15PM +0200, Fernando Fernandez Mancera wrote:
>>
>>
>> On 9/24/25 11:48 PM, Christoph Anton Mitterer wrote:
>>> Hey.
>>>
>>> E.g.:
>>> # nft list ruleset
>>> table inet filter {
>>> 	chain input {
>>> 		type filter hook input priority filter; policy drop;
>>> 		ct state { established, related } accept
>>> 		iif "eth0" accept
>>> 	}
>>> }
>>> #  nft -n list ruleset
>>> table inet filter {
>>> 	chain input {
>>> 		type filter hook input priority 0; policy drop;
>>> 		ct state { 0x2, 0x4 } accept
>>> 		iif "eth0" accept
>>> 	}
>>> }
>>>
>>>
>>> IMO especially for iif/oif, which hardcode the iface ID rather than
>>> name, it would IMO be rather important to show the real value (that is
>>> the ID) and not the resolved one... so that users aren't tricked into
>>> some false sense (when they should actually use [io]ifname.
>>>
>>
>> Hi,
>>
>> AFAICS, the current -n is just a combination of '--numeric-priority
>> --numeric-protocol --numeric-time'. Although, the message displayed when
>> using --help is misleading.
>>
>> -n, --numeric                   Print fully numerical output.
>>
>> I propose two changes:
>>
>> 1. Adjust the description when doing --help
>> 2. Introduce a new "--numeric-interface" which prevents resolving iif or
>> oif.
> 
> I wonder if there is a use-case for this.
> 
>> Another possible solution could be to use --numeric to do not resolve
>> iif/oif but then it would mean we should not resolve ANYTHING as "Print
>> fully numerical output." mentions.
>>
>> What do you think? I can send a patch and test it.
> 
> It would good to check if there are more datatypes that are hiding a
> number value behind to decide what to do with -n/--numeric.
> 

After inspecting the different datatypes:

- verdict (I do not think it makes sense to not resolve this one)
- tchandle (it resolves TC_H_ROOT and TC_H_UNSPEC)
- iif/oif
- ct_label (I think this isn't useful in numeric value)

I do not think there is an use-case for --numeric-interface other than 
just showing the id configured. Maybe we can honor the description of 
--numeric and handle iif/oif and tchandle when using it?

Re: bug: nft -n still shows "resolved" values for iif and oif

[Christoph Anton Mitterer]

On Thu, 2025-09-25 at 14:36 +0200, Fernando Fernandez Mancera wrote:
> 2. Introduce a new "--numeric-interface" which prevents resolving iif
> or 
> oif.

What IMO would be most helpful for users is an option, which for all
values simply causes the "real" value to be printed.

With "real" I mean:
- if e.g. an ip daddr matches on 1.1.1.1, then print 1.1.1.1
- if there were an ip domainname where netfilter would resolve, the
  that option should print the hostname
- if using iifname, the actual matched value is the string, so print
  that
- if using iif or oif, the actual matched value is the ID, so print
  that, in particular as (perhaps with the exception of lo), e.g. eth0
  isn't per definition ID 2 or whatever


For things like ICMP Type codes, IP protocol numbers, port numbers...
things are different to e.g. the iface ID.
For them, e.g. type 0 is always guaranteed to be icmp echo request and
22 is always port SSH.


So it could IMO be handy to have an option which gives the above
("real") but still uses non-numeric values for things where the
number<->string is fixed, and if one uses the option e.g. twice, then
even those are printed with their numeric values.


Cheers,
Chris.

Re: bug: nft -n still shows "resolved" values for iif and oif

[Florian Westphal]

Christoph Anton Mitterer <calestyo@scientia.org> wrote:
> IMO especially for iif/oif, which hardcode the iface ID rather than
> name, it would IMO be rather important to show the real value (that is
> the ID) and not the resolved one.

Seems like a bad idea.  Existing method will make
sure that if the device is renamed the output will change.

Also, if you load a ruleset you get a hard error if the device doesn't exist,
unlike with a raw value.

Or, its updated interally to whatever value is needed.

I'm open to Fernandos suggestion wrt. new options but i just don't see
a use case for this.

Re: bug: nft -n still shows "resolved" values for iif and oif

[Christoph Anton Mitterer]

On Thu, 2025-09-25 at 16:42 +0200, Florian Westphal wrote:
> Christoph Anton Mitterer <calestyo@scientia.org> wrote:
> > IMO especially for iif/oif, which hardcode the iface ID rather than
> > name, it would IMO be rather important to show the real value (that
> > is
> > the ID) and not the resolved one.
> 
> Seems like a bad idea.  Existing method will make
> sure that if the device is renamed the output will change.

But AFAIU only when it's renamed, not when it's e.g. removed and then
brought back?

I mean sometimes (admittedly rarely) I unload for example my wifi
driver modules and reload them (when the driver or firmware got in a
weird state and doesn't seem to recover).
Then my wifi iface would get a new ID, wouldn't id?


Maybe one could make iif/oif a special case... where the numeric value
is written and in a comment "(current: <name>)"?

Re: bug: nft -n still shows "resolved" values for iif and oif

[Florian Westphal]

Christoph Anton Mitterer <calestyo@scientia.org> wrote:
> On Thu, 2025-09-25 at 16:42 +0200, Florian Westphal wrote:
> > Christoph Anton Mitterer <calestyo@scientia.org> wrote:
> > > IMO especially for iif/oif, which hardcode the iface ID rather than
> > > name, it would IMO be rather important to show the real value (that
> > > is
> > > the ID) and not the resolved one.
> > 
> > Seems like a bad idea.  Existing method will make
> > sure that if the device is renamed the output will change.
> 
> But AFAIU only when it's renamed, not when it's e.g. removed and then
> brought back?

Sure, only when renamed.  When you remove it raw value is shown
and it won't match anymore.

> I mean sometimes (admittedly rarely) I unload for example my wifi
> driver modules and reload them (when the driver or firmware got in a
> weird state and doesn't seem to recover).
> Then my wifi iface would get a new ID, wouldn't id?

Sure but why do you use iif with a interface that gets removed in
between?

> Maybe one could make iif/oif a special case... where the numeric value
> is written and in a comment "(current: <name>)"?

I find that even worse compared to new command line option and i don't
see what added value it would provide or what confusion it would avoid.

iif and iifname are not the same and people should not expect them to
be.

If you use iif, then you specifically ask to continue matching on rename
of the interface, whereas iifname would stop matching.

If you use iifname, then you ask to match when interfaces get brought up
and down dynamically, e.g. ppp/dialup or virtual vpn interfaces.

Really, just use iifname if in doubt.

Re: bug: nft -n still shows "resolved" values for iif and oif

[Christoph Anton Mitterer]

On Thu, 2025-09-25 at 18:45 +0200, Florian Westphal wrote:
> Sure, only when renamed.  When you remove it raw value is shown
> and it won't match anymore.

Still, when explicitly using --numeric, which one can expect to show
the real values that are matched, and it still shows the string,...
then I guess it's easy for people to wrongly expect that it would
actually match on the name.


> Sure but why do you use iif with a interface that gets removed in
> between?

Well, *I* don't, but given the number of examples floating around that
use iif/oif I guess it's safe to assume that many users might not
realise.

And I'd have argued that the whole point of a --numeric is to show the
real values, that are actually used for matching.
Except that for values where the names are statically defined, I'd have
argued one could use a double -n to make them print the real numbers.


Aynway... not a big deal.


Cheers,
Chris.