dhcpcd-discuss

Hello.

So I took another look at the topics we discussed in the last two mails.

As for the logs, the message "setsockopt: SO_REUSEPORT: Protocol not 
available" is part of any output, serial console or systemd journal.
Those marker numbers always appear on the serial console, too. In 
systemd's journal they don't appear if dhcpcd is launched manually from 
CLI. They do if it gets started by a systemd unit - but only from 
dhcpcd's second start after booting onwards. Plus, the majority only 
appears after network connections were made and there's a lot of 
duplicates, e. g.
     Jun 24 13:30:54 ct1 systemd[1]: Starting \
     Schnittstellenkonfiguration für Routerbetrieb
     version 6.3.2 starting
     version 6.3.2 starting
     wlan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' PREINIT
     wlan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' PREINIT
     wlan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' CARRIER
     wlan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' CARRIER
     DUID <DUID>
     wlan0: IAID <IAID>
     wlan0: soliciting an IPv6 router
     wlan0: sending Router Solicitation
     DUID <DUID>
     wlan0: IAID <IAID>
     wlan0: soliciting an IPv6 router
     wlan0: sending Router Solicitation
     wlan0: reading lease `/var/lib/dhcpcd/dhcpcd-wlan0.lease'
     wlan0: reading lease `/var/lib/dhcpcd/dhcpcd-wlan0.lease'
     wlan0: rebinding lease of <IPv4 address>
     wlan0: sending REQUEST (xid 0x8ab24c55), next in 4.7 seconds
     wlan0: Router Advertisement from <link local address upstream router>
     wlan0: adding address <IPv6 address>/64
     wlan0: vltime 7200 seconds, pltime 1057 seconds
     wlan0: waiting for Router Advertisement DAD to complete
*     setsockopt: SO_REUSEPORT: Protocol not available
     wlan0: requesting DHCPv6 information
     wlan0: delaying INFORM6 (xid 0x09b88e), next in 0.1 seconds
     wlan0: acknowledged <IPv4 address> from <IPv4 address>
     wlan0: rebinding lease of <IPv4 address>
     wlan0: sending REQUEST (xid 0x8ab24c55), next in 4.7 seconds
     wlan0: Router Advertisement from <link local address upstream router>
     wlan0: adding address <IPv6 address>/64
     wlan0: vltime 7200 seconds, pltime 1057 seconds
     wlan0: waiting for Router Advertisement DAD to complete
     0
     1
     2
     3
*     setsockopt: SO_REUSEPORT: Protocol not available
     4
     5
     wlan0: requesting DHCPv6 information
     wlan0: delaying INFORM6 (xid 0x09b88e), next in 0.1 seconds
     wlan0: acknowledged <IPv4 address> from <IPv4 address>
     wlan0: checking for <IPv4 address>
     wlan0: checking for <IPv4 address>
     wlan0: sending ARP probe (1 of 3), next in 1.3 seconds
     wlan0: sending ARP probe (1 of 3), next in 1.3 seconds
To be honest I have no clue what's going on here. And maybe I was 
confusing something and had always been looking just on the serial 
console so far.
But to me it doesn't seem to be worth further tracking as starting 
dhcpcd manually and tracing the serial console is a reliable way to get 
all the output that's needed. If you should disagree about this, let me 
know.

Next there was the question why the problem arises running the old 3.4 
Kernel on ARM but not the recent 3.14/3.15 on x86.
Indeed on both platforms glibc and dhcpcd are compiled against API 
headers 3.14.1. This could imho be interpreted like recent Kernel + 
headers >= 3.9 (and <= <Version of running Kernel>) ==> no problems as 
well as headers >=  3.9 and Kernel < 3.9 (ARM) ==> problem as the API 
headers make dhcpcd think that SO_REUSEPORT is available which it isn't.
The only thing to remain confusing to me is your note " ... to 
accomodate dodgy Linux headers". This had made me think that problems 
actually have to be expected always on Linux for now. But doesn't it 
seem that the reason is in the too recent API headers, and not in any 
general Kernel feature?

I'd like to add some remarks on 6.4.0.

First that new 'slaac private' option.

Both the sysctl parameters autoconf and accept_ra are set to 0, but on 
exit only the latter is reset.
If dhcpcd using the option gets started on an interface that is up and 
has already been assigned both a MAC-derived global unicast and link 
local address by SLAAC, a global unicast address corresponding to 
RFC7217 is added while the two existing addresses persist. But if it 
gets launched on an interface that's down / unconfigured dhcpcd assigns 
one RFC7217 global unicast address and one RFC7217 and MAC-derived link 
local address respectively.
As for all this I'm wondering whether its intentional.

If the option is used when dhcpcd gets started after SLAAC the IPv6 
default route is duplicated. On the Cubietruck the preexisting routes of 
global unicast addresses are duplicated, too, e. g.
     <prefix>::/64 dev wlan0  proto kernel  metric 256 expires 7137sec
     <prefix>::/64 dev wlan0  proto kernel  metric 303  mtu 1492
     unreachable fe80::/64 dev lo  proto kernel  metric 256  error -101
     fe80::/64 dev wlan0  proto kernel  metric 256
     default via <link local address upstream router> dev wlan0  metric \
     303  mtu 1492
     default via <link local address upstream router> dev wlan0  proto \
     kernel  metric 1024  expires 1737sec
where the lines comprising "expires..." belong to SLAAC and disappear 
after a while.

On the Cubietruck running the corresponding sun7i Kernel a RFC7217 
global unicast address is never established. Apart from this it behaves 
as described above.

Btw. I'd find it useful if the stanza about the option in man 
dhcpcd.conf would refer to RFC7217. I for one first thought "private" 
was corresponding to Privacy Extensions...

Independent from slaac private / hwaddr there's a new error message on 
the said ARM platform
     if_addaddress6: Invalid argument
If dhcpcd just runs as client it is among the Router Advertisement 
messages and doesn't seem to indicate anything harmful.
     wlan0: Router Advertisement from <link local address upstream \
     router>
     wlan0: adding address <global unicast address>
*     if_addaddress6: Invalid argument
     wlan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
     wlan0: requesting DHCPv6 information
     wlan0: delaying INFORM6 (xid 0xf7625c), next in 0.4 seconds
     wlan0: broadcasting INFORM6 (xid 0xf7625c), next in 1.0 seconds

But it also appears when Prefix Delegation is attempted which 
unfortunately doesn't work with 6.4.0 either on this platform. E. g. 
using wlan0 as upstream and eth0 as downstream interface journal shows
     version 6.4.0 starting
     wlan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' PREINIT
     eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' PREINIT
     DUID <DUID>
     wlan0: IAID <IAID wlan0>
     wlan0: IAID 00:00:00:00
     setsockopt: SO_REUSEPORT: Protocol not available
     wlan0: reading lease `/var/lib/dhcpcd/dhcpcd-wlan0.lease6'
     wlan0: confirming Prefix Delegation
     wlan0: delaying REBIND6 (xid 0x5990bd), next in 0.2 seconds
     wlan0: delaying DHCP for 0.9 seconds
     eth0: IAID <IAID eth0>
     wlan0: broadcasting REBIND6 (xid 0x5990bd), next in 1.0 seconds
     wlan0: REPLY6 received from <link local address upstream router>
     wlan0: delegated prefix <prefix>::/62
     eth0: adding address <prefix>::1/64
*     if_addaddress6: Invalid argument
     wlan0: renew in 1800 seconds, rebind in 2880 seconds
     eth0: adding route to <prefix>::/64
     wlan0: writing lease `/var/lib/dhcpcd/dhcpcd-wlan0.lease6'
     wlan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' REBIND6
     forking to background
     forked to background, child pid <PID>
but in contrast to these messages eth0 gets no global unicast address 
assigned. A route on eth0 corresponding to the prefix is created, though.
None of these problems can be seen running 6.4.0 on i686, and Prefix 
Delegation is working running the patched 6.3.2 on ARM, too.

If you aren't fed up with this rather lengthy report yet I'd like to ask 
whether there's a comprehensive quick overview on how to checkout code 
from Fossil ;-).

Regards,

Peter Mattern