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: gnats-bugs%netbsd.org@localhost
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@localhost>
     Message-ID:  <20190409133002.9288B7A1D7%mollari.NetBSD.org@localhost>
 
   |  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).