[Bug 717166] Re: Broken with v4 isc-dhcp-server in Natty

Daniel Nurmi dnurmi at gmail.com
Wed Mar 16 02:07:35 UTC 2011


All,

Thanks for this bug report, it does indeed appear that there is a bug in
the new DHCP server that is preventing it from learning that some
interfaces may have multiple IP addresses associated with them.  Here is
the result of my findings after looking at the dhcp server code for both
dhcpd3 from lucid (works) with the new isc-dhcp-server.

In discover.c, there is a routine for discovering configured interfaces,
reading any assigned IPs on those interfaces, and matching those
assigned IPs with subnets defined in the dhcpd configuration file.
Fundamentally there is a big loop that goes over all interfaces and that
reads the configured IPs.  In v3, the buffer that was iterated over was
populated by an ioctl with SIOCGIFCONF, which fills a buffer with
interfaces and their assigned addresses; if an interface has more than
one assigned address, then the buffer contained multiple entries for
that interface each with an assigned IP.  The new logic has been
reworked (it looks like to solve the problem of supporting  more UNIX
variants cleanly), such that there are routines that populate a global
buffer, grab the 'next' interface, and cleanup when done.  For Linux,
the routines go through /proc/net/dev to get the device names, and then
use an ioctl with SIOCGIFADDR to get the address from each interface.
Here lies the problem, which is twofold!

1.) the ioctl and later logic will only return a single address from each interface
2.) /proc/net/dev only contains one entry per interface

So, if an interface has more than one assigned address, the server will
only ever see the 'first' one.

Possible solutions:

1.) It looks like, during the re-design of the iteration logic, that a
set of routines was written for BSD/OSX that use the getifaddrs() call
to get a complete list of all configured interfaces with addresses.
This looks really clean, and Linux does also support getifaddrs().  We
could potentially suggest to the upstream that this same logic be used
for linux as well as OSX/BSD.

2.) The iteration goes over each interface, and we could add some code
for each interface to interrogate the interface for all configured
addresses.

I've attached a patch that makes a proof of concept attempt at solution
#2 and verified that it works for Eucalyptus (should be general), but
I'm not necessarily comfortable suggesting this as the 'real' solution
as I believe that I'm missing some context as to the UNIX variant
agnostic nature of the DHCP server code.  It may be worth using as a
starting point, however.

In any case, I do believe that this issue should be brought to the
attention of the upstream maintainer, as I believe that, even ignoring
Eucalyptus altogether, this bug will cause problems for folks who have
more than one IP assigned to a single interface.

-Dan


** Patch added: "dhcpd.workaround.patch"
   https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/717166/+attachment/1911316/+files/dhcpd.workaround.patch

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
https://bugs.launchpad.net/bugs/717166

Title:
  Broken with v4 isc-dhcp-server in Natty



More information about the Ubuntu-server-bugs mailing list