Re: bin/53705: dhcpcd spams syslogd

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/53705; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Roy Marples <roy%marples.name@localhost>
Cc: Joerg Sonnenberger <joerg%bec.de@localhost>, gnats-bugs%netbsd.org@localhost, roy%netbsd.org@localhost,
        gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
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@localhost>
     Message-ID:  <ab97601f-aef1-c194-ef85-1cabee2fbec7%marples.name@localhost>
 
   | > "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