dhcpcd-discuss

On 07/07/2014 3:58, Robert White wrote:
> So the two process model may not be stable over time. At T+29 hours
> after the initial establishment of both leases (the ::/60 requester
> first, then the ::/128 requester launched immediately after) the
> ::/128 public address was gone from the external interface.
>
> I'm guessing the renew failed.
>
> I've not tried sharing the same source/dest socket between two
> processes. Is it possible that one process is getting all the packets
> just because of how the linux kernel handles UDP socket? (I'm familiar
> but not expert on that data path. e.g. since they are both bound to
> UDP *:dhcpv6-client will they both get all the packets?)

Hmm, it does seem that one dhcpcd instance is infact blocking the other 
on NetBSD at least. You're probably seeing the same thing.
My test case was to start both in different terminals and keep them in 
the foreground with debugging (-dB)
and then force link down/up (wpa_cli reassociate in my case).

Doing it like so, both start up fine, but the pfxdlgonly instance never 
sees any more DHCPv6 replies after carrier up which the server is 
sending.
It is sending replies out fine though which is odd as it uses the same 
socket. If I kill the nopfxdlg instance, the pfxdlgonly instance then 
gets the replies.
So definitely some kind of contention.

All the sharing options are in place so I don't understand why this 
happens at this time.

> Is their any chance that one actor (say "do prefixes") will squelch
> the other by sending a NAK for the others data set?

No

> The two process model as currently implemented already re-breaks the
> ipv6 --dumplease stuff. (I did a fresh update via fossil rather than
> applying the patches by hand, so this may just be a merging issue of
> some sort).

dhcpcd -U6 --pfxdlgonly iwi0
dhcpcd -U6 --nopfxdlg iwi0

work fine for me - when both actually have leases that is.

Thanks

Roy