dhcpcd-discuss

Roy,

No problem!

Part of what Yocto does is set up the configure flags; all you have to do is indicate that the package is built using autotools and it takes care of the rest. As such, other autotools packages built with Yocto receive the --includedir parameter, but from what I can tell dhcpcd is the only package that has its configure script add the given include directory to the CPPFLAGS variable as part of the -I parameter. I'm not saying this is wrong (it was probably added to fix a build on a different platform?), but it's different from other packages, so maybe there is another solution that would work for both platforms?

Regarding the max interval parameter, the environment we operate in is different from most networks in that it consists almost entirely of peer-to-peer devices. We run a DHCP server so that third-party devices can configure themselves. If you were to cold-boot all devices simultaneously then it could be up to 90 seconds before the DHCP server is available. Having a large interval further increases the time before the third-party devices are configured.

Are you referring to the limits discussed in RFC 7083 sections 4 and 5? Those sections seem like they impose limits on the values sent by a DHCPv6 server to reconfigure a client. This is different from values configured by the client.

I can see why having a small interval would cause problems in an environment with 100s of clients, but in smaller systems having the ability to reduce this would improve system responsiveness.

Thanks,

Nate

-----Original Message-----
From: Roy Marples [mailto:roy@xxxxxxxxxxxx]
Sent: Tuesday, December 15, 2015 7:19 AM
To: Karstens, Nate <Nate.Karstens@xxxxxxxxxx>; Karstens, Nate <Nate.Karstens@xxxxxxxxxx>
Cc: dhcpcd-discuss@xxxxxxxxxxxx
Subject: Re: [dhcpcd-discuss] Yocto Build and Feature Request

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

________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be confidential and/or legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.