Comment 2 for bug 717166

Revision history for this message
Daniel Nurmi (nurmi) wrote :

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