[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190517141709.GA25473@unicorn.suse.cz>
Date: Fri, 17 May 2019 16:17:09 +0200
From: Michal Kubecek <mkubecek@...e.cz>
To: netdev@...r.kernel.org
Cc: "Jason A. Donenfeld" <Jason@...c4.com>,
emersonbernier@...anota.com, dsahern@...il.com,
Stephen Hemminger <stephen@...workplumber.org>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
David Miller <davem@...emloft.net>, piraty1@...ox.ru
Subject: Re: 5.1 `ip route get addr/cidr` regression
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
Powered by blists - more mailing lists