dhcpcd-discuss

On 05/07/2014 21:19, Robert White wrote:
> On 07/04/2014 04:57 AM, Roy Marples wrote:
> > dhcpcd --nopfxdlg
> > dhcpcd --pfxdlgonly --script ""
>
> Patch (as fetched from fossil) seems to work.
>
> One side-note is that you (well _I_) have to run the commands in the
> opposite order or the prefix-only invocation just times out. I'm
> presuming that the comcast server thinks its a dupe or something and
> it doesn't answer again.
>
> So this is bad:
>
> > dhcpcd --nopfxdlg
> > dhcpcd --pfxdlgonly --script ""
>
> But this works for me:
>
> dhcpcd --pfxdlgonly --script ""
> dhcpcd --nopfxdlg

Start order *should* be irrelevant because they are implemented as 
separate protocols.
When it comes to RENEW/REBIND timers, they *could* be different also so 
one should not preclude the other.

As such there could be an error with the implementation.
Can you make some packet captures and forward them to me if not here 
please? Some working, some not working.
Also, can you also test *shudder* dhclient? That enforces different 
instances per IA type, same as what dhcpcd is doing above.
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?

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

> In a perfect world this would happen using a single internal
> fork()/clone() option like --prefixchild (or whatever) that forks off
> a child thread (On linux using clone(CLONE_THREAD,...) instead of just
> fork() so that it dies when it's parent is killed). But in that
> perfect world there'd be a way to predict which child ran first, or at
> a minimum that both were ready to receive before the first packet was
> sent.
>
> I'll work on a modified startup script, for now I'm manually starting
> things. Good thing I don't have to reboot very often.

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.

If we can get this working reliably, I may consider adding code so 
dhcpcd fork(3) and send it a SIGTERM when dhcpcd itself exists.
We can the control single instance vs RFC compliant forked instance with 
--pfxdlgfork

> Thanks for making this work. 8-)

Thanks for caring and testing!

Roy