NetBSD Problem Report #53705
From kre@munnari.OZ.AU Wed Nov 7 04:22:46 2018
Return-Path: <kre@munnari.OZ.AU>
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 2DFA27A1E1
for <gnats-bugs@gnats.NetBSD.org>; Wed, 7 Nov 2018 04:22:46 +0000 (UTC)
Message-Id: <201811070422.wA74MJ9X015812@jinx.noi.kre.to>
Date: Wed, 7 Nov 2018 11:22:19 +0700 (+07)
From: kre@munnari.OZ.AU
To: gnats-bugs@NetBSD.org
Subject: dhcpcd spams syslogd
X-Send-Pr-Version: 3.95
>Number: 53705
>Category: bin
>Synopsis: dhcpcd spams syslogd
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: roy
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Nov 07 04:25:00 +0000 2018
>Closed-Date: Sun May 05 09:56:46 +0000 2019
>Last-Modified: Sun May 05 09:56:46 +0000 2019
>Originator: Robert Elz
>Release: NetBSD 8.99.25
>Organization:
>Environment:
System: NetBSD jinx.noi.kre.to 8.99.25 NetBSD 8.99.25 (GENERIC) #0: Thu Sep 13 23:55:24 ICT 2018 kre@onyx.coe.psu.ac.th:/usr/obj/testing/amd64/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
I am at the IETF meeting in Bangkok. The network here is
configured to assign v6 addresses using SLAAC, but has
DHCPv6 configured to supply the "other" info (DNS servers,...)
This all works fine.
But it appears that twice (why twice) every 30 seconds or so
dhcpcd sends (as extracted from the syslog log file):
Nov 7 10:37:04 jinx dhcpcd[211]: iwm0: DHCPv6 REPLY: No addresses available for
this interface.
That's not true, dhcpcd has assigned an IPv6 address to
the interface (and v4) ...
iwm0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ssid ietf-legacy103
powersave off
bssid 70:70:8b:08:3d:0f chan 161
address: 34:13:e8:2f:bb:c4
media: IEEE802.11 autoselect (OFDM24 mode 11a)
status: active
inet 31.133.137.213/20 broadcast 31.133.143.255 flags 0x0
inet6 fe80::3613:e8ff:fe2f:bbc4%iwm0/64 flags 0x0 scopeid 0x2
inet6 2001:67c:370:128:1f6d:85c6:2217:387c/64 flags 0x0
It just did not come in the DHCPv6 reply packet, but via
SLAAC.
The errors reports repeat, two of them identified as being at the
same second, that pair seems to repeat every 30 secs.
>How-To-Repeat:
Come to the IETF meeting ...
Alternatively config DHCPv6 to not supply an address, and
use RAs from the local router to assign v6 addresses (but
keep the DHCPv6 server running. a DHCPv6-lite server will
work fine for this I think).
>Fix:
I added the following patch. It helps for me. However,
this is all wrong, and should not be installed in general.
Wrong with it:
1. it still logs the message occasionally, when ideally when
SLAAC is being used, this message should not appear at all,
it is confusing...
2. the coding is NetBSD specific ( uses __arraycount() )
3. it has a built in (inline code) 2 hour noise supression
which should not be needed at all if (1) above is addressed,
and if it is needed, should come from the config file (or
an option, or both) or at worst from a #define somewhere.
4. It assumes that the first DHCPv6 reply will not be seen
before 02:00 Jan 1, 1970, UTC (ie: that time(NULL) > 7200
always...) This one is unlikely to be a serious problem
until we invent time travel...
5. The "now = time(NULL)" line could be moved inside the
following "if", but that always seems to be true in
normal use, so really makes no difference in practice.
Index: src/dhcp6.c
===================================================================
RCS file: /cvsroot/src/external/bsd/dhcpcd/dist/src/dhcp6.c,v
retrieving revision 1.2
diff -u -r1.2 dhcp6.c
--- src/dhcp6.c 4 Nov 2018 16:30:28 -0000 1.2
+++ src/dhcp6.c 7 Nov 2018 04:02:28 -0000
@@ -43,6 +43,7 @@
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
+#include <time.h>
#define ELOOP_QUEUE 4
#include "config.h"
@@ -1916,6 +1917,8 @@
void * (*f)(void *, size_t, uint16_t, uint16_t *), *farg;
char buf[32], *sbuf;
const char *status;
+ time_t now;
+ static time_t reported[__arraycount(dhcp6_statuses)];
f = p ? dhcp6_findoption : dhcp6_findmoption;
if (p)
@@ -1936,6 +1939,13 @@
if (code == D6_STATUS_OK)
return 1;
+ now = time(NULL);
+ if (code < __arraycount(reported)) {
+ if (reported[code] + (3600 * 2) < now)
+ return -1;
+ reported[code] = now;
+ }
+
/* Anything after the code is a message. */
opt += sizeof(code);
mlen = opt_len - sizeof(code);
>Release-Note:
>Audit-Trail:
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Wed, 07 Nov 2018 11:51:39 +0700
I forgot to add the biggest problem with the patch ...
6. It should reset itself whenever the network link changes
(connecting to a new net) and should be interfacei
specific (having had a reply saying no addresses from
one interface when SLAAC is enabled there, doesn't
mean a message should not be logged for a different
interface where SLAAC is not available, but DHCPv6
refuses to assign an address, nor when the connection
moves to a different link for the same interface, again
where conditons are different)
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Wed, 07 Nov 2018 12:12:20 +0700
Aside from the missing "what's wrong" from the last message,
the patch was actually wrong, this is what it should be (inverted
time test...)
Index: dhcp6.c
===================================================================
RCS file: /cvsroot/src/external/bsd/dhcpcd/dist/src/dhcp6.c,v
retrieving revision 1.2
diff -u -r1.2 dhcp6.c
--- dhcp6.c 4 Nov 2018 16:30:28 -0000 1.2
+++ dhcp6.c 7 Nov 2018 05:10:57 -0000
@@ -43,6 +43,7 @@
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
+#include <time.h>
#define ELOOP_QUEUE 4
#include "config.h"
@@ -1916,6 +1917,8 @@
void * (*f)(void *, size_t, uint16_t, uint16_t *), *farg;
char buf[32], *sbuf;
const char *status;
+ time_t now;
+ static time_t reported[__arraycount(dhcp6_statuses)];
f = p ? dhcp6_findoption : dhcp6_findmoption;
if (p)
@@ -1936,6 +1939,13 @@
if (code == D6_STATUS_OK)
return 1;
+ now = time(NULL);
+ if (code < __arraycount(reported)) {
+ if (reported[code] + (3600 * 2) > now)
+ return -1;
+ reported[code] = now;
+ }
+
/* Anything after the code is a message. */
opt += sizeof(code);
mlen = opt_len - sizeof(code);
Responsible-Changed-From-To: bin-bug-people->roy
Responsible-Changed-By: bsiegert@NetBSD.org
Responsible-Changed-When: Mon, 08 Apr 2019 18:40:22 +0000
Responsible-Changed-Why:
Over to dhcpcd author.
From: Roy Marples <roy@marples.name>
To: gnats-bugs@NetBSD.org, Robert Elz <kre@munnari.OZ.AU>
Cc:
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Mon, 8 Apr 2019 21:26:09 +0100
So dhcpcd is logging the message sent in the DHCPv6 reply to say:
No addresses available for this interface.
In a stock config, dhcpcd will NOT request DHCPv6 unless a RA is found
with either the Managed or Other flag set.
dhcpcd will obey this flag.
So I'm guessing the RA is saying a Managed address is available but the
DHCPv6 server is saying otherwise - literally because dhcpcd doesn't
contain that string, so the DHCPv6 server sent it as a message.
This causes a DHCPv6 failure, so it aborts. However, the process will
restart when another RA is received with another DHCPv6 instruction.
In other words, dhcpcd is only spammy with a badly configured network
and is no different from a DHCPv4 server which NAKs the address you
request based on the address is originally offered.
I don't see anything to fix in dhcpcd here.
Roy
From: Robert Elz <kre@munnari.OZ.AU>
To: Roy Marples <roy@marples.name>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Tue, 09 Apr 2019 07:26:20 +0700
Date: Mon, 8 Apr 2019 21:26:09 +0100
From: Roy Marples <roy@marples.name>
Message-ID: <db03acd8-790b-6b8a-080f-52cf9185a0bc@marples.name>
| So dhcpcd is logging the message sent in the DHCPv6 reply to say:
| No addresses available for this interface.
Yes.
| In a stock config, dhcpcd will NOT request DHCPv6 unless a RA is found
| with either the Managed or Other flag set.
| dhcpcd will obey this flag.
That's all fine, and what is happening I believe, as:
06:48:32.492737 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24)
fe80::c0ea:b0ff:fe55:6190 > ff02::1: [icmp6 sum ok]
ICMP6, router advertisement, length 24
hop limit 64, Flags [managed], pref low, router lifetime 30s,
reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): c4:6e:1f:46:e5:cc
0x0000: c46e 1f46 e5cc
(that's an RA I captured relatively recently, but nothing relevant
would have changed since the PR was sent.) {I also manually altered the
line wrapping for this e-mail.]
| So I'm guessing the RA is saying a Managed address is available but the
| DHCPv6 server is saying otherwise - literally because dhcpcd doesn't
| contain that string, so the DHCPv6 server sent it as a message.
This is a commercial IPv6 enabled ADSL router, which has little in the
way of config in this area. It would also be the DHCPv6 server (as it
is the DHCPv4 server, NAT, ...)
The ADSL link it is connected to (currently) does not (currently) offer
IPv6, so the ADSL box isn't getting any v6 addresses to assign to the
downstream side.
It probably should not be sending RAs at all when that happens, and if
I could stop it, I would (it also means that my systems get an IPv6
default router installed, which is a nuisance for other reasons - and I
need to repeatedly "route delete -inet6 default").
I used to have dhcpcd configured to ignore v6 and only request v4, but
that didn't work too well when my system (laptop in this case) was
connected to a network which does (properly) support IPv6. So I enabled
v6 again, and I'd prefer to leave it that way so I don't forget to
enable it again the next time I'm on a v6 net.
| This causes a DHCPv6 failure, so it aborts. However, the process will
| restart when another RA is received with another DHCPv6 instruction.
All that is fine too.
| In other words, dhcpcd is only spammy with a badly configured network
| and is no different from a DHCPv4 server which NAKs the address you
| request based on the address is originally offered.
|
| I don't see anything to fix in dhcpcd here.
That's easy - in any of these situations, when the network is "broken",
it tends to stay broken. The v4 one can occasionally happen when
circumstances contrive such that the address that was available when
the discover was originally made is not still available later when the
client does the request. v6 should not have that problem.
However, on a v6 network, it is possible that a particular host is to
be denied v6 service, but for others, there are addresses available (that
is one reason you'd want to use managed addr assignemnt rather than
stateless autoconfig - so the network management can control which hosts
are offered v6 addresses. In that situation the network config isn't
broken, it is acting exactly as it should - the RA tells hosts to use
DHCPv6 to obtain an addr, they do, and then the DHCPv6 server actually
assigns addresses to those hosts management says should get them, and
not to those that should not. That's not what is happening in my case,
but the difference is irrelevant.
In any case, when an "error" like this occurs, and repeats, there's no
point continually telling the world about it every time - after it has
happened a couple of times, simply stop sending error reports until
something changes (until an address does get assigned, or until the
dhcpcd process restarts, or something).
kre
From: Roy Marples <roy@marples.name>
To: gnats-bugs@netbsd.org, roy@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, kre@munnari.OZ.AU
Cc:
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Tue, 9 Apr 2019 12:25:20 +0100
This is a multi-part message in MIME format.
--------------3F76325E9495F45A3CC31F97
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
On 09/04/2019 01:30, Robert Elz wrote:
> In any case, when an "error" like this occurs, and repeats, there's no
> point continually telling the world about it every time - after it has
> happened a couple of times, simply stop sending error reports until
> something changes (until an address does get assigned, or until the
> dhcpcd process restarts, or something).
Try the attached patch.
The only problem with it is that if dhcpcd is configured to request >1
IA and one of them gets an invalid status then dhcpcd will still be spammy.
Let me know if it helps your situation at least.
Roy
--------------3F76325E9495F45A3CC31F97
Content-Type: text/plain; charset=UTF-8;
name="dhcpcd-dhcpv6-spam.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="dhcpcd-dhcpv6-spam.diff"
ZGlmZiAtLWdpdCBhL3NyYy9kaGNwNi5jIGIvc3JjL2RoY3A2LmMKaW5kZXggY2MyMjY3ODcu
Ljk5YTQ1MmJiIDEwMDY0NAotLS0gYS9zcmMvZGhjcDYuYworKysgYi9zcmMvZGhjcDYuYwpA
QCAtMTkxMywxMyArMTkxMywxNiBAQCBzdGF0aWMgaW50CiBkaGNwNl9jaGVja3N0YXR1c29r
KGNvbnN0IHN0cnVjdCBpbnRlcmZhY2UgKmlmcCwKICAgICBzdHJ1Y3QgZGhjcDZfbWVzc2Fn
ZSAqbSwgdWludDhfdCAqcCwgc2l6ZV90IGxlbikKIHsKKwlzdHJ1Y3QgZGhjcDZfc3RhdGUg
KnN0YXRlOwogCXVpbnQ4X3QgKm9wdDsKIAl1aW50MTZfdCBvcHRfbGVuLCBjb2RlOwogCXNp
emVfdCBtbGVuOwogCXZvaWQgKiAoKmYpKHZvaWQgKiwgc2l6ZV90LCB1aW50MTZfdCwgdWlu
dDE2X3QgKiksICpmYXJnOwogCWNoYXIgYnVmWzMyXSwgKnNidWY7CiAJY29uc3QgY2hhciAq
c3RhdHVzOworCWxvZ2Z1bmNfdCAqbG9nZnVuYzsKIAorCXN0YXRlID0gRDZfU1RBVEUoaWZw
KTsKIAlmID0gcCA/IGRoY3A2X2ZpbmRvcHRpb24gOiBkaGNwNl9maW5kbW9wdGlvbjsKIAlp
ZiAocCkKIAkJZmFyZyA9IHA7CkBAIC0xOTI3LDYgKzE5MzAsNyBAQCBkaGNwNl9jaGVja3N0
YXR1c29rKGNvbnN0IHN0cnVjdCBpbnRlcmZhY2UgKmlmcCwKIAkJZmFyZyA9IG07CiAJaWYg
KChvcHQgPSBmKGZhcmcsIGxlbiwgRDZfT1BUSU9OX1NUQVRVU19DT0RFLCAmb3B0X2xlbikp
ID09IE5VTEwpIHsKIAkJLy9sb2dkZWJ1Z3goIiVzOiBubyBzdGF0dXMiLCBpZnAtPm5hbWUp
OworCQlzdGF0ZS0+bGVycm9yID0gMDsKIAkJcmV0dXJuIDA7CiAJfQogCkBAIC0xOTM2LDgg
KzE5NDAsMTAgQEAgZGhjcDZfY2hlY2tzdGF0dXNvayhjb25zdCBzdHJ1Y3QgaW50ZXJmYWNl
ICppZnAsCiAJfQogCW1lbWNweSgmY29kZSwgb3B0LCBzaXplb2YoY29kZSkpOwogCWNvZGUg
PSBudG9ocyhjb2RlKTsKLQlpZiAoY29kZSA9PSBENl9TVEFUVVNfT0spCisJaWYgKGNvZGUg
PT0gRDZfU1RBVFVTX09LKSB7CisJCXN0YXRlLT5sZXJyb3IgPSAwOwogCQlyZXR1cm4gMTsK
Kwl9CiAKIAkvKiBBbnl0aGluZyBhZnRlciB0aGUgY29kZSBpcyBhIG1lc3NhZ2UuICovCiAJ
b3B0ICs9IHNpemVvZihjb2RlKTsKQEAgLTE5NjAsOCArMTk2NiwxMyBAQCBkaGNwNl9jaGVj
a3N0YXR1c29rKGNvbnN0IHN0cnVjdCBpbnRlcmZhY2UgKmlmcCwKIAkJc3RhdHVzID0gc2J1
ZjsKIAl9CiAKLQlsb2dlcnJ4KCIlczogREhDUHY2IFJFUExZOiAlcyIsIGlmcC0+bmFtZSwg
c3RhdHVzKTsKKwlpZiAoc3RhdGUtPmxlcnJvciA9PSBjb2RlIHx8IHN0YXRlLT5zdGF0ZSA9
PSBESDZTX0lOSVQpCisJCWxvZ2Z1bmMgPSBsb2dkZWJ1Z3g7CisJZWxzZQorCQlsb2dmdW5j
ID0gbG9nZXJyeDsKKwlsb2dmdW5jKCIlczogREhDUHY2IFJFUExZOiAlcyIsIGlmcC0+bmFt
ZSwgc3RhdHVzKTsKIAlmcmVlKHNidWYpOworCXN0YXRlLT5sZXJyb3IgPSBjb2RlOwogCXJl
dHVybiAtMTsKIH0KIApAQCAtMzc5NCw2ICszODA1LDcgQEAgZGhjcDZfc3RhcnQoc3RydWN0
IGludGVyZmFjZSAqaWZwLCBlbnVtIERINlMgaW5pdF9zdGF0ZSkKIAogZ29nb2dvOgogCXN0
YXRlLT5zdGF0ZSA9IGluaXRfc3RhdGU7CisJc3RhdGUtPmxlcnJvciA9IDA7CiAJZGhjcF9z
ZXRfbGVhc2VmaWxlKHN0YXRlLT5sZWFzZWZpbGUsIHNpemVvZihzdGF0ZS0+bGVhc2VmaWxl
KSwKIAkgICAgQUZfSU5FVDYsIGlmcCk7CiAJaWYgKGlwdjZfbGlua2xvY2FsKGlmcCkgPT0g
TlVMTCkgewpAQCAtMzgxMywxOCArMzgyNSwyMCBAQCBkaGNwNl9yZWJvb3Qoc3RydWN0IGlu
dGVyZmFjZSAqaWZwKQogCXN0cnVjdCBkaGNwNl9zdGF0ZSAqc3RhdGU7CiAKIAlzdGF0ZSA9
IEQ2X1NUQVRFKGlmcCk7Ci0JaWYgKHN0YXRlKSB7Ci0JCXN3aXRjaCAoc3RhdGUtPnN0YXRl
KSB7Ci0JCWNhc2UgREg2U19CT1VORDoKLQkJCWRoY3A2X3N0YXJ0cmViaW5kKGlmcCk7Ci0J
CQlicmVhazsKLQkJY2FzZSBESDZTX0lORk9STUVEOgotCQkJZGhjcDZfc3RhcnRpbmZvcm0o
aWZwKTsKLQkJCWJyZWFrOwotCQlkZWZhdWx0OgotCQkJZGhjcDZfc3RhcnRkaXNjb3Zlcihp
ZnApOwotCQkJYnJlYWs7Ci0JCX0KKwlpZiAoc3RhdGUgPT0gTlVMTCkKKwkJcmV0dXJuOwor
CisJc3RhdGUtPmxlcnJvciA9IDA7CisJc3dpdGNoIChzdGF0ZS0+c3RhdGUpIHsKKwljYXNl
IERINlNfQk9VTkQ6CisJCWRoY3A2X3N0YXJ0cmViaW5kKGlmcCk7CisJCWJyZWFrOworCWNh
c2UgREg2U19JTkZPUk1FRDoKKwkJZGhjcDZfc3RhcnRpbmZvcm0oaWZwKTsKKwkJYnJlYWs7
CisJZGVmYXVsdDoKKwkJZGhjcDZfc3RhcnRkaXNjb3ZlcihpZnApOworCQlicmVhazsKIAl9
CiB9CiAKZGlmZiAtLWdpdCBhL3NyYy9kaGNwNi5oIGIvc3JjL2RoY3A2LmgKaW5kZXggZTFh
MGEzNzQuLmE2NzA1NjZkIDEwMDY0NAotLS0gYS9zcmMvZGhjcDYuaAorKysgYi9zcmMvZGhj
cDYuaApAQCAtMjA2LDcgKzIwNiw3IEBAIHN0cnVjdCBkaGNwNl9zdGF0ZSB7CiAJLyogVGhl
ICszIGlzIGZvciB0aGUgcG9zc2libGUgLnBkIGV4dGVuc2lvbiBmb3IgcHJlZml4IGRlbGVn
YXRpb24gKi8KIAljaGFyIGxlYXNlZmlsZVtzaXplb2YoTEVBU0VGSUxFNikgKyBJRl9OQU1F
U0laRSArIChJRl9TU0lETEVOICogNCkgKzNdOwogCWNvbnN0IGNoYXIgKnJlYXNvbjsKLQor
CXVpbnQxNl90IGxlcnJvcjsgLyogTGFzdCBlcnJvciByZWNlaXZlZCBmcm9tIERIQ1B2NiBy
ZXBseS4gKi8KIAlzdHJ1Y3QgYXV0aHN0YXRlIGF1dGg7CiB9OwogCg==
--------------3F76325E9495F45A3CC31F97--
From: Robert Elz <kre@munnari.OZ.AU>
To: Roy Marples <roy@marples.name>
Cc: gnats-bugs@netbsd.org, roy@netbsd.org
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Tue, 09 Apr 2019 20:25:52 +0700
Date: Tue, 9 Apr 2019 12:25:20 +0100
From: Roy Marples <roy@marples.name>
Message-ID: <ed9915cf-81ca-0693-9618-95d824fa0dd8@marples.name>
| Try the attached patch.
Thanks, I will do that tomorrow and let you know.
kre
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Wed, 10 Apr 2019 11:10:48 +0700
Date: Tue, 9 Apr 2019 13:30:02 +0000 (UTC)
From: Robert Elz <kre@munnari.OZ.AU>
Message-ID: <20190409133002.9288B7A1D7@mollari.NetBSD.org>
| Thanks, I will do that tomorrow and let you know.
Actually, it turns out I can't. I had forgotten this PR
completely, and didn't remember the details.
What I did now, was first to disable the patch I had installed
last November, while at the IETF (where the problem actually
occurred) and upgrade to the current version of dhcpcd as well
(I had not touched it since then) - and run that version for a
while (without the new patch) so I would have a baseline for
comparison.
That one did not misbehave at all.
What is happening is that there is no functioning DHCPv6 server
at all, so I assume that the router is smart enough not to bother
running one when it has no available addresses to assign. I can
observe dhcpcd sending DHCPv6 solicit packets:
08:53:33.231618 IP6 (hlim 1, next-header UDP (17) payload length: 146)
fe80::3613:e8ff:fe2f:bbc4.dhcpv6-client > ff02::1:2.dhcpv6-server:
[udp sum ok] dhcp6 solicit
(xid=605158 (client-ID hwaddr/time type 1 time 570821790 3413e82fbbc4)
(elapsed-time 1625) (vendor-class) (rapid-commit)
(IA_NA IAID:3895442372 T1:0 T2:0) (Client-FQDN) (reconfigure-accept)
(option-request DNS-server DNS-search-list Client-FQDN opt_82 opt_83))
but there is never a reply. Nothing gets logged to syslog (so there
is nothing to suppress.)
I am (kind of obviously) not still connected to the Bangkok IETF
network, so I cannot test the scenario where there was a problem.
I also don't (any more) have a packet dump from it, but I must have
done at the time, as I see I said in the PR that the RA packets
indicated stateless addr config should happen (and it did), and that
a DHCP6 server was available for the remaining config. (Some of
the networks there were v6 only).
I can confirm that the patch applies (but you knew that) and does
no harm (you knew that as well...) - also that it looks like the
right thing to do (much better than the patch I had been using, the
2nd one from the PR - which also did no harm, but was not really
correct, as the PR pointed out.)
kre
ps: one thing that would be good though, and which would help, would
be for dhcpcd to avoid adding a default v6 route if there are no
available v6 addresses (link local excepted, as they can't use the
route anyway). Until now I wasn't sure if dhcpcd was adding that,
or the kernel, when an RA arrives. But I see ...
Apr 10 08:53:16 jinx dhcpcd[14261]: iwm0: Router Advertisement from fe80::c0ea:b0ff:fe55:6190
Apr 10 08:53:16 jinx dhcpcd[14261]: iwm0: adding default route via fe80::c0ea:b0ff:fe55:6190
I am not sure why that causes problems, with no available useful v6
addr any attempt to send to destination v6 addrs should immediately
fail - but it does make a difference, stuff like connections
to *.netbsd.org go much slower (that is, connect much slower) when
that default route exists - after I delete it, the v6 attempt immediately
fails, and fall back to v4 happens immediately (and that works). The
ideal solution would be for my ISP to support v6, but that one I cannot
control..... (and yes, I know I could set up a tunnel).
From: Roy Marples <roy@marples.name>
To: gnats-bugs@netbsd.org, roy@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, kre@munnari.OZ.AU
Cc:
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Wed, 10 Apr 2019 14:13:07 +0100
On 10/04/2019 05:15, Robert Elz wrote:
> ps: one thing that would be good though, and which would
> help, would
> be for dhcpcd to avoid adding a default v6 route if there are no
> available v6 addresses (link local excepted, as they can't use the
> route anyway). Until now I wasn't sure if dhcpcd was adding that,
> or the kernel, when an RA arrives. But I see ...
>
> Apr 10 08:53:16 jinx dhcpcd[14261]: iwm0: Router Advertisement from fe80::c0ea:b0ff:fe55:6190
> Apr 10 08:53:16 jinx dhcpcd[14261]: iwm0: adding default route via fe80::c0ea:b0ff:fe55:6190
>
> I am not sure why that causes problems, with no available useful v6
> addr any attempt to send to destination v6 addrs should immediately
> fail - but it does make a difference, stuff like connections
> to *.netbsd.org go much slower (that is, connect much slower) when
> that default route exists - after I delete it, the v6 attempt immediately
> fails, and fall back to v4 happens immediately (and that works). The
> ideal solution would be for my ISP to support v6, but that one I cannot
> control..... (and yes, I know I could set up a tunnel).
That's a totally different issue.
Please create a new PR for it because there really is no right way of
solving this.
Roy
From: Robert Elz <kre@munnari.OZ.AU>
To: Roy Marples <roy@marples.name>
Cc: gnats-bugs@netbsd.org, roy@netbsd.org
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Wed, 10 Apr 2019 21:52:22 +0700
Date: Wed, 10 Apr 2019 14:13:07 +0100
From: Roy Marples <roy@marples.name>
Message-ID: <4f01bc7e-fcfb-e097-0d6c-4573ba6cc8fb@marples.name>
| That's a totally different issue.
Yes, understood and agreed. That's why that was just a postscript
added on to the end of the real message.
| Please create a new PR for it because there really is no right way of
| solving this.
If that latter part is correct (depending on just which "this" is in
question) a PR would be a bit pointless, right? No point asking for
changes if there is no way to do it.
(And if "this" was the "my ISP should support IPv6, but doesn't" then
I agree, there certainly does not appear to be any good solution, as
most of the ISP's customers have no idea at all what IP is, let alone
which version does what, or how.)
But if you, or someone really want a PR on the "default v6 route exists
and causes connection delays when there are no available v6 global addresses"
issue, then sure, I can do that. It will take a while while I collect
some packet traces, etc, and tomorrow I am unlikely to have much time,
but sometime over the weekend I can do that ... if you really want it.
kre
From: Roy Marples <roy@marples.name>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: gnats-bugs@netbsd.org, roy@netbsd.org
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Wed, 10 Apr 2019 15:55:54 +0100
On 10/04/2019 15:52, Robert Elz wrote:
> Date: Wed, 10 Apr 2019 14:13:07 +0100
> From: Roy Marples <roy@marples.name>
> Message-ID: <4f01bc7e-fcfb-e097-0d6c-4573ba6cc8fb@marples.name>
>
> | That's a totally different issue.
>
> Yes, understood and agreed. That's why that was just a postscript
> added on to the end of the real message.
>
> | Please create a new PR for it because there really is no right way of
> | solving this.
>
> If that latter part is correct (depending on just which "this" is in
> question) a PR would be a bit pointless, right? No point asking for
> changes if there is no way to do it.
>
> (And if "this" was the "my ISP should support IPv6, but doesn't" then
> I agree, there certainly does not appear to be any good solution, as
> most of the ISP's customers have no idea at all what IP is, let alone
> which version does what, or how.)
>
> But if you, or someone really want a PR on the "default v6 route exists
> and causes connection delays when there are no available v6 global addresses"
> issue, then sure, I can do that. It will take a while while I collect
> some packet traces, etc, and tomorrow I am unlikely to have much time,
> but sometime over the weekend I can do that ... if you really want it.
No traceroutes needed.
Just say RA received with no prefixes marked as generated a SLAAC
address, no DHCPv6 server available to hand out any IA and no static
IPv6 configuration.
I think that describes your situation.
Roy
From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc: roy@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
kre@munnari.OZ.AU
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Wed, 10 Apr 2019 17:08:28 +0200
On Wed, Apr 10, 2019 at 01:15:01PM +0000, Roy Marples wrote:
> Please create a new PR for it because there really is no right way of
> solving this.
"Ignore the DHCPv6 bit for RAs from the following address" would allow
to avoid the problem, wouldn't it?
Joerg
From: Robert Elz <kre@munnari.OZ.AU>
To: Roy Marples <roy@marples.name>
Cc: gnats-bugs@netbsd.org, roy@netbsd.org
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Wed, 10 Apr 2019 22:58:49 +0700
Date: Wed, 10 Apr 2019 15:55:54 +0100
From: Roy Marples <roy@marples.name>
Message-ID: <ae9db2eb-941e-40cd-83bb-da95dbef5466@marples.name>
| Just say RA received with no prefixes marked as generated a SLAAC
| address, no DHCPv6 server available to hand out any IA and no static
| IPv6 configuration.
| I think that describes your situation.
It does, I think, but I much prefer to know what is actually happening,
if not why or how to fix it, before sending bug reports.
kre
From: Roy Marples <roy@marples.name>
To: Joerg Sonnenberger <joerg@bec.de>, gnats-bugs@netbsd.org
Cc: roy@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
kre@munnari.OZ.AU
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Wed, 10 Apr 2019 18:08:16 +0100
On 10/04/2019 16:08, Joerg Sonnenberger wrote:
> On Wed, Apr 10, 2019 at 01:15:01PM +0000, Roy Marples wrote:
>> Please create a new PR for it because there really is no right way of
>> solving this.
>
> "Ignore the DHCPv6 bit for RAs from the following address" would allow
> to avoid the problem, wouldn't it?
No, the issue Robert is seeing here is that the RA says "I'm a default
router, get an address via DHCPv6" and the DHCPv6 server says "I have no
address for you".
Thus he just ends up with a default inet6 route, no addresses other than
the default link local address and as such gets timeouts when something
wants to use inet6 - such as a cvs up.
This is noted in RFC7084:
https://tools.ietf.org/html/rfc7084#section-3.2.1
At the time of this writing, several host implementations do not
handle the case where they have an IPv6 address configured and no
IPv6 connectivity, either because the address itself has a limited
topological reachability (e.g., ULA) or because the IPv6 CE router is
not connected to the IPv6 network on its WAN interface. To support
host implementations that do not handle multihoming in a multi-prefix
environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not,
as detailed in the requirements below, advertise itself as a default
router on the LAN interface(s) when it does not have IPv6
connectivity on the WAN interface or when it is not provisioned with
IPv6 addresses. For local IPv6 communication, the mechanisms
specified in [RFC4191] are used.
https://tools.ietf.org/html/rfc7084#section-4.3
ULA-5: An IPv6 CE router MUST NOT advertise itself as a default
router with a Router Lifetime greater than zero whenever all
of its configured and delegated prefixes are ULA prefixes.
The other issue is that we don't do anything with ICMP unreachable which
the router should have sent back anyway.
Roy
From: Robert Elz <kre@munnari.OZ.AU>
To: Roy Marples <roy@marples.name>
Cc: Joerg Sonnenberger <joerg@bec.de>, gnats-bugs@netbsd.org, roy@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/53705: dhcpcd spams syslogd
Date: Thu, 11 Apr 2019 04:41:14 +0700
Date: Wed, 10 Apr 2019 18:08:16 +0100
From: Roy Marples <roy@marples.name>
Message-ID: <ab97601f-aef1-c194-ef85-1cabee2fbec7@marples.name>
| > "Ignore the DHCPv6 bit for RAs from the following address" would allow
| > to avoid the problem, wouldn't it?
Apart from anything else, I would not want to configure that, as I live
in hope that my ISP will decide to support IPv6 one day (I know they won't
tell me if they do...) and that router will suddenly start having v6
addresses available for me.
That's why I don't simply config it to disable v6 - that I believe I can do.
| No, the issue Robert is seeing here is that the RA says "I'm a default
| router, get an address via DHCPv6" and the DHCPv6 server says "I have no
| address for you".
Actually, the DHCPv6 server just doesn't reply at all, but the effect
there is the same. It was the IETF DHCPv6 server that sent the negative
reply (but it was also enabling stateless autoconfig, so there I did have
a v6 addr - sometimes only a v6 addr, no (non-link local) v4 addr).
Since I have never seen this particular router in a situation where it
does have v6 addresses to assign, I don't know whether the DHCPv6 server
in it would come alive then, or whether it would start advertising
prefixes (just 1 I assume...), and enable stateless autoconfig.
| Thus he just ends up with a default inet6 route, no addresses other than
| the default link local address and as such gets timeouts when something
| wants to use inet6 - such as a cvs up.
Exactly.
| This is noted in RFC7084:
Yes. I doubt that I have the only router around which fails to
comply withh an RFC. What's more, the one I have probably re-dates
that RFC (for all I know, it might be the inspiration for that RFC).
It was one of the first (cheap) v6 supporting ADSL routers around,
and runs firmware of a version which kind of suggests that it was
last updated 2013 or 2014 (that RFC is November 2013) - and as best
I can tell, no-one has ever been able to find a firmware update for
it. (It is also based upon GPL'd code - ie: linux - at least in
part, so who knows on the code quality ... but this aside, it does
work in general.) It will be upgraded soonish, that version doesn't
support any of the newer WiFi standards (no 802.11ac/ad etc) - which
means probably late this year.
| The other issue is that we don't do anything with ICMP unreachable which
| the router should have sent back anyway.
One of the reasons I don't want to submit a PR for this right now is
that I want to find out whether some kind of ICMPv6 packet gets returned
or not - plus discover for sure that NetBSD is sending a v6 TCP SYN (or
attempting to) and if so, from what v6 addr. While it should not be
happening (resolv.conf contains no v6 addr of any DNS server) it is also
possible (I suppose) that the delay is caused by the DNS query for the
server (I don't run a local caching server on my laptop) rather than the
initial SYN attempt. Answers to these questions are all avaoiable, once
I have time to go look for them.
kre
From: "Roy Marples" <roy@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53705 CVS commit: src/external/bsd/dhcpcd/dist
Date: Wed, 17 Apr 2019 23:33:09 +0000
Module Name: src
Committed By: roy
Date: Wed Apr 17 23:33:09 UTC 2019
Update of /cvsroot/src/external/bsd/dhcpcd/dist
In directory ivanova.netbsd.org:/tmp/cvs-serv11850
Log Message:
Import dhcpcd-7.2.0 with the following changes:
* BSD: PF_LINK sockets now closed when no longer needed
* BSD: Fix detecting interface for scoped routes
* script: Allow "" to mean /dev/null
* script: Add static routers and routes to env
* DHCP: outbound interface is no longer dictated with IP_PKTINFO
* DHCP: BPF sockets now closed when no longer needed
* DHCPv6: Allow nooption dhcp6_unicast to work
* DHCPv6: Don't spam syslog if we always get the same error
* route: Log pid which deleted routes of interest
This release fixes PR bin/53705.
Status:
Vendor Tag: roy
Release Tags: dhcpcd-7-2-0
U src/external/bsd/dhcpcd/dist/.gitignore
U src/external/bsd/dhcpcd/dist/BUILDING.md
U src/external/bsd/dhcpcd/dist/LICENSE
U src/external/bsd/dhcpcd/dist/Makefile
U src/external/bsd/dhcpcd/dist/Makefile.inc
U src/external/bsd/dhcpcd/dist/README.md
U src/external/bsd/dhcpcd/dist/config-null.mk
U src/external/bsd/dhcpcd/dist/configure
U src/external/bsd/dhcpcd/dist/iconfig.mk
U src/external/bsd/dhcpcd/dist/compat/_strtoi.h
U src/external/bsd/dhcpcd/dist/compat/arc4random.c
U src/external/bsd/dhcpcd/dist/compat/arc4random.h
U src/external/bsd/dhcpcd/dist/compat/bitops.h
U src/external/bsd/dhcpcd/dist/compat/queue.h
U src/external/bsd/dhcpcd/dist/compat/arc4random_uniform.c
U src/external/bsd/dhcpcd/dist/compat/arc4random_uniform.h
U src/external/bsd/dhcpcd/dist/compat/reallocarray.c
U src/external/bsd/dhcpcd/dist/compat/dprintf.c
U src/external/bsd/dhcpcd/dist/compat/dprintf.h
U src/external/bsd/dhcpcd/dist/compat/endian.h
U src/external/bsd/dhcpcd/dist/compat/pidfile.c
U src/external/bsd/dhcpcd/dist/compat/pidfile.h
U src/external/bsd/dhcpcd/dist/compat/reallocarray.h
U src/external/bsd/dhcpcd/dist/compat/strlcpy.c
U src/external/bsd/dhcpcd/dist/compat/strlcpy.h
U src/external/bsd/dhcpcd/dist/compat/strtoi.c
U src/external/bsd/dhcpcd/dist/compat/strtoi.h
U src/external/bsd/dhcpcd/dist/compat/strtou.c
U src/external/bsd/dhcpcd/dist/compat/crypt/hmac.c
U src/external/bsd/dhcpcd/dist/compat/crypt/hmac.h
U src/external/bsd/dhcpcd/dist/compat/crypt/md5.c
U src/external/bsd/dhcpcd/dist/compat/crypt/md5.h
U src/external/bsd/dhcpcd/dist/compat/crypt/sha256.c
U src/external/bsd/dhcpcd/dist/compat/crypt/sha256.h
C src/external/bsd/dhcpcd/dist/src/dhcp.c
U src/external/bsd/dhcpcd/dist/src/GNUmakefile
U src/external/bsd/dhcpcd/dist/src/Makefile
U src/external/bsd/dhcpcd/dist/src/arp.c
U src/external/bsd/dhcpcd/dist/src/arp.h
U src/external/bsd/dhcpcd/dist/src/auth.c
U src/external/bsd/dhcpcd/dist/src/auth.h
U src/external/bsd/dhcpcd/dist/src/bpf.c
U src/external/bsd/dhcpcd/dist/src/bpf.h
U src/external/bsd/dhcpcd/dist/src/common.c
U src/external/bsd/dhcpcd/dist/src/common.h
U src/external/bsd/dhcpcd/dist/src/control.c
U src/external/bsd/dhcpcd/dist/src/control.h
U src/external/bsd/dhcpcd/dist/src/defs.h
U src/external/bsd/dhcpcd/dist/src/dev.c
U src/external/bsd/dhcpcd/dist/src/dev.h
U src/external/bsd/dhcpcd/dist/src/dhcp-common.c
U src/external/bsd/dhcpcd/dist/src/dhcp-common.h
U src/external/bsd/dhcpcd/dist/src/dhcp.h
C src/external/bsd/dhcpcd/dist/src/dhcp6.c
U src/external/bsd/dhcpcd/dist/src/dhcp6.h
U src/external/bsd/dhcpcd/dist/src/dhcpcd.conf.5.in
U src/external/bsd/dhcpcd/dist/src/dhcpcd.8.in
U src/external/bsd/dhcpcd/dist/src/dhcpcd-definitions-small.conf
U src/external/bsd/dhcpcd/dist/src/dhcpcd-definitions.conf
U src/external/bsd/dhcpcd/dist/src/dhcpcd-embedded.c.in
U src/external/bsd/dhcpcd/dist/src/dhcpcd-embedded.h.in
C src/external/bsd/dhcpcd/dist/src/dhcpcd.c
U src/external/bsd/dhcpcd/dist/src/dhcpcd.conf
U src/external/bsd/dhcpcd/dist/src/genembedc
U src/external/bsd/dhcpcd/dist/src/dhcpcd.h
U src/external/bsd/dhcpcd/dist/src/duid.c
U src/external/bsd/dhcpcd/dist/src/duid.h
U src/external/bsd/dhcpcd/dist/src/eloop.c
U src/external/bsd/dhcpcd/dist/src/eloop.h
U src/external/bsd/dhcpcd/dist/src/if-linux-wext.c
U src/external/bsd/dhcpcd/dist/src/genembedh
C src/external/bsd/dhcpcd/dist/src/if-bsd.c
U src/external/bsd/dhcpcd/dist/src/if-linux.c
C src/external/bsd/dhcpcd/dist/src/if-options.c
U src/external/bsd/dhcpcd/dist/src/if-options.h
U src/external/bsd/dhcpcd/dist/src/if-sun.c
U src/external/bsd/dhcpcd/dist/src/if.c
U src/external/bsd/dhcpcd/dist/src/if.h
U src/external/bsd/dhcpcd/dist/src/ipv4.c
U src/external/bsd/dhcpcd/dist/src/ipv4.h
U src/external/bsd/dhcpcd/dist/src/ipv4ll.c
U src/external/bsd/dhcpcd/dist/src/ipv4ll.h
U src/external/bsd/dhcpcd/dist/src/ipv6.c
U src/external/bsd/dhcpcd/dist/src/ipv6.h
C src/external/bsd/dhcpcd/dist/src/ipv6nd.c
U src/external/bsd/dhcpcd/dist/src/ipv6nd.h
U src/external/bsd/dhcpcd/dist/src/logerr.c
U src/external/bsd/dhcpcd/dist/src/logerr.h
U src/external/bsd/dhcpcd/dist/src/route.c
U src/external/bsd/dhcpcd/dist/src/route.h
U src/external/bsd/dhcpcd/dist/src/sa.c
U src/external/bsd/dhcpcd/dist/src/sa.h
U src/external/bsd/dhcpcd/dist/src/script.c
U src/external/bsd/dhcpcd/dist/src/script.h
U src/external/bsd/dhcpcd/dist/src/dev/Makefile
U src/external/bsd/dhcpcd/dist/src/dev/udev.c
U src/external/bsd/dhcpcd/dist/hooks/15-timezone
U src/external/bsd/dhcpcd/dist/hooks/01-test
U src/external/bsd/dhcpcd/dist/hooks/02-dump
U src/external/bsd/dhcpcd/dist/hooks/dhcpcd-run-hooks.8.in
U src/external/bsd/dhcpcd/dist/hooks/10-wpa_supplicant
U src/external/bsd/dhcpcd/dist/hooks/20-resolv.conf
U src/external/bsd/dhcpcd/dist/hooks/29-lookup-hostname
U src/external/bsd/dhcpcd/dist/hooks/30-hostname
U src/external/bsd/dhcpcd/dist/hooks/50-dhcpcd-compat
U src/external/bsd/dhcpcd/dist/hooks/50-ntp.conf
U src/external/bsd/dhcpcd/dist/hooks/50-yp.conf
U src/external/bsd/dhcpcd/dist/hooks/50-ypbind.in
U src/external/bsd/dhcpcd/dist/hooks/Makefile
U src/external/bsd/dhcpcd/dist/hooks/dhcpcd-run-hooks.in
U src/external/bsd/dhcpcd/dist/tests/Makefile
U src/external/bsd/dhcpcd/dist/tests/crypt/test_hmac_md5.c
U src/external/bsd/dhcpcd/dist/tests/crypt/.gitignore
U src/external/bsd/dhcpcd/dist/tests/crypt/GNUmakefile
U src/external/bsd/dhcpcd/dist/tests/crypt/Makefile
U src/external/bsd/dhcpcd/dist/tests/crypt/README.md
U src/external/bsd/dhcpcd/dist/tests/crypt/run-test.c
U src/external/bsd/dhcpcd/dist/tests/crypt/test.h
U src/external/bsd/dhcpcd/dist/tests/eloop-bench/eloop-bench.c
U src/external/bsd/dhcpcd/dist/tests/eloop-bench/.gitignore
U src/external/bsd/dhcpcd/dist/tests/eloop-bench/Makefile
U src/external/bsd/dhcpcd/dist/tests/eloop-bench/README.md
6 conflicts created by this import.
Use the following command to help the merge:
cvs checkout -jroy:yesterday -jroy src/external/bsd/dhcpcd/dist
State-Changed-From-To: open->closed
State-Changed-By: roy@NetBSD.org
State-Changed-When: Sun, 05 May 2019 09:56:46 +0000
State-Changed-Why:
Has been pulled up to -8
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home