Re: Clarification of the procedure for filtering IP option fields

[Alexey Kashavkin <akashavkin@xxxxxxxxx>]

> On 30 Jan 2025, at 21:06, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> This is what you mean:
> 
> # nft describe ip option lsrr addr
> exthdr expression, datatype ipv4_addr (IPv4 address) (basetype integer), 32 bits
> <ip-option-use-ipv4-type.patch>

Yes, changing the data type for the addr field in the templates with this macro makes it more user friendly and allows the user to specify the first IP address in the IP option in the network packet as the value of the addr field.

# nft list table ip ipopt
table ip ipopt {
        chain ipopt {
                ip option lsrr addr 192.168.0.11 drop
                ip option lsrr addr 10.0.0.1 drop
                ip option lsrr length 11 counter packets 0 bytes 0 drop
        }
}

I assume that Stefan converted the IP to a decimal number and then already specified the resulting value in the addr field. 
For example like this:

# echo '192*2^24 + 168*2^16 + 0 + 11' | bc
3232235531
# echo '10*2^24 + 0 + 0 + 1' | bc
167772161

# nft add rule ip ipopt_t test_ipopt_c ip option lsrr addr 3232235531 drop
# nft add rule ip ipopt_t test_ipopt_c ip option lsrr addr 167772161 drop

table ip ipopt_t {
        chain ipopt_c {
                ip option lsrr addr 3232235531 drop
                ip option lsrr addr 167772161 drop
                ip option lsrr length 11 counter packets 0 bytes 0 drop
        }
}



Without the type field in the templates as a token for bison and ipaddr_type as the data type, this functionality in nft becomes more correct according to RFC791.

Thank you for the clarification.