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..
dhcpparm(8) System Manager's Manual dhcpparm(8)NAME
dhcpparm - Daemon for client configuration
SYNOPSIS
/usr/sbin/dhcpparm [-i interface] tag | symbol | name
OPTIONS
Use this option on hardware that has two or more interfaces configurable by the Dynamic Host Configuration Protocol (DHCP), and for a
parameter that is interface specific. When no interface is specified, the client daemon returns the name of the first interface it finds on
which DHCP has successfully completed: the value(s) displayed will be those of the configuration received on that interface.
DESCRIPTION
The dhcpparm command displays the value(s) of the parameter requested on the command line as supplied by the DHCP protocol. If the DHCP
parameter implies more than one value (for example, a list of gateways), the values are displayed separated by newline characters. The
parameter may be identified either by its numeric value in the DHCP protocol, by its two character symbol, or by its long name. The dhcp-
parm command is intended to be used in command substitutions in the shell scripts invoked by init at system boot. It first contacts the
DHCP client daemon (joinc) to verify that DHCP has successfully completed. When the -i option specifies a particular interface, the daemon
verifies successful DHCP configuration of that interface; otherwise, the client verifies that at least one interface is successfully con-
figured, and supplies the name of that interface to dhcpparm. Parameter values echoed by dhcpparm should not be used without checking exit
status. See the EXIT STATUS section below.
RESTRICTIONS
A cluster member should never be a DHCP client; it should always use static addressing.
If a cluster is to support a DHCP server, there can only be one DHCP server for all the cluster members using a common database with
failover.
If a cluster is to support a DHCP server, there can only be one DHCP server for all the cluster members using a common database with
failover.
DHCP client is not supported on dataless clients.
SYMBOLS
See dhcptags(4) for the list of two letter symbol codes and names of all DHCP parameters. See RFC 1533 for more detail.
EXIT STATUS
Exit codes are as follows: Success. DHCP was not successful. The DHCP client daemon may not be running, the interface might have failed to
configure, or no satisfactory DHCP responses were received. Bad arguments. A timer was set and the interface had not configured before it
expired. Can only be run as root. Some system error (should never occur).
SEE ALSO
Commands: dhcpconf(8), joinc(8), showdhc(8), shleases(8)
Files: client.pcy(4), dhcptags(4)
RFC1533
dhcpparm(8)
01-13-2012
