We have satellite modems and small servers installed in plenty of odd, rough, remote rural places, and satellite modems can be persnickety beasts. The provider claims they're all identical but some hand out static IP's over dhcp, some don't. Some respond to DHCP, some don't. They all have a nice parse-able web interface for runtime statistics, but not always the same parse-able web interface for runtime statistics. Trying to deal with their eccentricities in an automatic way can be a bit troubling if you want a uniform set of systems.
With a bit of wrangling I found an arrangement that worked in most situations. Usually the modems give a static address over DHCP, or a NAT address over DHCP, but a few odd ones don't respond at all, so I used dhcp failovers to auto-set the server's WAN port to an 192.168.x.x address when DHCP failed. Finally I could have the same settings work on all of my servers and modems, with actual static IP's when available, and it was good.
A little while later, a minor but important security fix came through for dhcpcd. In-house testing showed it properly picking up IP's, and the rest of the changes looked absolutely minor, so I deployed it. Most servers kept running... a few didn't. 100km later I was sitting on a bucket in a grimy, tick-filled wooden shack trying to figure out what the machine in front of me was doing to itself.
Code:
$ ifconfig wan
wan Link encap:Ethernet HWaddr 00:08:C7:E3:A1:13
inet addr:169.254.32.239 Bcast: ...
The not-so-insignificant new feature turned out to be zeroconf support, enabled by default. This means failure is a perfectly acceptable outcome for dhcpcd now. On timeout it sets a useless random IP and returns success. No error, no failover; no failover, no network connection. One extra flag in dhcpcd's default options, a few long drives, and everything worked fine again.
I don't want to kill whoever decided zeroconf was a sane default for the world, but I'd at least like to pie him.
Last edited by Corona688; 01-13-2012 at 01:16 PM..
DHCPCD-RUN-HOOKS(8) BSD System Manager's Manual DHCPCD-RUN-HOOKS(8)NAME
dhcpcd-run-hooks -- DHCP client configuration script
DESCRIPTION
dhcpcd-run-hooks is used by dhcpcd(8) to run any system and user defined hook scripts. System hook scripts are found in
/libexec/dhcpcd-hooks and the user defined hooks are /etc/dhcpcd.enter-hook. and /etc/dhcpcd.exit-hook. The default install supplies hook
scripts for configuring /etc/resolv.conf and the hostname. Your distribution may have included other hook scripts to say configure ntp or
ypbind. A test hook is also supplied that simply echos the dhcp variables to the console from DISCOVER message.
Each time dhcpcd-run-hooks is invoked, $interface is set to the interface that dhcpcd is run on and $reason is to the reason why
dhcpcd-run-hooks was invoked. DHCP information to be configured is held in variables starting with the word new_ and old DHCP information to
be removed is held in variables starting with the word old_. dhcpcd can display the full list of variables it knows how about by using the
-V, --variables argument.
Here's a list of reasons why dhcpcd-run-hooks could be invoked:
PREINIT dhcpcd is starting up and any pre-initialisation should be done.
CARRIER dhcpcd has detected the carrier is up. This is generally just a notification and no action need be taken.
INFORM dhcpcd informed a DHCP server about it's address and obtained other configuration details.
BOUND dhcpcd obtained a new lease from a DHCP server.
RENEW dhcpcd renewed it's lease.
REBIND dhcpcd has rebound to a new DHCP server.
REBOOT dhcpcd successfully requested a lease from a DHCP server.
IPV4LL dhcpcd failed to contact any DHCP servers but did obtain an IPV4LL address.
STATIC dhcpcd has been configured with a static configuration which has not been obtained from a DHCP server.
3RDPARTY dhcpcd is monitoring the interface for a 3rd party to give it an IP address.
TIMEOUT dhcpcd failed to contact any DHCP servers but was able to use an old lease.
EXPIRE dhcpcd's lease or state expired and it failed to obtain a new one.
RELEASE dhcpcd's lease was released back to the DHCP server for re-use.
NAK dhcpcd received a NAK from the DHCP server. This should be treated as EXPIRE.
NOCARRIER dhcpcd lost the carrier. The cable may have been unplugged or association to the wireless point lost.
FAIL dhcpcd failed to operate on the interface. This normally happens when dhcpcd does not support the raw interface, which means
it cannot work as a DHCP or ZeroConf client. Static configuration and DHCP INFORM is still allowed.
STOP dhcpcd stopped running on the interface.
DUMP dhcpcd has been asked to dump the last lease for the interface.
TEST dhcpcd received an OFFER from a DHCP server but will not configure the interface. This is primarily used to test the variables
are filled correctly for the script to process them.
ROUTERADVERT dhcpcd has received an IPv6 Router Advertisment, or one has expired.
FILES
When dhcpcd-run-hooks runs, it loads /etc/dhcpcd.enter-hook and any scripts found in /libexec/dhcpcd-hooks in a lexical order and then
finally /etc/dhcpcd.exit-hook
SEE ALSO dhcpcd(8)AUTHORS
Roy Marples <roy@marples.name>
BUGS
Please report them to
http://roy.marples.name/projects/dhcpcd
SECURITY CONSIDERATIONS
Little validation of DHCP options is done in dhcpcd itself. Instead, it is up to the hooks to handle any validation needed. To this end,
some helper functions are provided, such as valid_domainname as used by the 20-resolv.conf hook to ensure that the hostname is not set to an
invalid value. valid_path is also provided, but is currently unused by a stock hook script.
BSD March 19, 2012 BSD
01-13-2012
