listing for C
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
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
packets. 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
parameter, 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
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
packets. 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
configuration of the interface for an amount of time given by the
negative number terminating the array. During this time, the interface
is considered 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 element 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 the array.
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
parameter 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
different 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
various parameters, consult RFC1542 and others to which it refers.
Valid options follow. The first group are DHCP generic:
The following are specific to the DHCP server:
DARPA Internet Request For Comments RFC 1541, RFC 1542
listing for C