client.pcy - BOOTP and DHCP client policy
The client.pcy file is a text database, read by the joinc daemon on
startup, which governs the behavior of BOOTP and DHCP clients. If the
JOINCONFIG variable is present in the joinc environment, it is taken to be
the directory where client.pcy is housed; otherwise joinc searches the
/etc/join directory. Defaults exist for all parameters and switches, so it
is not an error if the file does not exist.
Blank lines are ignored. The number sign (#) introduces a comment which
continues to the next newline. Each new policy option must begin and end on
a separate line. Policy options are introduced by a keyword, and may be
Boolean, or may take a value separated from the keyword by whitespace (but
not a newline). If an option is present more than once, only the value
attached to the last occurrence takes effect - earlier value(s) are forgot-
KEYWORDS AND VALUES
If no DHCP responses are heard and this flag is set, the client uses
any BOOTP response in the configuration. In this scenario, the client
does not renew, rebind, expire, or release its IP address lease. In
other words the client is given what is effectively an infinite lease.
Although the client accepts BOOTP responses, it only sends DHCP pack-
ets. There is no guarantee that BOOTP servers which hear these packets
will respond, since they may become confused by the presence of DHCP
data within the packet.
When the client receives an IP address from the server, it performs an
ARP on the local network to verify that no other client is using the
address. If the client receives no reply after seconds expires, it
assumes that it may use the address.
Default: 2 seconds.
The client's class ID. Consult RFC1541 for details.
Use a client identifier other than the MAC address. Currently setting
client_id tells the DHCP client daemon to use a concatenation of the
MAC address and the interface name as the client ID. The MAC address
is in internal form, not the readable, colon-separated string. You
must use this option when configuring a client with multiple interfaces
and where the client's MAC address is the same on each interface (SUN
hardware for example).
The DHCP server grants the client permission to use an IP address for a
fixed period of time (which may be infinite). In the language of DHCP,
the client is granted a "lease" on the IP address. With this parame-
ter, the client may request a lease of a particular duration, although
servers are not bound to honor the request. If the client does not
care, seconds should be set to zero; if an infinite lease is required,
to minus one, -1. Otherwise specify in seconds the lease duration
This parameter is subtly different from the number of retries a client
will make as part of an exponential broadcast retry backoff. Rather it
is the number of separate attempts the client will make to contact a
server, assuming that replies are received, but that the client, for
one reason or another, rejected those replies.
Clients are required by the DHCP protocol to implement an exponential
retransmission and backoff when broadcasting discover or request pack-
ets. The array of values specifies how long the client should wait for
replies before timing out and retrying the broadcast.
Each time the client sends a DHCP protocol packet, it waits for a
response until a timeout occurs as specified by a member of this array
(in seconds). If a timeout has occurred, the packet is retransmitted
with the same XID (see RFC 1541) and the timeout is set to the next
positive number in the comma-separated list. The last element in the
list is negative or zero. After all specified timeouts have been
tried, the next action depends on options to the dhcpconf program. One
option is to fail; another is to retry forever. See dhcpconf(8) for
further information. If the last value is negative, DHCP suspends con-
figuration of the interface for an amount of time given by the negative
number terminating the array. During this time, the interface is con-
sidered idle; the client is not expecting responses destined for the
interface and will ignore any that arrive. When the idle time is over,
the client begins retransmitting with a timeout given by the first ele-
ment in the array and a new XID. If the last value is zero, the client
continues to use the same XID and timeout of the last positive value in
If there is no reply to DHCP, and use_saved_config is set, then use the
configuration stored in <interface>.cf from a previous invocation of
the protocol providing the lease is still valid.
The DHCP protocol requires clients to delay a random time interval on
booting, and after each timeout, before broadcasting to the net. This
is to prevent network "flooding" in the event that many clients try to
configure simultaneously (say after a sitewide power-up). This parame-
ter is the maximum delay that the client will tolerate. The actual
delay is randomized from zero to seconds. Note that on each timeout
the client will also delay, and that the second and subsequent delays
are also random, and need not be the same as the first.
Default: 10 seconds.
There may be many instances of the request keyword, each with a dif-
ferent parameter_name. Each parameter that is configurable through
DHCP and the server extensions is identified by a unique parameter.
Limited size of DHCP packets dictates that a client should not request
data which it cannot use. However, different DHCP servers, or different
server policies may dictate that a server return more configuration
than a client requested. For a description of the meaning of the vari-
ous parameters, consult RFC1542 and others to which it refers. Valid
options follow. The first group are DHCP generic: all_subnets_are_local
The following are specific to the DHCP server:
DARPA Internet Request For Comments RFC 1541, RFC 1542