2e328b6913
Change order of operations to prevent overflow with very long leases when calculating rebind time duration. |
||
---|---|---|
.. | ||
arp.c | ||
arp.h | ||
CMakeLists.txt | ||
config.h | ||
COPYING | ||
dhcp.c | ||
dhcp.h | ||
ifchange.c | ||
ifchange.h | ||
leasefile.c | ||
leasefile.h | ||
ndhc-defines.h | ||
ndhc.8 | ||
ndhc.c | ||
netlink.c | ||
netlink.h | ||
nl.c | ||
nl.h | ||
options.c | ||
options.h | ||
README | ||
state.c | ||
state.h | ||
sys.c | ||
sys.h |
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.