NetBSD Problem Report #54997
From www@netbsd.org Fri Feb 21 18:25:48 2020
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 898D91A9213
for <gnats-bugs@gnats.NetBSD.org>; Fri, 21 Feb 2020 18:25:48 +0000 (UTC)
Message-Id: <20200221182547.6ECDC1A9217@mollari.NetBSD.org>
Date: Fri, 21 Feb 2020 18:25:47 +0000 (UTC)
From: rcbixler@nyx.net
Reply-To: rcbixler@nyx.net
To: gnats-bugs@NetBSD.org
Subject: dhcpcd does not set IPv6 default route
X-Send-Pr-Version: www-1.0
>Number: 54997
>Category: bin
>Synopsis: dhcpcd does not set IPv6 default route
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Feb 21 18:30:00 +0000 2020
>Closed-Date: Mon Apr 20 16:49:46 +0000 2020
>Last-Modified: Mon Apr 20 16:49:46 +0000 2020
>Originator: Roy Bixler
>Release: 9
>Organization:
>Environment:
NetBSD localhost 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC 2020 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
I have dhcpcd set to YES in my rc.conf. Networking is set up fine for IPv4 but remote IPv6 connections don't work on startup. Local IPv6 connections work fine. The only error I see in the log is:
Feb 21 17:46:53 localhost dhcpcd[276]: axe0: failed to request information
Doing a bit of debug, I see no default router set:
localhost# ndp -r
In the routing table, there is one set, but it is not the active router and does not forward packets.
>How-To-Repeat:
Here are my rc.conf settings:
dhcpcd=YES
dhcpcd_flags="-qM axe0"
I notice remote IPv6 connections don't work:
localhost$ telnet yahoo.com www
Trying 2001:4998:44:41d::3...
telnet: Connect to address 2001:4998:44:41d::3: : Connection timed out
>Fix:
No fix, but I found a workaround. First, I do:
localhost# ndp -i axe0 accept_rtadv
linkmtu=0, maxmtu=0, curhlim=64, basereachable=30s0ms, reachable=39s, retrans=1s0ms
Flags: nud accept_rtadv override_rtadv
Wait a bit for "ndp -r" to show a router, then do "ndp -H". Then the telnet command above connects immediately.
>Release-Note:
>Audit-Trail:
From: Roy Bixler <rcbixler@nyx.net>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/54997: dhcpcd does not set IPv6 default route
Date: Mon, 24 Feb 2020 08:06:54 -0700
I tried again with my workaround and found that it didn't work
immediately, but it worked the second time. I think what had to
happen was that ndp's route table had to receive the advertisement for
the high priority router, which is the active one. The lower priority
ones are not active.
This bug is similar to #52554, which I filed when NetBSD-8 came out.
I don't have this problem with Linux or NetBSD 8.1.
--
Roy Bixler <rcbixler@nyx.net>
"The fundamental principle of science, the definition almost, is this: the
sole test of the validity of any idea is experiment."
-- Richard P. Feynman
From: Roy Bixler <rcbixler@nyx.net>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/54997: dhcpcd does not set IPv6 default route
Date: Fri, 6 Mar 2020 09:53:09 -0700
This patch seems to fix the problem (otherwise, the behaviour I observe
is that the first router advertisement received remains first):
--- ipv6nd.c.orig 2020-02-27 16:50:52.476425174 +0000
+++ ipv6nd.c 2020-03-06 16:43:18.730737671 +0000
@@ -595,7 +595,7 @@
if (ipv6nd_rtpref(ra1) < ipv6nd_rtpref(ra2))
continue;
/* All things being equal, prefer older routers. */
- if (timespeccmp(&ra1->acquired, &ra2->acquired, >=))
+ if ((ipv6nd_rtpref(ra1) == ipv6nd_rtpref(ra2)) && (timespeccmp(&ra1->acquired, &ra2->acquired, >=)))
continue;
TAILQ_INSERT_BEFORE(ra2, ra1, next);
break;
--
Roy Bixler <rcbixler@nyx.net>
"The fundamental principle of science, the definition almost, is this: the
sole test of the validity of any idea is experiment."
-- Richard P. Feynman
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54997 CVS commit: [netbsd-9] src
Date: Sun, 12 Apr 2020 08:29:41 +0000
Module Name: src
Committed By: martin
Date: Sun Apr 12 08:29:41 UTC 2020
Modified Files:
src/doc [netbsd-9]: 3RDPARTY
src/external/bsd/dhcpcd/dist/src [netbsd-9]: arp.c arp.h bpf.c bpf.h
common.h defs.h dhcp.c dhcp6.c dhcp6.h dhcpcd.c eloop.h if-bsd.c
if-options.c if.c if.h ipv4ll.c ipv6.c ipv6nd.c ipv6nd.h logerr.c
logerr.h
Log Message:
Apply patch, requested by roy in ticket #825:
external/bsd/dhcpcd/dist/src/arp.c (apply patch)
external/bsd/dhcpcd/dist/src/arp.h (apply patch)
external/bsd/dhcpcd/dist/src/bpf.c (apply patch)
external/bsd/dhcpcd/dist/src/bpf.h (apply patch)
external/bsd/dhcpcd/dist/src/common.h (apply patch)
external/bsd/dhcpcd/dist/src/defs.h (apply patch)
external/bsd/dhcpcd/dist/src/dhcp.c (apply patch)
external/bsd/dhcpcd/dist/src/dhcp6.c (apply patch)
external/bsd/dhcpcd/dist/src/dhcp6.h (apply patch)
external/bsd/dhcpcd/dist/src/dhcpcd.c (apply patch)
external/bsd/dhcpcd/dist/src/eloop.h (apply patch)
external/bsd/dhcpcd/dist/src/if-bsd.c (apply patch)
external/bsd/dhcpcd/dist/src/if-options.c (apply patch)
external/bsd/dhcpcd/dist/src/if.c (apply patch)
external/bsd/dhcpcd/dist/src/if.h (apply patch)
external/bsd/dhcpcd/dist/src/ipv4ll.c (apply patch)
external/bsd/dhcpcd/dist/src/ipv6.c (apply patch)
external/bsd/dhcpcd/dist/src/ipv6nd.c (apply patch)
external/bsd/dhcpcd/dist/src/ipv6nd.h (apply patch)
external/bsd/dhcpcd/dist/src/logerr.c (apply patch)
external/bsd/dhcpcd/dist/src/logerr.h (apply patch)
doc/3RDPARTY (apply patch)
Update to dhcpcd-8.1.7 which fixes the following issues:
* Decode interface complex interface names eth0.100:2 eth0i100:2.
This allows us to ignore some virtual interfaces by default
* ARP: Report L2 header address on conflict for more clarity
* DHCP: Support jumbo frames (untested)
* DHCP6: Clean up old lease on failure to confirm/rebind, etc
* RA: Prefer older routers - fixes PR bin/54997
* INET6: Obscure prefixes are now calculated correctly
* macro logerr commands to allow an alternative logger
To generate a diff of this commit:
cvs rdiff -u -r1.1640.2.12 -r1.1640.2.13 src/doc/3RDPARTY
cvs rdiff -u -r1.1.1.11.2.2 -r1.1.1.11.2.3 \
src/external/bsd/dhcpcd/dist/src/arp.c
cvs rdiff -u -r1.1.1.8.2.1 -r1.1.1.8.2.2 \
src/external/bsd/dhcpcd/dist/src/arp.h \
src/external/bsd/dhcpcd/dist/src/common.h
cvs rdiff -u -r1.11.2.2 -r1.11.2.3 src/external/bsd/dhcpcd/dist/src/bpf.c
cvs rdiff -u -r1.1.1.6.2.1 -r1.1.1.6.2.2 \
src/external/bsd/dhcpcd/dist/src/bpf.h
cvs rdiff -u -r1.1.1.25.2.6 -r1.1.1.25.2.7 \
src/external/bsd/dhcpcd/dist/src/defs.h
cvs rdiff -u -r1.23.2.6 -r1.23.2.7 src/external/bsd/dhcpcd/dist/src/dhcp.c
cvs rdiff -u -r1.11.2.4 -r1.11.2.5 src/external/bsd/dhcpcd/dist/src/dhcp6.c
cvs rdiff -u -r1.1.1.12 -r1.1.1.12.2.1 \
src/external/bsd/dhcpcd/dist/src/dhcp6.h
cvs rdiff -u -r1.23.2.5 -r1.23.2.6 src/external/bsd/dhcpcd/dist/src/dhcpcd.c
cvs rdiff -u -r1.1.1.5.2.1 -r1.1.1.5.2.2 \
src/external/bsd/dhcpcd/dist/src/eloop.h
cvs rdiff -u -r1.10.2.4 -r1.10.2.5 src/external/bsd/dhcpcd/dist/src/if-bsd.c
cvs rdiff -u -r1.16.2.3 -r1.16.2.4 \
src/external/bsd/dhcpcd/dist/src/if-options.c
cvs rdiff -u -r1.1.1.14.2.3 -r1.1.1.14.2.4 \
src/external/bsd/dhcpcd/dist/src/if.c
cvs rdiff -u -r1.1.1.10.2.3 -r1.1.1.10.2.4 \
src/external/bsd/dhcpcd/dist/src/if.h
cvs rdiff -u -r1.1.1.9.2.1 -r1.1.1.9.2.2 \
src/external/bsd/dhcpcd/dist/src/ipv4ll.c
cvs rdiff -u -r1.3.2.5 -r1.3.2.6 src/external/bsd/dhcpcd/dist/src/ipv6.c
cvs rdiff -u -r1.10.2.5 -r1.10.2.6 src/external/bsd/dhcpcd/dist/src/ipv6nd.c
cvs rdiff -u -r1.1.1.10.2.2 -r1.1.1.10.2.3 \
src/external/bsd/dhcpcd/dist/src/ipv6nd.h
cvs rdiff -u -r1.2 -r1.2.2.1 src/external/bsd/dhcpcd/dist/src/logerr.c
cvs rdiff -u -r1.1.1.5 -r1.1.1.5.2.1 \
src/external/bsd/dhcpcd/dist/src/logerr.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: maya@NetBSD.org
State-Changed-When: Sun, 12 Apr 2020 11:22:26 +0000
State-Changed-Why:
does the backport help with the issue?
From: "Kimmo Suominen" <kim@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54997 CVS commit: src/sys/netinet6
Date: Mon, 13 Apr 2020 14:04:27 +0000
Module Name: src
Committed By: kim
Date: Mon Apr 13 14:04:27 UTC 2020
Modified Files:
src/sys/netinet6: nd6_rtr.c
Log Message:
Fix default route selection
The primary issue was that in revision 1.79 a check was added in the
nd6_defrouter_select() search loop to ignore the entry if RA processing
is enabled on its interface. In practice this results in all entries
being ignored.
This fix reverses the condition, so that an entry is ignored when RA
processing is NOT enabled on its interface. Further, the entry is
only ignored for being selected as the default router. The currently
installed router must be identified regardless of the (current) status
of its interface, so that we can delete the route before installing a
new one.
I also added error logging when adding or deleting a route fails. This
should help the administrator (or kernel developer) in noticing possible
problems.
Finally, if deleting a route fails, the corresponding default route
entry no longer has its "installed" flag cleared, so that deletion will
be retried. At a minimum, this will cause repeated messages about the
failed deletion as opposed to only getting repeated messages about the
installation of a new default route failing.
Fixes PR kern/55091 and also PR bin/54997 as far as the behaviour
observed with ndp(8).
To generate a diff of this commit:
cvs rdiff -u -r1.147 -r1.148 src/sys/netinet6/nd6_rtr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54997 CVS commit: [netbsd-9] src/sys/netinet6
Date: Tue, 14 Apr 2020 17:26:22 +0000
Module Name: src
Committed By: martin
Date: Tue Apr 14 17:26:22 UTC 2020
Modified Files:
src/sys/netinet6 [netbsd-9]: nd6_rtr.c
Log Message:
Pull up following revision(s) (requested by kim in ticket #834):
sys/netinet6/nd6_rtr.c: revision 1.148
Fix default route selection
The primary issue was that in revision 1.79 a check was added in the
nd6_defrouter_select() search loop to ignore the entry if RA processing
is enabled on its interface. In practice this results in all entries
being ignored.
This fix reverses the condition, so that an entry is ignored when RA
processing is NOT enabled on its interface. Further, the entry is
only ignored for being selected as the default router. The currently
installed router must be identified regardless of the (current) status
of its interface, so that we can delete the route before installing a
new one.
I also added error logging when adding or deleting a route fails. This
should help the administrator (or kernel developer) in noticing possible
problems.
Finally, if deleting a route fails, the corresponding default route
entry no longer has its "installed" flag cleared, so that deletion will
be retried. At a minimum, this will cause repeated messages about the
failed deletion as opposed to only getting repeated messages about the
installation of a new default route failing.
Fixes PR kern/55091 and also PR bin/54997 as far as the behaviour
observed with ndp(8).
To generate a diff of this commit:
cvs rdiff -u -r1.145 -r1.145.2.1 src/sys/netinet6/nd6_rtr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54997 CVS commit: [netbsd-8] src/sys/netinet6
Date: Wed, 15 Apr 2020 14:27:54 +0000
Module Name: src
Committed By: martin
Date: Wed Apr 15 14:27:54 UTC 2020
Modified Files:
src/sys/netinet6 [netbsd-8]: nd6_rtr.c
Log Message:
Pull up following revision(s) (requested by kim in ticket #1531):
sys/netinet6/nd6_rtr.c: revision 1.148
Fix default route selection
The primary issue was that in revision 1.79 a check was added in the
nd6_defrouter_select() search loop to ignore the entry if RA processing
is enabled on its interface. In practice this results in all entries
being ignored.
This fix reverses the condition, so that an entry is ignored when RA
processing is NOT enabled on its interface. Further, the entry is
only ignored for being selected as the default router. The currently
installed router must be identified regardless of the (current) status
of its interface, so that we can delete the route before installing a
new one.
I also added error logging when adding or deleting a route fails. This
should help the administrator (or kernel developer) in noticing possible
problems.
Finally, if deleting a route fails, the corresponding default route
entry no longer has its "installed" flag cleared, so that deletion will
be retried. At a minimum, this will cause repeated messages about the
failed deletion as opposed to only getting repeated messages about the
installation of a new default route failing.
Fixes PR kern/55091 and also PR bin/54997 as far as the behaviour
observed with ndp(8).
To generate a diff of this commit:
cvs rdiff -u -r1.135.6.4 -r1.135.6.5 src/sys/netinet6/nd6_rtr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54997 CVS commit: [netbsd-7] src/sys/netinet6
Date: Wed, 15 Apr 2020 14:52:29 +0000
Module Name: src
Committed By: martin
Date: Wed Apr 15 14:52:29 UTC 2020
Modified Files:
src/sys/netinet6 [netbsd-7]: nd6_rtr.c
Log Message:
Pull up following revision(s) (requested by kim in ticket #1727):
sys/netinet6/nd6_rtr.c: revision 1.148 (via patch)
Fix default route selection
The primary issue was that in revision 1.79 a check was added in the
nd6_defrouter_select() search loop to ignore the entry if RA processing
is enabled on its interface. In practice this results in all entries
being ignored.
This fix reverses the condition, so that an entry is ignored when RA
processing is NOT enabled on its interface. Further, the entry is
only ignored for being selected as the default router. The currently
installed router must be identified regardless of the (current) status
of its interface, so that we can delete the route before installing a
new one.
I also added error logging when adding or deleting a route fails. This
should help the administrator (or kernel developer) in noticing possible
problems.
Finally, if deleting a route fails, the corresponding default route
entry no longer has its "installed" flag cleared, so that deletion will
be retried. At a minimum, this will cause repeated messages about the
failed deletion as opposed to only getting repeated messages about the
installation of a new default route failing.
Fixes PR kern/55091 and also PR bin/54997 as far as the behaviour
observed with ndp(8).
To generate a diff of this commit:
cvs rdiff -u -r1.93.2.3 -r1.93.2.4 src/sys/netinet6/nd6_rtr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54997 CVS commit: [netbsd-7-1] src/sys/netinet6
Date: Wed, 15 Apr 2020 14:58:41 +0000
Module Name: src
Committed By: martin
Date: Wed Apr 15 14:58:41 UTC 2020
Modified Files:
src/sys/netinet6 [netbsd-7-1]: nd6_rtr.c
Log Message:
Pull up following revision(s) (requested by kim in ticket #1727):
sys/netinet6/nd6_rtr.c: revision 1.148 (via patch)
Fix default route selection
The primary issue was that in revision 1.79 a check was added in the
nd6_defrouter_select() search loop to ignore the entry if RA processing
is enabled on its interface. In practice this results in all entries
being ignored.
This fix reverses the condition, so that an entry is ignored when RA
processing is NOT enabled on its interface. Further, the entry is
only ignored for being selected as the default router. The currently
installed router must be identified regardless of the (current) status
of its interface, so that we can delete the route before installing a
new one.
I also added error logging when adding or deleting a route fails. This
should help the administrator (or kernel developer) in noticing possible
problems.
Finally, if deleting a route fails, the corresponding default route
entry no longer has its "installed" flag cleared, so that deletion will
be retried. At a minimum, this will cause repeated messages about the
failed deletion as opposed to only getting repeated messages about the
installation of a new default route failing.
Fixes PR kern/55091 and also PR bin/54997 as far as the behaviour
observed with ndp(8).
To generate a diff of this commit:
cvs rdiff -u -r1.93.2.3 -r1.93.2.3.6.1 src/sys/netinet6/nd6_rtr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54997 CVS commit: [netbsd-7-0] src/sys/netinet6
Date: Wed, 15 Apr 2020 14:59:33 +0000
Module Name: src
Committed By: martin
Date: Wed Apr 15 14:59:33 UTC 2020
Modified Files:
src/sys/netinet6 [netbsd-7-0]: nd6_rtr.c
Log Message:
Pull up following revision(s) (requested by kim in ticket #1727):
sys/netinet6/nd6_rtr.c: revision 1.148 (via patch)
Fix default route selection
The primary issue was that in revision 1.79 a check was added in the
nd6_defrouter_select() search loop to ignore the entry if RA processing
is enabled on its interface. In practice this results in all entries
being ignored.
This fix reverses the condition, so that an entry is ignored when RA
processing is NOT enabled on its interface. Further, the entry is
only ignored for being selected as the default router. The currently
installed router must be identified regardless of the (current) status
of its interface, so that we can delete the route before installing a
new one.
I also added error logging when adding or deleting a route fails. This
should help the administrator (or kernel developer) in noticing possible
problems.
Finally, if deleting a route fails, the corresponding default route
entry no longer has its "installed" flag cleared, so that deletion will
be retried. At a minimum, this will cause repeated messages about the
failed deletion as opposed to only getting repeated messages about the
installation of a new default route failing.
Fixes PR kern/55091 and also PR bin/54997 as far as the behaviour
observed with ndp(8).
To generate a diff of this commit:
cvs rdiff -u -r1.93.2.3 -r1.93.2.3.2.1 src/sys/netinet6/nd6_rtr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Roy Bixler <rcbixler@nyx.net>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, maya@NetBSD.org
Subject: Re: bin/54997 (dhcpcd does not set IPv6 default route)
Date: Mon, 20 Apr 2020 07:26:32 -0600
On Sun, Apr 12, 2020 at 11:22:27AM +0000, maya@NetBSD.org wrote:
> Synopsis: dhcpcd does not set IPv6 default route
>
> State-Changed-From-To: open->feedback
> State-Changed-By: maya@NetBSD.org
> State-Changed-When: Sun, 12 Apr 2020 11:22:26 +0000
> State-Changed-Why:
> does the backport help with the issue?
I updated to a 9.0_STABLE build from the 16th, where dhcpcd reports
itself as version 8.1.8. The problem appears fixed.
--
Roy Bixler <rcbixler@nyx.net>
"The fundamental principle of science, the definition almost, is this: the
sole test of the validity of any idea is experiment."
-- Richard P. Feynman
State-Changed-From-To: feedback->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Mon, 20 Apr 2020 16:49:46 +0000
State-Changed-Why:
Reported fixed, thanks for the report!
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home