Re: [LARTC] [BUG?] ip ru flush && RTNETLINK answers: Numerical result out of range

[Patrick McHardy <kaber@trash.net>]

Luciano Ruete wrote:
> After an: 
> # ip ru flush
> I loose all my ip rules but the priority 0 one. 
> root@sarasvati:~# ip ru
> 0:      from all lookup 255
> root@sarasvati:~#  
> 
> Ok with that, but now i'm not able to insert any new rule.
> This leads to a total loose of conectivity.
> 
> root@sarasvati:~# ip ru add from all table default
> RTNETLINK answers: Numerical result out of range
> root@sarasvati:~# ip ru add from all lookup main
> RTNETLINK answers: Numerical result out of range
> 
> Even seting the priority value by hand, i got the same error:
> 
> root@sarasvati:~# ip ru add from all lookup main priority 32766
> RTNETLINK answers: Numerical result out of range
> 
> To be able to send this e-mail without rebooting i had to insert my gw ip 
> routes in table 255.
> 
> Is this a bug in iproute?
> 
> Some adiotional data:
> ip utility, iproute2-ss060323
> Linux sarasvati 2.6.20-5-386 #2 Sat Jan 6 14:44:57 UTC 2007 i686 GNU/Linux


The problem seems to be the nla policy added in 2.6.19 or 2.6.20.
When specifying a prefix as "all", iproute adds a zero byte long
attribute (FRA_SRC in this case). The IPv4 fib_rules policy states
that it has to be exactly 4 bytes long, which makes validation fail.
This also affects IPv6 and DECnet.

I would argue that iproute is broken and shouldn't add a zero
byte long attribute, but we still need to make sure the kernel
accepts these attributes as valid.

Thomas, I can't see a clean way to fix this right now that
doesn't either bloat struct nla_policy or removes FRA_SRC/FRA_DST
from the policy, could you please look into this? Thanks.