Re: bin/53705: dhcpcd spams syslogd

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

    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