unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Page:
Section:
Apropos / Subsearch:
optional field



client.pcy(4)							client.pcy(4)



NAME

  client.pcy - BOOTP and DHCP client policy

DESCRIPTION

  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.

  FORMAT


  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-
  ten.

  KEYWORDS AND VALUES


  accept_bootp
      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.

  arp_timeout seconds
      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.

  class_id
      The client's class ID. Consult RFC1541 for details.

  client_id
      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).

  lease_desired	seconds
      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
      required.
      Default: 0

  retry_broadcast integer
      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.
      Default: 2

  timeouts value,value,value....
      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
      the array.
      Default: 4,8,16,32,0

  use_saved_config
      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.

  wait_before_broadcast	seconds
      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.

  request parameter_name
      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
      arp_cache_timeout
      boot_file
      boot_file_server
      boot_size
      broadcast_address
      cookie_server
      default_ip_time-to-live
      dns_domain_name
      dns_servers
      ethernet_encapsulation
      extensions_path
      home_directory
      host_name
      impress_server
      interface_mtu
      ip_forwarding
      keepalive_garbage
      lease_time
      log_server
      lpr_server
      mask_supplier
      maximum_datagram_reassembly_size
      merit_dump_file
      name_server
      netbios_datagram_distribution_server
      netbios_name_server
      netbios_node_type
      netbios_scope
      nis_domain_name
      nis_server
      non-local_source_routing
      ntp_server
      path_mtu_aging_timeout
      path_mtu_plateau_table
      perform_mask_discovery
      perform_router_discovery
      policy_filter
      rebinding_time_value
      renewal_time_value
      resource_location_server
      root_path
      router
      router_solicitation_address
      static_routes
      subnet_mask
      swap_server
      tcp_default_time_to_live
      tcp_keepalive_interval
      time_offset
      time_server_(rfc_868)
      trailer_encapsulation
      x_window_display_manager
      x_windows_font_server

      The following are	specific to the	DHCP server:

      nfs_mounted_file_systems
      svr4_printer_setup
      printers

RELATED	INFORMATION

  joinc(8)
  DARPA	Internet Request For Comments RFC 1541,	RFC 1542