What I've been doing - DHCP client coding

[Dan Williams <dcbw redhat com>]

Hi,

Since I've gotten fed up with the DHCP situation with NetworkManager, I 
started looking at existing dhcp clients with the idea of incorporating 
one into NetworkManager.  This has the following benefits:

1) We don't have to depend on the execution cycle of external daemons.  
We'd really just love to have a library that we could call to do the work.  
When we switch interfaces, we have to 'kill -9' the current dhclient 
process (at least on Fedora).  We could try to get its PID when we execute 
it, but that's more code since we can't use g_spawn_sync() anymore.

2) MUCH better error reporting.  Since we're not dependent on an 
executable, we can have much better error reporting.  We know when the 
request has failed, we know immediately when it has succeeded, etc.  We 
can control the renewal, etc.

For NetworkManager, good error and state reporting is essential.  It seems 
that the only way we can accurately detect a link for all wireless cards 
is to do DHCP on them, this allows us to do Open System authentication 
too.  Therefore, we need to be able to control, in a fine-grained manner, 
the operation of the DHCP client if we are able to use it as our 
link-validation method.

3) We don't have to use external scripts for configuration.  While 
external scripts are nice, and may have a place in the NetworkManager 
architecture in the future, they inhibit us right now.  For example, on 
Fedora, the scripts take the interface down when the DHCP fails.  We need 
to keep that interface up so that scanning can work.  They also do other 
wierd things that weren't intended for something like NetworkManager.

The cons of this approach are:

1) We have _another_ dhcp client around.  Most distributions already ship 
with one.

2) We have to keep up with security issues.  This is fairly easy if the 
code is simple.

3) Some small loss of distribution-specific configurability.  Since we're 
not using those distribution-specific scripts (like /sbin/dhclient-script 
on Fedora), the internal DHCP stuff won't necessarily set the card up in 
the same way.

This is mostly an issue with stuff like bridging, bonding, VLANs, etc.  
However, since we don't support these right now anyway, I consider it 
something we can overlook until we decided to add support for them.


So, I took a look at a couple DHCP clients over the past few days:

a) ISC dhcp: includes both client and server.  Looks like the most 
actively developed and most complete.  However, its _quite_ hard to 
separate the server and client code, and the client code is quite 
intertwined with OMAPI objects.  We'd need to include about 25 .c files 
and it would take significant effort to separate out just the client bits.  
BSD-type license.

b) udhcpd: small, but doesn't seem to be proven to work as many places.  
Both client and server.

c) pump: small, but has known issues with some DHCP servers, and is not 
actively maintained.  People keep telling me we're trying to kill it 
anyway.  Client only.

d) dhcpcd: small, GPL license.  Client-only.  However, it uses global 
variables for the entire client state and packet data.

I decided that dhcpcd would fit best, so I spent the past few days 
refactoring it to not use global variables and to clean up some of the 
code.  I've now gotten it mostly into the shape where its suitable to be a 
library that we and other projects can link in.  I'll be getting it up to 
speed, committing the code to CVS, and changing the link detection of 
NetworkManager to go through a full DHCP process before determining 
failure or success of a link.

Thoughts?  Its not too late :)  Most of the decision to go this route was 
due to Open System support, as well as random "it won't connect to my 
access point and keeps asking for a WEP key" complaints, all valid ones.  
This should fix these problems, at the cost of waiting a bit longer for a 
connection.  We can, however, provide more user feedback during the 
connection process, which should compensate for that.  I feel that at this 
time, slower-but-robust connection process is better than 
faster-but-sucks.

Dan