[udhcp] Fwd: Zeroconf in udhcpc

[Elvis Pfützenreuter]

Greetings,

I would like to present a patch for udhcp, that implements Zeroconf
for udhcpc (DHCP client). The patch was made against the CVS version
of 15/5 (I have no CVS access today, so unfortunately the patch is not
against today's CVS).

I know there are other Zeroconf initiaitives in open source world, as
Busybox's zcif, and Howl, but both seem to implement Zeroconf in
separate binaries. Only if DHCP lease fails, Zeroconf kicks in, and
DHCP is never tried again until reboot.

My approach was quite different: the Zeroconf and DHCP client state
machines work in the same program (udhcpc), so the user gets the best
IP address the fastest possible. If the user starts the machine in an
insulated network, it will get a Zeroconf IP. As soon as a DHCP server
shows up, udhcpc will get its IP. On the other hand, if the DHCP
server is out and the lease expires, a Zeroconf address will be
configured.

I did not analyze the Darwin's code for Zeroconf, but I have an iBook
and I feel this approach mimics Mac OS X more closely than simply
disabling DHCP for good and resorting to Zeroconf.

About code changes in udhcp. I tried to touch dhcpc.c the least
possible, concentrating all Zeroconf state machine in a new source
file (zeroconf.c) that is not even compiled if Makefile is configured
not to include Zeroconf.

Perhaps I should have discussed all of that in this mailing list
before writing any code, but I really wanted to show some
ready-to-play patch to justify my approach.

A couple TODOS remain:

* Autoimmune response test (two network interfaces in the same link)

* While Zeroconf is in and DHCP lease has yet not been granted, DHCP
raw socket receives every packet of the network interface, so udhcpc
would consume a fair amount of CPU in a embedded computer with
Zeroconf active. I am not sure how to fix that, I did not feel
confident to make any changes in the core DHCP client code (I'm
accepting suggestions.)

* ARP replies must be in broadcast if you have an Zeroconf address
(169.254/16). I implemented an ARP responder in UDHCPC to fulfill
that, but it is in fact duplicating the kernel's ARP responder. The
right approach would be to submit a kernel patch.

Elvis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: udhcp-cvs.zeroconf.patch.gz
Type: application/x-gzip
Size: 8621 bytes
Desc: not available
Url : http://busybox.net/lists/udhcp/attachments/20050530/15fc056f/udhcp-cvs.zeroconf.patch.bin