On Fri, May 17, 2019 at 12:22:41PM +0200, Jason A. Donenfeld wrote:
> Hi,
>
> I'm back now and catching up with a lot of things. A few people have
> mentioned to me that wg-quick(8), a bash script that makes a bunch of
> iproute2 invocations, appears to be broken on 5.1. I've distilled the
> behavior change down to the following.
>
> Behavior on 5.0:
>
> + ip link add wg0 type dummy
> + ip address add 192.168.50.2/24 dev wg0
> + ip link set mtu 1420 up dev wg0
> + ip route get 192.168.50.0/24
> broadcast 192.168.50.0 dev wg0 src 192.168.50.2 uid 0
> cache <local,brd>
>
> Behavior on 5.1:
>
> + ip link add wg0 type dummy
> + ip address add 192.168.50.2/24 dev wg0
> + ip link set mtu 1420 up dev wg0
> + ip route get 192.168.50.0/24
> RTNETLINK answers: Invalid argument
With recent kernel and iproute2 5.1, I get
alaris:~ # ip route get 172.17.1.2/24
Error: ipv4: Invalid values in header for route get request.
This message comes from kernel commit a00302b60777 ("net: ipv4: route:
perform strict checks also for doit handlers") which only considers the
range valid if the prefix is /32 (a single address).
But these checks are only performed when userspace requests strict
validation which iproute2 does since (iproute2) commit aea41afcfd6d ("ip
bridge: Set NETLINK_GET_STRICT_CHK on socket"). So I would say the
change is a result of the combination of kernel (5.1) commit
a00302b60777 and iproute2 (5.0) commit aea41afcfd6d.
> Upon investigating, I'm not sure that `ip route get` was ever suitable
> for getting details on a particular route. So I'll adjust the
> wg-quick(8) code accordingly. But FYI, this is unexpected userspace
> breakage.
AFAIK the purpose of 'ip route get' always was to let the user check
the result of a route lookup, i.e. "what route would be used if I sent
a packet to an address". To be honest I would have to check how exactly
was "ip route get <addr>/<prefixlen>" implemented before.
Michal Kubecek
