Re: [PATCH nft] doc: extend description of fib expression

[Florian Westphal <fw@strlen.de>]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > -|Keyword| Description| Type
> > +|flag| Description
> > +|daddr| Perform a normal route lookup: search fib for route to the *destination address* of the packet.
> > +|saddr| Perform a reverse route lookup: search the fib for route to the *source address* of the packet.
> > +|mark | consider the packet mark (nfmark) when querying the fib.
> > +|iif  | fail fib lookup unless route exists and its output interface is identical to the packets input interface
> 
> maybe easier to understand?
> 
>            if fib lookups provides a route then check its output interface is identical to the packets *input* interface.
> 
> > +|oif  | fail fib lookup unless route exists and its output interface is identical to the packets output interface.
> 
>            if fib lookups provides a route then check its output interface is identical to the packets *output* interface.

Its better, updated, thanks.

> > This flag can only be used with the *type* result.
> 
> Are you sure 'oif' can only be used with type? I can see NFTA_FIB_F_OIF is available in nft_fib4_eval()
> 
>         if (priv->flags & NFTA_FIB_F_OIF)
>                 oif = nft_out(pkt);
>         else if (priv->flags & NFTA_FIB_F_IIF)
>                 oif = nft_in(pkt);
>         else
>                 oif = NULL;

Seems to be dead code.  nft_fib_init() has:
        switch (priv->result) {
        case NFT_FIB_RESULT_OIF:
                if (priv->flags & NFTA_FIB_F_OIF)
                        return -EINVAL;
                len = sizeof(int);
                break;
        case NFT_FIB_RESULT_OIFNAME:
                if (priv->flags & NFTA_FIB_F_OIF)
                        return -EINVAL;
                len = IFNAMSIZ;


since _OIF and _OIFNAME was restricted to prerouting, nf hookfn has NULL
output interface, so there is nothing we could compare against.

Now its available in forward too so it could be selectively relaxed for
this, but, what is the use case?

Do a RPF in forward, then we need to compare vs. incoming interface.

But for outgoing interface, we'd do a normal route lookup, but the stack
already did that for us (as packet is already being forwarded).

So what would be the desired outcome for a 'fib daddr . oif' check?