On Tue, 2019-02-12 at 17:15 +0000, Clément Hertling (Wxcafé) wrote:
> Hey,
>
> February 11, 2019 6:27 PM, "Luca Boccassi" <bl...@debian.org> 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
Description: This is a digitally signed message part
