iproute2-4.16.0 doesn't accept fe80::1 as gateway anymore: > # ip route add default via ff80::1 > Error: inet address is expected rather than "ff80::1". I noticed this on reboot, my /etc/conf.d/net has > routes_eth0=" > default via a.b.c.d > default via fe80::1 > " On start: > * Bringing up interface eth0 > * Caching network module dependencies > * Waiting for carrier (10 seconds) .... > [...] > * Adding routes > * default via a.b.c.d src Y.Y.Y.Y ... > [ ok ] > [ ok ] > * default via fe80::1 ... > Error: inet address is expected rather than "fe80::1". Works with <iproute2-4.16.0.
> git bisect start > # good: [50b8a842e8c098cddb213f5b3076526df88826e8] v4.15.0 > git bisect good 50b8a842e8c098cddb213f5b3076526df88826e8 > # bad: [4b6c4177ee66421770f0bbcc765c29135e44d921] v4.16.0 > git bisect bad 4b6c4177ee66421770f0bbcc765c29135e44d921 > # bad: [5f4892e2c8d4fb22118713e0c83290b352fe0e34] rdma: Make visible the number of arguments > git bisect bad 5f4892e2c8d4fb22118713e0c83290b352fe0e34 > # good: [8c75f69411bc8c3affe5d173afcf981d15f5da15] Merge branch 'master' into net-next > git bisect good 8c75f69411bc8c3affe5d173afcf981d15f5da15 > # bad: [27c523e209ab956ff269afec68c6e744e7f5edb6] utils: Introduce get_addr_rta() and inet_addr_match_rta() > git bisect bad 27c523e209ab956ff269afec68c6e744e7f5edb6 > # bad: [d0bcedd549566a87354aa804df3be6be80681ee9] tc: introduce tc_qdisc_block_exists helper > git bisect bad d0bcedd549566a87354aa804df3be6be80681ee9 > # bad: [6c4b672738acf680ee98c10e79a52a8dede5f9a6] iplink_geneve: Get rid of inet_get_addr() > git bisect bad 6c4b672738acf680ee98c10e79a52a8dede5f9a6 > # bad: [93fa12418dc6f5943692250244be303bb162175b] utils: Always specify family and ->bytelen in get_prefix_1() > git bisect bad 93fa12418dc6f5943692250244be303bb162175b > # good: [f2522007d8fee924cb098b4afc8af16f2b25829f] utils: Always specify family for address in get_addr_1() > git bisect good f2522007d8fee924cb098b4afc8af16f2b25829f > # first bad commit: [93fa12418dc6f5943692250244be303bb162175b] utils: Always specify family and ->bytelen in get_prefix_1() > From 93fa12418dc6f5943692250244be303bb162175b Mon Sep 17 00:00:00 2001 > From: Serhey Popovych > Date: Thu, 18 Jan 2018 20:13:43 +0200 > Subject: utils: Always specify family and ->bytelen in get_prefix_1() > > Handle default/all/any special case in get_addr_1() to setup > ->family and ->bytelen correctly. > > Make get_addr_1() return ->bitlen == -2 instead of -1 to > distinguish default/all/any special case from the rest: > it is safe because all callers check ->bitlen < 0, not > explicit value -1. > > Reduce intendation by one level and get rid of goto/label > to make code more readable. > > Signed-off-by: Serhey Popovych > Signed-off-by: David Ahern https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=93fa12418dc6f5943692250244be303bb162175b I contacted upstream: https://marc.info/?l=linux-netdev&m=152349984014876&w=2
Note: netifrc can already handle that, see https://gitweb.gentoo.org/proj/netifrc.git/tree/init.d/net.lo.in However, documentation (https://gitweb.gentoo.org/proj/netifrc.git/tree/doc/net.example.Linux.in#n97) should be updated. Should be > #routes_eth0="-4 default via 192.168.0.1 > #-4 10.0.0.0/8 via 192.168.0.1 > #-6 ::/0"
1. You seem to be mixing ff80 and fe80. Please stop. 2. This does look like a regression that -4/-6 are now required. I think iproute2 should be fixed, not the netifrc docs saying to add -4/-6 prefixes.
> 2. This does look like a regression that -4/-6 are now required. I think > iproute2 should be fixed, not the netifrc docs saying to add -4/-6 prefixes. Upstream acknowledged that the behavior change wasn't intentional and is currently looking into this. But can you please explain why netifrc documentation shouldn't be updated if netifrc already supports family specification?
(In reply to Thomas Deutschmann from comment #4) > > 2. This does look like a regression that -4/-6 are now required. I think > > iproute2 should be fixed, not the netifrc docs saying to add -4/-6 prefixes. > Upstream acknowledged that the behavior change wasn't intentional and is > currently looking into this. But can you please explain why netifrc > documentation shouldn't be updated if netifrc already supports family > specification? Netifrc should accept ANY input that is valid for iproute2. If you find a case to the contrary, I'm very interested. The documentation should reflect that fact, and not try to suggest that -4/-6 is required in any way.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1b28b8a212eb9657e45a074da43dfa8c8721c409 commit 1b28b8a212eb9657e45a074da43dfa8c8721c409 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-04-15 19:23:39 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-04-15 19:23:53 +0000 sys-apps/iproute2: Restore auto inet family support Closes: https://bugs.gentoo.org/652986 Package-Manager: Portage-2.3.28, Repoman-2.3.9 .../files/iproute2-4.16.0-keep-family.patch | 25 ++++ sys-apps/iproute2/iproute2-4.16.0-r1.ebuild | 152 +++++++++++++++++++++ 2 files changed, 177 insertions(+)
