faa56bb616
waiting for select loop to cycle again. Works better in practice and simplifies the select loop, too. |
||
---|---|---|
.. | ||
AUTHORS.udhcp | ||
clientpacket.c | ||
clientpacket.h | ||
CMakeLists.txt | ||
COPYING | ||
dhcpc.h | ||
dhcpd.h | ||
MODIFICATIONS | ||
ndhc-defines.h | ||
ndhc.8 | ||
ndhc.c | ||
options.c | ||
options.h | ||
packet.c | ||
packet.h | ||
README | ||
script.c | ||
script.h | ||
socket.c | ||
socket.h | ||
TODO |
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.