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