dhcpcd-discuss

On Fri, 13 Nov 2015 09:38:38 +0000
Roy Marples <roy@xxxxxxxxxxxx> wrote:

> Hi SillySausage (love the nick!)
> 
> This is quite a long post, so I've trimmed stuff I won't talk about
> util the dhcpcd issue is resolved.
> 
> On 12/11/2015 16:19, sillysausage wrote:
> > gateway:~# cat /etc/dhcpcd.conf
> > # Enable extra debugging
> > debug
> > 
> > # Allow users of this group to interact with dhcpcd via the control
> > # socket.
> > #controlgroup wheel
> > 
> > # Inform the DHCP server of our hostname for DDNS.
> > gateway
> 
> This should not be gateway, it should be hostname.
> gateway does something different, go read the fine dhcpcd.conf man
> page ;)
> 
> It does't affect your issue though.
> 

Oh yeah, that's supposed to be "hostname gateway" yeah, my gateway's
hostname is gateway, I thought it was funny at the time. The flavour in
my household is dragonlance cities:

http://dragonlancenexus.com/lexicon/index.php?title=Gateway_(Abanasinia)

> > 
> > # Use the hardware address of the interface for the Client ID.
> > #clientid
> > # or
> > # Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as
> > # per RFC4361. Some non-RFC compliant DHCP servers do not reply with
> > # this set. In this case, comment out duid and enable clientid
> > above. duid
> > 
> > # Persist interface configuration when dhcpcd exits.
> > persistent
> > 
> > # Rapid commit support.
> > # Safe to enable by default because it requires the equivalent
> > option # set on the server to actually work.
> > option rapid_commit
> > 
> > # A list of options to request from the DHCP server.
> > option domain_name_servers, domain_name, domain_search, host_name
> > option classless_static_routes
> > 
> > # Most distributions have NTP support.
> > option ntp_servers
> > # Respect the network MTU.
> > # Some interface drivers reset when changing the MTU so disabled by
> > # default.
> > #option interface_mtu
> > 
> > # A ServerID is required by RFC2131.
> > require dhcp_server_identifier
> > 
> > # Generate Stable Private IPv6 Addresses instead of hardware based
> > # ones
> > slaac private
> > 
> > # A hook script is provided to lookup the hostname if not set by the
> > # DHCP server, but it should not be run by default.
> > nohook lookup-hostname
> > 
> > # IPv6 Only
> > ipv6only
> > 
> > # Disable solicitations on all interfaces
> > noipv6rs
> > 
> > # Wait for IP before forking to background
> > waitip 6
> > 
> > # Don't install any default routes.
> > # PPP has already set a default route
> > nogateway
> 
> This conflicts with the gateway option you set above ;)
> 

Fixed. I found I lost IPv6 connectivity when I two default routes, one
by PPP and one by DHCPv6.

> > # Don't touch DNS
> > nohook resolv.conf
> 
> Have you considered a resolvconf solution for DNS management?
> I ship openresolv which is quite powerful and if you wish to persue
> this start a new thread on this list.
> 

I choose not to use my ISP's DNS servers. I have unbound running
locally which forwards all requests to DNSCrypt over the VPN.

http://wiki.alpinelinux.org/wiki/Linux_Router_with_VPN_on_a_Raspberry_Pi#Unbound_DNS_forwarder_with_dnscrypt

> > # Use the interface connected to WAN
> > interface eth1
> >     ipv6rs # enable routing solicitation get the default IPv6 route
> 

This was also a problem. The WAN interface should have been ppp0, not
eth1.

> You get a devault route via ppp0, this maybe the problem you're
> facing.
> 
> >     iaid 1
> >     ia_pd 1/::/64 eth0/1/64
> 
> This looks fine.
> 
> > Before I start dhcpcd:
> > 
> > gateway:~# ip -f inet6 addr
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 
> >     inet6 ::1/128 scope host 
> >        valid_lft forever preferred_lft forever
> > 
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> >     inet6 2001:0db8:1234:0001::1/64 scope global 
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::ba27:ebff:fe63:46b5/64 scope link 
> >        valid_lft forever preferred_lft forever
> > 
> > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> >     inet6 2001:0db8:1234:0000::2/64 scope global 
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::8249:71ff:fe12:3879/64 scope link 
> >        valid_lft forever preferred_lft forever
> > 
> > 4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qlen 3
> >     inet6 2001:0db8:16:606:98ea:4841:1037:349f/64 scope global
> > mngtmpaddr dynamic valid_lft 5930sec preferred_lft 5930sec
> >     inet6 fe80::98ea:4841:1037:349f/10 scope link 
> >        valid_lft forever preferred_lft forever
> > 
> > gateway:~# ip -f inet6 route
> > 2001:0db8:16:606::/64 dev ppp0  proto kernel  metric 256  expires
> > 5897sec 2001:0db8:1234:0000::/64 dev eth1  proto kernel  metric 256 
> > 2001:0db8:1234:0001::/64 dev eth0  proto kernel  metric 256 
> > fe80::/64 dev eth1  proto kernel  metric 256 
> > fe80::/64 dev eth0  proto kernel  metric 256 
> > fe80::/10 dev ppp0  metric 1 
> > fe80::/10 dev ppp0  proto kernel  metric 256 
> > default via fe80::222:55ff:fe75:ec00 dev ppp0  proto ra  metric 1024
> > expires 5837sec hoplimit 64
> 
> ^^ ppp0 already has a defualt route,
> 

Yes that would have been added when pppd started.

> > gateway daemon.debug dhcpcd[1956]: dhcpcd-6.9.0 starting
> 
> Please upgrade to 6.9.3
> 
> > gateway daemon.debug dhcpcd[1956]: eth1: broadcasting SOLICIT6 (xid
> > 0x6c386c), next in 0.9 seconds
> > gateway daemon.err dhcpcd[1956]: eth1: DHCPv6 REPLY: 
> 
> The problem here is that dhcpcd has an error (even in 6.9.3) where it
> does not show the failure code as a message from the server if there
> is no textual message included in the reply.
> 
> Apply this patch to 6.9.3:
> http://roy.marples.name/projects/dhcpcd/vpatch?from=d8f8999d1efb4376c29d7d2c13b0de1c6da52226&to=90e878f68804cb98e03e90b33233e607e6541358
> 
> Then dhcpcd will be more descriptive about the error and we can
> proceed from there.
> 

Done and pushed patch to my distribution:

http://git.alpinelinux.org/cgit/aports/commit/?id=ddea03d3