dhcpcd-discuss

Hi Nate

Sorry for the late reply, life is quite busy atm!

On 2015-12-10 13:59, Karstens, Nate wrote:
> First, let me thank you for your work on dhcpcd. We needed a DHCP
> client with good auto-IP fallback. The ISC dhclient and udhcpc seem to
> have some support for this when paired with an auto-IP client like
> avahi-autoipd, but dhcpcd continues to search for DHCP servers even
> after assigning a link local address, which is perfect.

Thanks!

> We use Yocto to cross-compile for an ARM processor, but ran into a
> problem compiling dhcpcd in this environment. I have a fix that I'd
> like to run by you and a feature request that I hope you'll consider.
>
> First, the cross-compiling issue manifested itself as a compile error
> related to some assembly code. Part of what Yocto does it to set up a
> build environment that contains the header files, libraries, etc. of
> the target system instead of the host system. One of the sections of
> dhcpcd's configure script adds a path to the header files on the build
> system. This causes the build system's header files to be used, which
> leads to x86 assembly code being introduced for the network byte order
> functions (e.g., htons). The change to fix this has been posted to
> http://patches.openembedded.org/patch/109521/ [1]. It seems to work
> well enough for Yocto, but I didn't know if that section of the script
> is needed for another platform.

The code removed by this patch is only triggered when ./configure is 
sent --includedir dir .... so simply don't use that in your cross 
compile environment and there is no need for the patch.

> Now for the feature request. Our environment is slightly different
> from traditional networking environments in that the DHCP server is
> not necessarily running when the client is started; it may be started
> much later. dhcpcd will continue to search for DHCP servers in this
> scenario, but the interval between DISCOVER messages increases until
> it reaches a maximum of 64 seconds (as recommended by RFC 2131). We'd
> like to be able to specify the maximum interval between messages so
> that the DHCP client can acquire a local address much faster. Unless
> I'm overlooking a configuration option it doesn't look like there is a
> way to do this. I propose introducing a "--maxinterval" parameter that
> defaults to 64. I have a local patch that accomplishes this and if
> you'd like I can clean it up, add documentation, and pass it along.

I'm in two minds about this.
Firstly, the wording in RFC2131 is SHOULD and not MUST which means we 
can have any arbitrary limit.
Secondly, in RFC7083 it increases the maximum equivalent for DHCPv6 from 
120 seconds (double DHCP) to 3600 seconds by default but also allows it 
to be configurable (server side -> client side) where it MUST in the 
range 60 <= "value" <= 86400 (1 day).

So if we did implement this option, it would have to fall into the same 
range, and I doubt shaving 4 seconds off the max limit will improve your 
situation any.
I also cannot imagine any network design where the DHCP server should 
NOT be running before clients are started, unless it was down for 
maintenance.
But even then, DHCP fail-over is not a new science and there are good 
working examples for implementing this with ISC DHCPd.

So no, I think I will have to reject this as it goes against one of the 
core principles of dhcpcd - being as RFC compliant as possible.

Could you expand more on why the DHCP server may not be available when 
the client boots?
dhcpcd resets the timers on link down/up messages from the kernel - is 
this issue because your client driver does not support this?

Thanks

Roy