[dhcp-agent-commits] dhcp-agent/doc part-1.texi,NONE,1.1 part-3.texi,NONE,1.1 part-2.texi,NONE,1.1 part-5.texi,NONE,1.1 part-4.texi,NONE,1.1 dhcp-agent.texi,1.2,1.3

[<act...@us...>]

Update of /cvsroot/dhcp-agent/dhcp-agent/doc
In directory sc8-pr-cvs1:/tmp/cvs-serv30594

Modified Files:
	dhcp-agent.texi 
Added Files:
	part-1.texi part-3.texi part-2.texi part-5.texi part-4.texi 
Log Message:
new docs with new layout

--- NEW FILE: part-1.texi ---
@node The dhcp-agent License
@chapter The dhcp-agent License
@cindex The dhcp-agent License

dhcp-agent is distributed under a revised BSD-like license:

@quotation
Copyright 2002, 2003 Thamer Alharbash <tmh@@whitefang.com>

 
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

  
  1. Redistributions of source code must retain the above copyright
     notice, this list of conditions and the following disclaimer.


  2. Redistributions in binary form must reproduce the above copyright
     notice, this list of conditions and the following disclaimer in
     the documentation and/or other materials provided with the
     distribution.


  3. The names of the authors may not be used to endorse or promote
     products derived from this software without specific prior
     written permission.

	 
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
@end quotation

@node Manual Layout
@chapter Manual Layout
@cindex Manual Layout

The dhcp-agent manual is divided into six parts:

An introductory part consists of five chapters on: the licensing
information, the layout of this manual, an overview of all the
components, an primer on the Dynamic Host Configuration Protocol, and
system specific notes.

Part two is reference material on invoking the components. This is
what you would typically expect from a man page. The dhcp-agent
distribution comes with man pages which have the same invocation
instructions in them. They are reproduced in this texinfo manual for
completeness sake only.

Part three discusses the configuration of the client and server. For
most purposes, the casual user of the client will not need to do any
configuration tweaking. The default configuration file for the client
should do for most installations.

Part four is for the advanced user who wants to take advantage of the
embedded Scheme interpreter (guile). Documentation is provided on the
hooks, files, and the API used to extend the components.

Part five is an overview of troubleshooting with the suite, and in
particular documents the output from the command line sniffer.

Finally an index is provided.

@node Components Overview
@chapter Components Overview
@cindex Components Overview

dhcp-agent currently ships with only two components, a command line
sniffer, and a DHCP client.

In the future a server and relay agent will be provided as well.

@node The Dynamic Host Configuration Protocol
@chapter The Dynamic Host Configuration Protocol
@cindex The Dynamic Host Configuration Protocol

The following is an overview of the Dynamic Host Configuration
Protocol (DHCP), and how dhcp-agent deals with some of the deficiences
of the protocol.

DHCP is based on the Bootstrap Protocol (BOOTP). It provides a
mechanism whereby configuration parameters can be distributed from a
central repository, a server or set of servers, to individual hosts,
which are running a DHCP client.

The protocol uses leases to pass configuration parameters between the
server and client. The term ``lease'' is used because the parameters
expire. Prior to lease expiration the client attempts to renew.

A DHCP client and server communicate via a set of primitive messages
which ideally allow the acquisition of leases to occur despite the
fact that the client does not have an initialized IP stack. This is
done by broadcasting IP datagrams, and later reverting to unicasting
when the client has acquired an IP address. Additionally, the User
Datagram Protocol (UDP) is used for DHCP which makes writing an ad-hoc
IP stack in the client easier.

The client begins by broadcasting a DHCP DISCOVER message to discover
what leases are available to it. The client can send a parameter
request list in its DHCP DISCOVER message which would request specific
configuration parameters to be offered back to it. It may also send a
message with no such list if it is not particular about the options it
wants to receive.

The DHCP servers which see the DHCP DISCOVER broadcast back the next
lease which is available via DHCP OFFER message which, ideally,
contains all the configuration parameters the client explicitly
requested, or all the configuration parameters the server has been
configured ot pass if the client did not request a specific list.

Unfortunately, RFC2131 leaves some ambiguity as to whether or not the
server should @strong{only} send specific options requested in the
parameter request list, or all options it has been configured
with. The dhcp-agent client can be configured to request specific
options, require that specific options are available in a response,
and configure only a set of specific options. This is a valuable
feature to get around uncooperative servers, or very generous servers.
@xref{Configuring dhcp-client}.

Once the client receives an offer for a suitable lease it responds
with a DHCP REQUEST which includes a server identifier refering to
whichever server the client has accepted the lease from. The server
then responds with a DHCP ACK, or a DHCP NACK, acknowledging or
retracting the offer, respectively.

If the client receives an acknowledgement it configures its host
with the values passed. Among the values passed is the lease expiry
time expressed in seconds. Additionally a ``renew'' and ``rebind''
time can also be passed from the server. The expiry, renew, and rebind
values are used to setup three timers. The first timer is the renew
timer when the client attempts to renew its lease by requesting it
again from the server it received the lease from. The rebind timer is
whenx the client attempts to renew its lease from broadcasting to any
server that can hear it. Finally, once the lease expires the client
will unconfigure the settings and attempt to discover a new lease.

Unfortunately, more ambigiouty exists with RFC2131. There is no
mention of what the client should do if it receives no expiry
time. dhcp-agent's client will assume an infinite time and never give
up its lease unless explicitly killed. @xref{Invoking dhcp-client}.

There is no mention of what the client should do if the lease received
during a rebind or renew differs from its own lease, except that the
client should notify the user. dhcp-agent allows additional rebind and
renew hooks in its sysconf script to handle this. @xref{Extending dhcp-client}.

And so the circle of life in the DHCP UNIXverse continues on. Kind of.

[ It should be noted that this protocol overview is client
centric. More will be added in the future when the server is 
closer to completion. ]

@node System Specific Notes
@chapter System Specific Notes
@cindex System Specific Notes

@section GNU/Linux

The client under Linux may not be entirely happy when applied to an
aliased interface. You will see some error messages, however things
should proceed OK.

@section Solaris

No major issues so far. Building the package may become
``interesting'' if you have not setup your build environment properly.

@section FreeBSD

Under FreeBSD the client, sniffer, and the server will make use of two
bpf devices. This is because of a limitation in dnet which makes it
only single directional for sending packets. Consequently libpcap is
used to open another bpf devices for reading. If you run out of bpf
devices you will need to compile a kernel with more bpf devices.

@section NetBSD

NetBSD ships with a pcap which does not come with @dfn{pcap_freecode}
this results in a small mem leak when the client reinitializes its raw
network code. To avoid this upgrade to the latest version of pcap and
nuke your old pcap library.

See above note for FreeBSD and BPF since it applies to all BSDs.

@section OpenBSD

OpenBSD has some brain damage with its bpf structure. Unlike the other
BSD flavors it insists on using unsigned instead of signed integers
for the number of seconds in its timestamp. This results in some
inaccuracy when calculating timeouts. Lobby your OpenBSD developers to
stop the brain damage.

See above note for FreeBSD and BPF since it applies to all BSDs.

--- NEW FILE: part-3.texi ---
@node Configuration Intro
@chapter Configuration Intro
@cindex Configuration Intro

This section describes configuration of the dhcp-agent components.

@section The Configuration File Parser

All configurable components use a single parser, which follows a
simple grammar and accepts the same type of tokens. This is good news
since it means the configuration files will look very similar. The
only differences will be the directives each component accepts.

@section The Tokens

The parser accepts a set of tokens which it uses to build complete
statements.

@itemize

@item
string

Strings can be a single alphanumeric contiginous string of characters,
a quoted alphanumeric string of characters, and may contain other
characters as long as they are preceeded by a backslash. If newlines
are present, they may only be present in a quoted string and must be
preceeded by a backslash.

examples: 

@example
foobar
@end example

@example
``foo bar''
@end example

@example
``foo:bar''
@end example

@example
``foo \
  bar''
@end example

@item
assignment: 

The equal character (``='') signifies assignment.

examples:

@example
foo = bar
@end example

@example
blah = "foo bar"
@end example

@item
blocks: 

Grouping can be done via blocks which begin with a ``@{`` character
and are terminated by a ``@}'' character

examples:

@example
foo @{
        bar = foo
@}
@end example

@item
terminator: 

The semicolon (``;'') character is used to terminate statements.

examples:

@example
foo = bar;
@end example

@item
lists: 

Commas (``,'') are used to denote a list of items. Currently lists of
strings are used.

@example
foo = bar, blah;
@end example

@end itemize

As the reader has noted, anything except a few special characters
defaults to a string which is then evaluated at a higher level.

@section Directives

The configuration files are made up of directives which in turn are
made up of the above tokens. Each directive begins with an identifier
and is terminated by the terminator (``;'').

@example

set foo = blah;

@end example

Here ``set'' is the identifier, or the command name, and what follows
is dependant on the command. The chapters below will describe all the
configuration directives for the components of dhcp-gent.

@node Configuring dhcp-client
@chapter Configuring dhcp-client
@cindex Configuring dhcp-client

@section The Configuration Files

dhcp-client will look for two files for a configuration
information. Both these files should be located in the system
configuration directory. By default this is defined as
@file{/usr/local/etc} You can change this definition at build time by
specifying a different prefix to the @command{configure} script.

The first file that is checked for begins with the name of the
interface the client is configuring. For example, if the name of our
interface is ``xl0'' then the configuration file to be checked will be
@file{/usr/local/etc/dhcp-agent/dhcp-client/xl0.conf}

If this file does not exist then the default configuration file is
@file{/usr/local/etc/dhcp-agent/dhcp-client/default.conf}

This allows dhcp-client to accept configuration per interface, and use
a default file without forcing the user to name interfaces in the
actual configuration file. It is believed that configuration files are
more portable this way and are not dependant on interface names by
avoiding having to specify interface names in the configuration file.

@section Configuration Directives


@subheading DHCP Option Handling

The following directives affect DHCP option handling by the client

@deffn {Client Configuration Directive} request

This directive instructs the client to request a
set of dhcp options. The request directive accepts a list of strings
which name the options to be requested:

@example
request subnet-mask, ip-address-lease-time, renewal-time,
        rebinding-time, interface-mtu, domain-name, domain-name-servers;
@end example

@end deffn

@deffn {Client Configuration Directive} require

This directive instructs the client to require a set of dhcp options
to be passed before accepting the lease. This is useful to make sure
you receive a minimum of desired options. If these options are never
met the client will eventually timeout. If this directive is not set,
the first DHCP lease offer will be accepted.

@example
require subnet-mask, ip-address-lease-time, renewal-time,
        rebinding-time, interface-mtu;
@end example

@end deffn

@deffn {Client Configuration Directive} configure

This directive instructs the client to only
configure a set of dhcp options. This is useful if the server is
passing you options you would rather not configure but implicitly
claim to configure by accepting the lease. This directive does not
define how options are configured. In order to define how
configuration is done see ``Writing Client Extensions,'' for more info.

@example
configure subnet-mask, ip-address-lease-time, renewal-time,
          rebinding-time, interface-mtu, domain-name, domain-name-servers;
@end example

@end deffn

@deffn {Client Configuration Directive} append

This directive instructs the client to append a
value to a DHCP option prior to system configuration. If this option
is a list of values, the value specified is merely appended. If this
value is a string the value is appended to the string. If this option
is a single datum then you should be using the override option
instead.
@example
append domain-name-servers = 127.0.0.1, 192.168.0.1;
@end example

@end deffn

@deffn {Client Configuration Directive} prepend

This directive works the same as the append
directive only the values are placed at the beginning of the list or
string. You should not use prepend on single datum options and should
use override instead.

@example
prepend domain-name-servers = 127.0.0.1, 192.168.0.1;
@end example

@end deffn

@deffn {Client Configuration Directive} override

This directive instructs the client to
overwrite a DHCP option with a specified value prior to system
configuration. This is useful to for clients that wish to use an
alternate value for a DHCP option than the one passed by the DHCP
server.

@example
override domain-name = "example.com";
@end example

@end deffn

@subheading Variable Settings

@deffn {Client Configuration Directive} set

This directive instructs the client to set a variable to
a defined value.

@example
set default-subnet-mask = 255.255.255.0;
@end example

@end deffn

@deffn {Client Configuration Directive} enable

This directive instructs the client to set a boolean
variable to a defined value. The boolean variable only accepts ``yes'' or
``no'' for values.

@example
enable do-measure-router-latency = no;
@end example

@end deffn

@subheading Configurable Variables

dhcp-client accepts a number of variables to configure default values,
values passed to the server, and control some of its behaviour.

@defvr {Client Configuration Variable} hostname

This variable can be set to a string which is passed as
the hostname DHCP option to the server. This allows servers to pass
configuration based on a hostname passed by the client. It will also
instruct the client to set the hostname to that variable. If you want
to pass a hostname to the server you should set this variable and not
use the ``override'' directive because the ``override'' directive only
affects system configuration.

@example
set hostname = "foo.example.com";
@end example


@end defvr

@defvr {Client Configuration Variable} dhcp-discovery-retries 

This variable can be set to an integer value
which instructs the client on how many times it should retry a DHCP
discover before it gives up.

@example
set dhcp-discovery-retries = 3;
@end example

@end defvr

@defvr {Client Configuration Variable} icmp-retries 

This variable can be set to an integer value which
instructs the client on how many times it should retry an ICMP
operation. This affects operations such as router latency discovery,
ICMP netmask discovery etc.

@example
set icmp-retries = 3;
@end example

@end defvr

@defvr {Client Configuration Variable} default-interface-mtu

This variable can be set to an integer value
which instructs the client on what it's default interface MTU should
be. This MTU is used during the initial DHCP discovery messages, and
later used to configure the interface MTU if no MTU was specified by
the DHCP server.

@example
set default-interface-mtu = 1500;
@end example

@end defvr

@defvr {Client Configuration Variable} default-subnet-mask

This variable can be set to a netmask value to
specify a default subnet mask in case none is provided by the DHCP
operation. Unlike the ``override'' directive this provides a fallback
in case no subnet-mask is provided by the server.

@example
set default-subnet-mask = 255.255.255.0;
@end example

@end defvr

@defvr {Client Configuration Variable} do-measure-router-latency

This variable can be set to a boolean
value to indicate whether or not the client should attempt to send
ICMP ECHO requests to routers passed by the DHCP server and determine
which is one has the least latency to become the default
route. Disabling this variable stops this operation from taking place,
and the first router is used as the default route. This is useful if
the routers cannot be reached by ICMP ECHO requests.

@example
enable do-measure-router-latency = yes;
@end example

@end defvr

@node Configuring dhcp-server
@chapter Configuring dhcp-server
@cindex Configuring dhcp-server

[TODO]

@node Configuring dhcp-relay
@chapter Configuring dhcp-relay
@cindex Configuring dhcp-relay

[TODO]

--- NEW FILE: part-2.texi ---
@node Invoking dhcp-client
@chapter Invoking dhcp-client
@cindex Invoking dhcp-client

dhcp-client runs on a per interface basis. By default the client will
start up, look for the first ethernet interface which is down, and
attempt to use it to perform DHCP operations through. You can force
the client to use a specific interface by referring it to a particular
interface. @xref{Invoking dhcp-client, Command Line Options}.

@section Command Line Options

@itemize

@item
-h     Print out usage.


@item
-v     Print out version information


@item
-a     

Always run in the foreground and do not go into the background.

@item
-c     

Clear the cache. This is useful in case a stale cache is left behind
by an earlier invocation.

@item
-k 

Kill a dhcp-client instance. Coupled with the -i option this will kill
a specific instance of dhcp-client. Otherwise the first dhcp-client
found on an active ethernet interface is terminated.

@item
-p     

Forces dhcp-client to use promiscious mode. This is only useful on
systems which are sufficiently broken that require promiscious mode
to receive broadcast messages.

@item
-w     

Wake a dhcp-client instance. Coupled with the -i option this will wake
up a client on a specified interface and cause it to either rebind, or
renew earlier depending on which timer is next. Use this to force the
client to reacquire a lease.

@item
-s

Print out status information on the most recent lease acquired by
the client.

@item
-i @dfn{interface}

Force dhcp-client to use the interface specified.  This is useful to
make sure dhcp-client uses a specific interface if the host is
multi-homed.

@item
-l @dfn{level}

Generate messages at the level specified. The level should be an
integer between 0 - 4. The levels are no messages, error messages,
info messages (default), warnings, diagnostic-messages, respectively.
Each level includes all messages below it.  The default is info
messages which also include error messages.

@item
-m @dfn{mac address}

Fake a mac address during the DHCP operation. This will only affect
the DHCP operations and no others.  This is useful for debugging a
DHCP server that is not behaving itself.

@end itemize

@node Invoking dhcp-server
@chapter Invoking dhcp-server
@cindex Invoking dhcp-server

[TODO]

@node Invoking dhcp-sniff
@chapter Invoking dhcp-sniff
@cindex Invoking dhcp-sniff

[TODO]

@node Invoking dhcp-relay
@chapter Invoking dhcp-relay
@cindex Invoking dhcp-relay

[TODO]

--- NEW FILE: part-5.texi ---
@node dhcp-sniff Output Format
@chapter dhcp-sniff Output Format
@cindex dhcp-sniff Output Format

[TODO]

@node dhcp-client Lease Introspection
@chapter dhcp-client Lease Introspection
@cindex dhcp-client Lease Introspection

[TODO]

@node dhcp-server Lease Introspection
@chapter dhcp-server Lease Introspection
@cindex dhcp-server Lease Introspection

[TODO]

--- NEW FILE: part-4.texi ---
@node Extensions Intro
@chapter Extensions Intro
@cindex Extensions Intro

[TODO]

@node Extending dhcp-client
@chapter Extending dhcp-client
@cindex Extending dhcp-client

dhcp-client uses guile (GNU's Ubiquitous Intelligent Language for
Extensions) to extend itself. Extensions can currently be written for
handling DHCP options during system configuration time. Essentially,
the extension script defines how the client configures the local
system according to the DHCP options passed.

The rest of this section assumes you are familiar with the Scheme
programming language. If you are not familiar with the Scheme
programming language then you cannot extend the client to configure
options it is not programmed to handle.

@section The Client Sysconf Script

dhcp-client calls a sysconf script which is placed in the same
directory as the configuration file. This script, like the
configuration file, can be named either ``default.sysconf'' or after
an interface name. The file naming convention is the same as the
configuration file. @xref{Configuring dhcp-client}.

@section Looking At The Sysconf Script

The default sysconf script which is shipped with dhcp-agent is made up
of several lambda expressions which are placed inside closures. If
you're not familiar with the concept of closures, refer to the guile
documentation.

Under each closure is a configure/unconfigure lambda expression which
are bound to top level symbols. These symbols are then placed in two
hooks, one for the bound state, and one for the release state.

@subsection The DNS Configuration: An Example

We'll walk through the DNS configuration (a very simple example) to
see how it was written. After this example a more in-depth discussion
follows. If you notice some details are skipped over, don't worry. It
will become clear later.

@example
(define configure-dns #f)
(define unconfigure-dns #f)
@end example

First we define two top level symbols to false. We'll later bind
against these in the closure.

@example
(let ((configured-domain-name #f)
       (configured-domain-name-servers #f)
@end example

We begin the closure by defining two variables which will be used to
hold any configured domain name and domain name servers. For DNS
configuration these aren't useful, but for other sysconf code keeping
the values of configured data is useful when it comes time to
unconfigure the system on a DHCP RELEASE.

@example
      ; check to see if we really need to configure
       (do-configure 
        (lambda()
          (and (client-configure? client-control
          'dhcp-domain-name-servers) 
               (client-configure? client-control 'dhcp-domain-name)
               (defined? 'dhcp-domain-name-servers)
               (defined? 'dhcp-domain-name)))))
@end example

Here we define a lambda expression which will tell us whether or not
we should be performing any configuration for dns. The expression will
return true if the options ``domain-name-servers'' and ``domain-name''
have been passed to us by the DHCP server. Also it checks if the user
has requested that we configure these options.

@example
  ; configure dns options
  (set! configure-dns

        (lambda ()
          (if (do-configure)
              (let ((resolv-conf-file-port (open "/etc/resolv.conf" (logior O_WRONLY O_TRUNC)  0644)))
                (client-info-message "configuring resolver")
                (map-in-order
                 (lambda (dns-server)
                   (simple-format resolv-conf-file-port "nameserver ~A\n" dns-server))  dhcp-domain-name-servers)
                (simple-format resolv-conf-file-port "search ~A\n" dhcp-domain-name)
                (close-port resolv-conf-file-port)

                                        ; now setup the options so we can use them again in unconfigure.
                (set! configured-domain-name dhcp-domain-name)
                (set! configured-domain-name-servers dhcp-domain-name-servers)))))

@end example

The ``configure-dns'' function will first check if ``do-configure''
returns true. It will then open ``/etc/resolv.conf'' and notify the
user that the resolver is being configured. It then writes out the
contents of the string list ``dhcp-domain-name-servers'' to the file
prefixing each string with the keyword ``nameserver.'' Finally the
``search'' keyword is written with the domain name.

After the configuration is complete, the values are stored in
``configured-domain-name'' and ``configured-domain-name-servers.''
This allows us to remember the values in the event of unconfiguring
the system.

@example
                                        ; unconfigure dns options
  (set! unconfigure-dns
        (lambda()

         ; We shouldn't really be doing anything. Any name server
         ; is a good server :-)

          #t)))
@end example

As mentioned in the comment there's no need to do any
unconfiguration. We'd rather have a resolv.conf than delete it. You
can always modify this to delete the file, or insert a different set
of values.

@example

(add-hook! dhcp-bind-hook configure-dns)
(add-hook! dhcp-release-hook unconfigure-dns)

@end example

Finally the two routines are bound to the DHCP BIND and DHCP RELEASE
hooks. It is important to add the option handlers in reverse
order. You'll notice ``configure-interface'' is added last so that the
interface is configured first.

@subsection The DHCP BOUND and DHCP RELEASE hooks

Two hooks are defined at the top level by the
client. ``dhcp-bind-hook'' and ``dhcp-release-hook.'' When the client
wants to configure itself it will call ``dhcp-bind-hook'' and when it
releases its lease it will call ``dhcp-release-hook.''

@subsection How DHCP Options Are Passed To The Sysconf Script

When the DHCP BOUND hook is called, all the options are defined as
top level symbols which refer to either a string, or a list of strings
depending on whether the option is a single atom, or a list of atoms
[ TODO: make list of handled options along with their types. ]

In order to check for the existance of an option, simple use
``defined?'' to check if the symbol is bound.

@example

; check for the routers option

(defined? 'dhcp-routers)

@end example

This will return a boolean value of true of false depending on whether
the DHCP option has been bound at the top level.

@section Scheme Procedures Provided By The Client

At the top level a ``client-control'' symbol is bound to a control
object which is used in every invocation of routines provided by the
client.

@deffn {Client Sysconf Routine} client-configure? client-control option-symbol

Returns #t of #f depending on whether or not the user has explicitly
stated that the dhcp option should be configured.

@end deffn

@deffn {Client Sysconf Routine} client-interface-up client-control ip-address netmask mtu

Initializes the network interface the client is handling and assigns
the requested @var{ip-address}, the @var{netmask} and @var{mtu}.

@end deffn

@deffn {Client Sysconf Routine} client-set-default-route client-control ip-address

Sets the default route to the @var{ip-address} specified.

@end deffn

@deffn {Client Sysconf Routine} client-remove-default-route client-control ip-address

Removes the default route to the @var{ip-address} specified.

@end deffn

@deffn {Client Sysconf Routine} client-get-default-mtu client-control

Returns the default mtu specified by the user.

@end deffn

@deffn {Client Sysconf Routine} client-get-default-subnet-mask client-control

Returns the default subnet-mask specified by the user.

@end deffn

@deffn {Client Sysconf Routine} client-info-message  string

Prints out the string using the client's @dfn{info_message} routine.

@end deffn

@deffn {Client Sysconf Routine} client-error-message string

Prints out the string using the client's @dfn{error_message} routine.

@end deffn

@deffn {Client Sysconf Routine} client-fatal-message string

Prints out the string using the client's @dfn{fatal_message}
routine. This exits after passing the message to the user.

@end deffn

@deffn {Client Sysconf Routine} client-shutdown client-control

Invokes the @dfn{shutdown} routine in the client and causes the
client to exit as cleanly as possible, relinquishing any leases it
has. Warning! This should not be called from within a release hook.

@end deffn

@deffn {Client Sysconf Routine} client-discover-icmp-latency client-control address-list

Accepts a list of addresses @var{address-list} and performs ICMP ECHO
latency tests to determine which host is responding fastest. A list of
address/average-latency pairs is returned.

@end deffn

@deffn {Client Sysconf Routine} client-do-discover-icmp-latency client-control

Returns #t if the user enabled ``do-measure-router-latency'' or #f if
not.

@end deffn

@node Extending dhcp-server
@chapter Extending dhcp-server
@cindex Extending dhcp-server

[TODO]

Index: dhcp-agent.texi
===================================================================
RCS file: /cvsroot/dhcp-agent/dhcp-agent/doc/dhcp-agent.texi,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** dhcp-agent.texi	18 May 2003 03:25:44 -0000	1.2
--- dhcp-agent.texi	22 Jul 2003 20:18:53 -0000	1.3
***************
*** 15,18 ****
--- 15,24 ----
  @node Top
  @top dhcp-agent
+ 
+ This is the reference manual for dhcp-agent, an extendable, portable
+ UNIX DHCP suite. It contains a brief introduction on DHCP, and an
+ overview of the suite's features, and is a reference to its operation
+ and features.
+ 
  @end ifnottex
  
***************
*** 20,37 ****
  @c ** add new menu items here.
  @menu
! * Introduction::
! * dhcp-client::
! * dhcp-server::
! * dhcp-sniff::
! * dhcp-relay::
  @end menu
  
  @contents
  
! @include introduction.texi
! @include dhcp-client.texi
! @include dhcp-server.texi
! @include dhcp-sniff.texi
! @include dhcp-relay.texi
  
  @bye
--- 26,78 ----
  @c ** add new menu items here.
  @menu
! 
! Part I: Introduction to dhcp-agent.
! 
! * The dhcp-agent License::
! * Manual Layout::
! * Components Overview::
! * The Dynamic Host Configuration Protocol::
! * System Specific Notes::
! 
! Part II: Invoking the dhcp-agent components.
! 
! * Invoking dhcp-client::
! * Invoking dhcp-server::
! * Invoking dhcp-sniff::
! * Invoking dhcp-relay::
! 
! Part III: Configuration
! 
! * Configuration Intro::
! * Configuring dhcp-client::
! * Configuring dhcp-server::
! * Configuring dhcp-relay::
! 
! Part IV: Writing Extensions
! 
! * Extensions Intro::
! * Extending dhcp-client::
! * Extending dhcp-server::
! 
! Part V: Troubleshooting and Diagnostics
! 
! * dhcp-sniff Output Format::
! * dhcp-client Lease Introspection::
! * dhcp-server Lease Introspection::
! 
! Appendix
! 
! * DHCP Options::
! 
  @end menu
  
  @contents
  
! @include part-1.texi
! @include part-2.texi
! @include part-3.texi
! @include part-4.texi
! @include part-5.texi
! @include appendix.texi
  
  @bye