dhcpcd-discuss

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

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


On 07/05/2014 02:16 PM, Roy Marples wrote:
> Also, can you also test *shudder* dhclient? That enforces different
> instances per IA type, same as what dhcpcd is doing above.

I tried and abandoned dhclient because that took me back to day-one. I 
couldn't figure out how to get it to send the "::/60" prefix data 
element in the request so comcast would respond, but only with a /64. 
(e.g. it was just as day one of our exchange here 8-).

> Does that suffer from the same startup order logic? If not, can you
> provide packet captures of that working as well please so I can see what
> dhcpcd is doing differently and try and fix?

I'll go back and try to figure this part out

> > It's gonna suck to integrate this into the Gentoo daemon startup and
> > control scheme.
>
> It's easy - symlink /etc/init.d/dhcpcd to dhcpcd-pfxonly and treat it as
> a different service ;)

Ay on treating it as a different service. Nay on being able to do it 
with a symlink. It will be enough to copy the file and tweak it with the 
various mods; different options, different pid files, a dependency order 
"before" or "after" clause.

It's not hard by any stretch, I just have to do it and them make it a 
maintenance thing after any future updates.

> I did consider this but decided not to for a few reasons:
> 1) Any solution needs to be portable (Linux is not the only supported
> platform)
> 2) dhcpcd needs to work on non MMU or RTOS platforms, no fork(3) so we
> need this to work as is anyway.

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

More and more fun!

-- Rob