dhcpcd-discuss

Hi Peter

On 27/06/2014 20:36, Peter Mattern wrote:
> 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.

You see the duplicates because systemd records both stderr and syslog 
output.
You may wish to consider the --quiet flag to stop stderr output.
Debug still works with --quiet.

> 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.

No, that's fine.

> 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?

In my experience, many distributions ship headers that don't entirely
match the kernel in terms of feature availability.
Because it fails like so is sort of expected I guess, the important part
is that it's now handled gracefully.

> 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.

This is true, it's similar in BSD as well.
I've remove the cleanup, especially as we could have >1 daemon playing 
around with it so resetting it wouldn't be reliable anyway.
http://roy.marples.name/projects/dhcpcd/ci/79829e0adc4b0bb8f484e6d1db88870927f1dc35?sbs=0

See the IA_PD discussion with Robert White on this list for why we may 
need this.

> 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.

The extra address is being added by the Linux kernel which is silly and 
someone should fix.
Someone other than me ;)

See a similar query on tech-userlevel@netbsd
http://mail-index.netbsd.org/tech-net/2014/07/02/msg004684.html

> 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.

Hard to see anything that's wrong as you've masked the addresses.
Could be due to the problem below.
Duplicate routes can potentially be a problem due to Linux sometimes 
changing the metric it wants to add.
This is fixed in newer kernels where I can stop the automatic route 
being added - yay!.
Needs a 3.14 kernel I think.

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

Due to an error shown below.

> 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...

http://roy.marples.name/projects/dhcpcd/fdiff?v1=9f9c279efc300b7ada7d3b5eb0e26b02b1197b8b&v2=cb73407779dea3efaee4ae0ccbf0eea8719ce057&sbs=1

> 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 ;-).


ARRRRRRRRRRRGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHH

OK, this is another one of those header vs kernel issues!
Sadly this is harder to fallback on.
The error in question is probably due to this in if-linux.c around line 
1090

#ifdef IFA_F_NOPREFIXROUTE
        if (!IN6_IS_ADDR_LINKLOCAL(&ap->addr)) {
                flags = IFA_F_NOPREFIXROUTE;
                add_attr_32(&nlm.hdr, sizeof(nlm), IFA_FLAGS, flags);
        }
#endif

The only thing we can do at runtime is to re-try adding the address 
without that flag, but that will complicate the code here and elsewhere 
.....
To test, simply comment out the add_attr_32 line.

Really Peter, please fix the header mess :)

Thanks

Roy