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

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

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.