Bug#921737: iproute2: `ip route get` problems with 0.0.0.0 and ::

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#921737: iproute2: `ip route get` problems with 0.0.0.0 and ::

wxcafe
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  libcap2                1:2.25-1.2
ii  libcap2-bin            1:2.25-1.2
ii  libdb5.3               5.3.28+dfsg1-0.2
ii  libelf1                0.175-2
ii  libmnl0                1.0.4-2
ii  libselinux1            2.8-1+b1
ii  libxtables12           1.8.2-3

Versions of packages iproute2 recommends:
pn  libatm1  <none>

Versions of packages iproute2 suggests:
pn  iproute2-doc  <none>

-- debconf information:
  iproute2/setcaps: false

Reply | Threaded
Open this post in threaded view
|

Bug#921737: iproute2: `ip route get` problems with 0.0.0.0 and ::

Luca Boccassi-3
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' <repeats 1020 times>}

(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' <repeats 1018 times>}

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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#921737: iproute2: `ip route get` problems with 0.0.0.0 and ::

Luca Boccassi-3
In reply to this post by wxcafe
On Tue, 2019-02-12 at 17:15 +0000, Clément Hertling (Wxcafé) wrote:

> Hey,
>
> February 11, 2019 6:27 PM, "Luca Boccassi" <[hidden email]> 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' <repeats 1020 times>}
> >
> > (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' <repeats 1018
> > 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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#921737: iproute2: `ip route get` problems with 0.0.0.0 and ::

wxcafe
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" <[hidden email]> wrote:

> On Tue, 2019-02-12 at 17:15 +0000, Clément Hertling (Wxcafé) wrote:
>
>> Hey,
>>
>> February 11, 2019 6:27 PM, "Luca Boccassi" <[hidden email]> 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' <repeats 1020 times>}
>>
>> (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' <repeats 1018
>> 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