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..
dhcpcemu(8) System Manager's Manual dhcpcemu(8)NAME
dhcpcemu - Emulate a DHCP client
SYNOPSIS
/usr/sbin/dhcpcemu [-b] [-q] [-m | -n | -v] [-dn] [-a server_address] [-c client_address] [-e hardware_address] [-h hostname] [-i
client_identifier] [-r requested_address] [-p bootp | discover | renew | rebind | request | select | decline] [-s size] [-t timeout] [-f
file] interface
OPTIONS
Sets the broadcast bit. Runs quietly: display neither the contents of the incoming nor the outgoing packets. Sets the magic cookie in the
outgoing packet to be the CMU (-m) or the RFC1048 (-v ) value (the default). The -n option means to use no cookie at all. The server
identifier field in the options of the outgoing packet is set to the IP address. To properly emulate a client in the selecting DHCP state,
this field is required regardless of the value given with the -p option. Sets the ciaddr field in the packet to the value client_address
or to the IP address of the interface chosen if client_address equals 0.0.0.0. Pretend to be at the given hardware (MAC) address. The
chaddr field is set to hardware_address. Unless the broadcast bit is also set, this usually means that no replies will be received, as the
server or relay agents will normally try a link-level unicast to the phony address. Sets the hostname option in the outgoing packet to the
given value. Sets the client identifier option in the outgoing packet to the given string. The string is treated literally, not as a hex
representation of an arbitrary octet string. Sets the IP address value in the outgoing packet. This option is required if the outgoing
packet is to validly represent a client in the DHCP states selecting or rebooting or in a DHCP DECLINE message. The string following
determines the kind of BOOTP or DHCP packet sent, and whether the packet is broadcast or unicast. The default is to emulate a BOOTP
client. Sends a packet of size octets (by default 548 octets). Exits after timeout seconds if no responses are received. Sets the file
field in the outgoing packet to the given string.
DESCRIPTION
The dhcpcemu command emulates a DHCP/BOOTP client. Options are provided to set the most important fields in the BOOTP request packet. A
packet is constructed, is sent through the interface specified, and a reply awaited. The emulator exits after the first reply is received
or for a length of time specified by the -t option. Depending on the options specified and/or the DHCP server configuration, no reply may
in fact be forthcoming. If no timeout is specified, the emulator may be killed with any suitable asynchronous signal. The SIGINT signal
(usually generated from the keyboard with Ctrl/c) is available if dhcpcemu is running in the foreground.
It is important to note that with the options available, it is quite possible to create an illegal packet. This is one of the primary func-
tions of dhcpcemu; to test the behavior of servers when confronted with packets that do not conform to the standards.
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 be only one DHCP server for all the cluster members using a common database with
failover.
SEE ALSO
RFC2031, RFC2032
dhcpcemu(8)
01-13-2012
