Problems running multiple dhclients at the same time

[David W. Hankins]

On Wed, Jun 09, 2010 at 02:25:47PM -0700, Jeremiah Jinno wrote:
> Synchronization Issue 1:
> Synchronization Issue 2:

These probably have to do with how dhclient-script re-initializes an
interface.  The script chooses to 'down/up' an interface to clean
both it and all routing tables.  A softer method (maybe using
something like Linux' /sbin/ip instead of /sbin/ifconfig, `ip' has
better tools to remove all config of a specific type).

We essentially had to do this in order to support dual stack DHCPv4
and DHCPv6; so one software starting before the other would not
re-initialize the interface the other software is using.

But this doesn't get into the problems where configuration parameters
(nameservers, domain search, etc) are revoked when any one of the
interfaces expires or releases.

Overall, I want dhclient to start to rely on an external agent to
combine configuration information.  There are multiple sources of
configuration - DHCPv4, DHCPv6, manual parameters entered by the
operator, so forth.  Essentially what's needed is an engine that sorts
multiple inputs into one output, detects not just a per-interface
change but a global change in the net sum before reconfiguring the
system.

Right now my best guess is that external agent would be the
NetworkManager project, which relies on dBus to do its thing, because
it already has a desktop applet that can involve the user in
decisions about configuration selection and managing both user
supplied and dynamically supplied configuration.  All that's needed is
a shim "system administrator" virtual applet for servers, where X
isn't running.

Alas it is a project for a rainy day, and it never rains in California.

> ** Should this be filed as a bug?? **

Yes, it would be easiest if you just send the patch as an attachment
with a brief description (or just copy and paste a URL from archives).

> -       srandom(seed + cur_time);
> +       srandom(seed + (unsigned)cur_time + (unsigned)getpid());

That's a good idea.  It also solves problems where the clients derive
similar random back-off timers.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100610/749beba6/attachment.bin>