Bug#921737: iproute2: `ip route get` problems with 0.0.0.0 and ::
Hey! Any news on this? I'm opening another (unrelated) bug on iproute2 (or two), and I was wondering how this one was doing. Thanks :) On Thu, 14 Feb 2019 16:37:43 + "=?utf-8?B?Q2zDqW1lbnQgSGVydGxpbmcgKFd4Y2Fmw6kp?=" wrote: > Ah, another thing. The behavior that ip route get shows right now is also > incorrect in the following way: > > ``` > $ ip route show > # [...] > 192.168.1.0/24 dev enp0s31f6 proto kernel scope link src 192.168.1.156 metric > 100 > # [...] > > $ ip route get 192.168.1.22/28 > 192.168.1.22 dev enp0s31f6 src 192.168.1.156 uid 1000 > cache > > $ ip route get 192.168.1.22/24 > 192.168.1.22 dev enp0s31f6 src 192.168.1.156 uid 1000 > cache > ``` > > both should return either > > ``` > 192.168.1.0/24 dev enp0s31f6 src 192.168.1.156 uid 1000 > ``` > > (preferred), or > > ``` > 192.168.1.22/24 dev enp0s31f6 src 192.168.1.156 uid 1000 > ``` > > with the current behavior, it looks as if the mask is ignored. > > > Also, the "cache" source isn't great, it would be nice to get the actual > source of the route (in this case, directly-connected or kernel or something). > > Should I open a new bug (possibly with the linux package) or is this okay? > > Thank you for your help > > -- > Clément 'wxcafé' Hertling > > > February 13, 2019 2:56 PM, "Luca Boccassi" wrote: > > > On Tue, 2019-02-12 at 17:15 +, Clément Hertling (Wxcafé) wrote: > > > >> Hey, > >> > >> February 11, 2019 6:27 PM, "Luca Boccassi" wrote: > >> > >> On Fri, 2019-02-08 at 11:55 -0500, Clément 'wxcafé' Hertling wrote: > >> > >>> Package: iproute2 > >>> Version: 4.20.0-2 > >>> Severity: normal > >>> Tags: ipv6 upstream > >>> > >>> When using `ip route get` with 0.0.0.0 or ::, iproute2 shows > >>> multiple > >>> incorrect behaviors: -- \o/ Clément Hertling G Gandi NOC
Bug#921737: iproute2: `ip route get` problems with 0.0.0.0 and ::
Ah, another thing. The behavior that ip route get shows right now is also
incorrect in the following way:
```
$ ip route show
# [...]
192.168.1.0/24 dev enp0s31f6 proto kernel scope link src 192.168.1.156 metric
100
# [...]
$ ip route get 192.168.1.22/28
192.168.1.22 dev enp0s31f6 src 192.168.1.156 uid 1000
cache
$ ip route get 192.168.1.22/24
192.168.1.22 dev enp0s31f6 src 192.168.1.156 uid 1000
cache
```
both should return either
```
192.168.1.0/24 dev enp0s31f6 src 192.168.1.156 uid 1000
```
(preferred), or
```
192.168.1.22/24 dev enp0s31f6 src 192.168.1.156 uid 1000
```
with the current behavior, it looks as if the mask is ignored.
Also, the "cache" source isn't great, it would be nice to get the actual source
of the route (in this case, directly-connected or kernel or something).
Should I open a new bug (possibly with the linux package) or is this okay?
Thank you for your help
--
Clément 'wxcafé' Hertling
February 13, 2019 2:56 PM, "Luca Boccassi" wrote:
> On Tue, 2019-02-12 at 17:15 +, Clément Hertling (Wxcafé) wrote:
>
>> Hey,
>>
>> February 11, 2019 6:27 PM, "Luca Boccassi" wrote:
>>
>> On Fri, 2019-02-08 at 11:55 -0500, Clément 'wxcafé' Hertling wrote:
>>
>>> Package: iproute2
>>> Version: 4.20.0-2
>>> Severity: normal
>>> Tags: ipv6 upstream
>>>
>>> When using `ip route get` with 0.0.0.0 or ::, iproute2 shows
>>> multiple
>>> incorrect behaviors:
>>>
>>> - `ip route get 0.0.0.0/0` answers "need at least a destination
>>> address",
>>> where it should answer with the default route. 0.0.0.0/0 is a
>>> valid
>>> network and it should be possible to query for the default route
>>> that way
>>> - similarly, `ip route get `::/0` also answers "need at least a
>>> destination
>>> address". For the same reason, it should also answer with the
>>> default
>>> route.
>>
>> Those sound reasonable, can you send a patch upstream and see what
>> they
>> say?
>>
>> Sorry, I wouldn't know how to write a patch or which upstream to send
>> it to.
>> Should I open an issue upstream? Who should I contact for that?
>>
>>> - finally, `ip route get 0.0.0.0/1`, or any other non-0 netmask,
>>> answers
>>> with "local 0.0.0.0 dev lo src 127.0.0.1 uid 1000", which is
>>> simply
>>> wrong. 0.0.0.0/1 IS NOT routed via lo, and this query should
>>> answer
>>> with the most-specific route for 0.0.0.0/1 or the default if
>>> there
>>> is
>>> no such route. Interestingly, `ip route get 1.0.0.0/1`, while a
>>> query
>>> for the exact same subnet, actually gives the right route (in my
>>> case,
>>> the default route).
>>
>> The netlink messages sent by iproute2 look exactly the same, apart
>> from
>> the address:
>>
>> (gdb) p req
>> $17 = {n = {nlmsg_len = 36, nlmsg_type = 26, nlmsg_flags = 1,
>> nlmsg_seq = 0, nlmsg_pid = 0}, r = {
>> rtm_family = 2 '\002', rtm_dst_len = 0 '\000', rtm_src_len = 0
>> '\000', rtm_tos = 0 '\000',
>> rtm_table = 0 '\000', rtm_protocol = 0 '\000', rtm_scope = 0
>> '\000', rtm_type = 0 '\000',
>> rtm_flags = 0}, buf = "\b\000\001", '\000' }
>>
>> (gdb) p req
>> $13 = {n = {nlmsg_len = 36, nlmsg_type = 26, nlmsg_flags = 1,
>> nlmsg_seq = 0, nlmsg_pid = 0}, r = {
>> rtm_family = 2 '\002', rtm_dst_len = 0 '\000', rtm_src_len = 0
>> '\000', rtm_tos = 0 '\000',
>> rtm_table = 0 '\000', rtm_protocol = 0 '\000', rtm_scope = 0
>> '\000', rtm_type = 0 '\000',
>> rtm_flags = 0}, buf = "\b\000\001\000\001", '\000' > times>}
>>
>> So I would guess the issue is in the kernel.
>>
>> Same question, should I open an issue to the debian linux package, or
>> to the linux kernel directly?
>
> No worries, I'll take care of both if you are not familiar with the
> processes
>
> --
> Kind regards,
> Luca Boccassi
Bug#921737: iproute2: `ip route get` problems with 0.0.0.0 and ::
On Tue, 2019-02-12 at 17:15 +, Clément Hertling (Wxcafé) wrote:
> Hey,
>
> February 11, 2019 6:27 PM, "Luca Boccassi" wrote:
>
> > On Fri, 2019-02-08 at 11:55 -0500, Clément 'wxcafé' Hertling wrote:
> >
> > > Package: iproute2
> > > Version: 4.20.0-2
> > > Severity: normal
> > > Tags: ipv6 upstream
> > >
> > > When using `ip route get` with 0.0.0.0 or ::, iproute2 shows
> > > multiple
> > > incorrect behaviors:
> > >
> > > - `ip route get 0.0.0.0/0` answers "need at least a destination
> > > address",
> > > where it should answer with the default route. 0.0.0.0/0 is a
> > > valid
> > > network and it should be possible to query for the default route
> > > that way
> > > - similarly, `ip route get `::/0` also answers "need at least a
> > > destination
> > > address". For the same reason, it should also answer with the
> > > default
> > > route.
> >
> > Those sound reasonable, can you send a patch upstream and see what
> > they
> > say?
>
> Sorry, I wouldn't know how to write a patch or which upstream to send
> it to.
> Should I open an issue upstream? Who should I contact for that?
>
> >
> > > - finally, `ip route get 0.0.0.0/1`, or any other non-0 netmask,
> > > answers
> > > with "local 0.0.0.0 dev lo src 127.0.0.1 uid 1000", which is
> > > simply
> > > wrong. 0.0.0.0/1 IS NOT routed via lo, and this query should
> > > answer
> > > with the most-specific route for 0.0.0.0/1 or the default if
> > > there
> > > is
> > > no such route. Interestingly, `ip route get 1.0.0.0/1`, while a
> > > query
> > > for the exact same subnet, actually gives the right route (in my
> > > case,
> > > the default route).
> >
> > The netlink messages sent by iproute2 look exactly the same, apart
> > from
> > the address:
> >
> > (gdb) p req
> > $17 = {n = {nlmsg_len = 36, nlmsg_type = 26, nlmsg_flags = 1,
> > nlmsg_seq = 0, nlmsg_pid = 0}, r = {
> > rtm_family = 2 '\002', rtm_dst_len = 0 '\000', rtm_src_len = 0
> > '\000', rtm_tos = 0 '\000',
> > rtm_table = 0 '\000', rtm_protocol = 0 '\000', rtm_scope = 0
> > '\000', rtm_type = 0 '\000',
> > rtm_flags = 0}, buf = "\b\000\001", '\000' }
> >
> > (gdb) p req
> > $13 = {n = {nlmsg_len = 36, nlmsg_type = 26, nlmsg_flags = 1,
> > nlmsg_seq = 0, nlmsg_pid = 0}, r = {
> > rtm_family = 2 '\002', rtm_dst_len = 0 '\000', rtm_src_len = 0
> > '\000', rtm_tos = 0 '\000',
> > rtm_table = 0 '\000', rtm_protocol = 0 '\000', rtm_scope = 0
> > '\000', rtm_type = 0 '\000',
> > rtm_flags = 0}, buf = "\b\000\001\000\001", '\000' > times>}
> >
> > So I would guess the issue is in the kernel.
>
> Same question, should I open an issue to the debian linux package, or
> to the linux kernel directly?
No worries, I'll take care of both if you are not familiar with the
processes
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#921737: iproute2: `ip route get` problems with 0.0.0.0 and ::
On Fri, 2019-02-08 at 11:55 -0500, Clément 'wxcafé' Hertling wrote:
> Package: iproute2
> Version: 4.20.0-2
> Severity: normal
> Tags: ipv6 upstream
>
>
> When using `ip route get` with 0.0.0.0 or ::, iproute2 shows multiple
> incorrect behaviors:
>
> - `ip route get 0.0.0.0/0` answers "need at least a destination
> address",
> where it should answer with the default route. 0.0.0.0/0 is a valid
> network and it should be possible to query for the default route
> that way
> - similarly, `ip route get `::/0` also answers "need at least a
> destination
> address". For the same reason, it should also answer with the
> default
> route.
Those sound reasonable, can you send a patch upstream and see what they
say?
> - finally, `ip route get 0.0.0.0/1`, or any other non-0 netmask,
> answers
> with "local 0.0.0.0 dev lo src 127.0.0.1 uid 1000", which is simply
> wrong. 0.0.0.0/1 IS NOT routed via lo, and this query should answer
> with the most-specific route for 0.0.0.0/1 or the default if there
> is
> no such route. Interestingly, `ip route get 1.0.0.0/1`, while a
> query
> for the exact same subnet, actually gives the right route (in my
> case,
> the default route).
The netlink messages sent by iproute2 look exactly the same, apart from
the address:
(gdb) p req
$17 = {n = {nlmsg_len = 36, nlmsg_type = 26, nlmsg_flags = 1, nlmsg_seq = 0,
nlmsg_pid = 0}, r = {
rtm_family = 2 '\002', rtm_dst_len = 0 '\000', rtm_src_len = 0 '\000',
rtm_tos = 0 '\000',
rtm_table = 0 '\000', rtm_protocol = 0 '\000', rtm_scope = 0 '\000',
rtm_type = 0 '\000',
rtm_flags = 0}, buf = "\b\000\001", '\000' }
(gdb) p req
$13 = {n = {nlmsg_len = 36, nlmsg_type = 26, nlmsg_flags = 1, nlmsg_seq = 0,
nlmsg_pid = 0}, r = {
rtm_family = 2 '\002', rtm_dst_len = 0 '\000', rtm_src_len = 0 '\000',
rtm_tos = 0 '\000',
rtm_table = 0 '\000', rtm_protocol = 0 '\000', rtm_scope = 0 '\000',
rtm_type = 0 '\000',
rtm_flags = 0}, buf = "\b\000\001\000\001", '\000' }
So I would guess the issue is in the kernel.
> The first two problems seem to be caused by this line in iproute2
> error
> handling https://github.com/shemminger/iproute2/blob/master/ip/iprout
> e.c#L1425,
> which is written without taking into consideration that netmasks of
> length 0 are actually valid; I have no idea where the last problem
> originates unfortunately.
>
> Thank you
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#921737: iproute2: `ip route get` problems with 0.0.0.0 and ::
Package: iproute2 Version: 4.20.0-2 Severity: normal Tags: ipv6 upstream When using `ip route get` with 0.0.0.0 or ::, iproute2 shows multiple incorrect behaviors: - `ip route get 0.0.0.0/0` answers "need at least a destination address", where it should answer with the default route. 0.0.0.0/0 is a valid network and it should be possible to query for the default route that way - similarly, `ip route get `::/0` also answers "need at least a destination address". For the same reason, it should also answer with the default route. - finally, `ip route get 0.0.0.0/1`, or any other non-0 netmask, answers with "local 0.0.0.0 dev lo src 127.0.0.1 uid 1000", which is simply wrong. 0.0.0.0/1 IS NOT routed via lo, and this query should answer with the most-specific route for 0.0.0.0/1 or the default if there is no such route. Interestingly, `ip route get 1.0.0.0/1`, while a query for the exact same subnet, actually gives the right route (in my case, the default route). The first two problems seem to be caused by this line in iproute2 error handling https://github.com/shemminger/iproute2/blob/master/ip/iproute.c#L1425, which is written without taking into consideration that netmasks of length 0 are actually valid; I have no idea where the last problem originates unfortunately. Thank you -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iproute2 depends on: ii debconf [debconf-2.0] 1.5.70 ii libc6 2.28-5 ii libcap21:2.25-1.2 ii libcap2-bin1:2.25-1.2 ii libdb5.3 5.3.28+dfsg1-0.2 ii libelf10.175-2 ii libmnl01.0.4-2 ii libselinux12.8-1+b1 ii libxtables12 1.8.2-3 Versions of packages iproute2 recommends: pn libatm1 Versions of packages iproute2 suggests: pn iproute2-doc -- debconf information: iproute2/setcaps: false
