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: gnats-bugs%NetBSD.org@localhost
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@localhost>
     Message-ID:  <db03acd8-790b-6b8a-080f-52cf9185a0bc%marples.name@localhost>
 
   | 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