2011-07-01 05:35:38 -04:00
..
2011-05-30 10:54:05 -04:00
2010-11-12 04:02:18 -05:00
2010-11-12 04:02:18 -05:00
2011-06-27 15:19:54 -04:00
2011-05-30 10:54:05 -04:00
2011-05-30 10:54:05 -04:00
2011-05-30 10:54:05 -04:00

ndhc client
--------------------

The ndhc client negotiates a lease with the DHCP server and notifies
ifchd when a leases is obtained or lost.


command line options
-------------------

The command line options for the ndhc client are:

-c, --clientid=CLIENTID         Client identifier
-H, --hostname=HOSTNAME         Client hostname
-h,				Alias for -H
-f, --foreground                Do not fork after getting lease
-b, --background                Fork to background if lease cannot be
                                immediately negotiated.
-i, --interface=INTERFACE       Interface to use (default: eth0)
-n, --now                       Exit with failure if lease cannot be
                                immediately negotiated.
-q, --quit                      Quit after obtaining lease
-r, --request=IP                IP address to request (default: none)
-v, --version                   Display version


If the requested IP address cannot be obtained, the client accepts the
address that the server offers.


note on ndhc's random seed
---------------------------

ndhc will seed its random number generator (used for generating xids)
by reading /dev/urandom. If you have a lot of embedded systems on the same
network, with no entropy, you can either seed /dev/urandom by a method of
your own, or doing the following on startup:

ifconfig eth0 > /dev/urandom

in order to seed /dev/urandom with some data (mac address) unique to your
system. If reading /dev/urandom fails, ndhc will fall back to its old
behavior of seeding with time(0).


signals accepted by ndhc
-------------------------

ndhc also responds to SIGUSR1 and SIGUSR2. SIGUSR1 will force a renew state,
and SIGUSR2 will force a release of the current lease, and cause ndhc to
go into an inactive state (until it is killed, or receives a SIGUSR1). You do
not need to sleep between sending signals, as signals received are processed
sequentially in the order they are received.

DHCP pitfalls
-------------

Send a packet that has an options field set to:
DHCP-OPTION-OVERLOAD:3

Then in the file and sname fields:
DHCP-OPTION-OVERLOAD:3

I suspect some bad dhcp programs will hang given this input.