dhclient

package: dhcp-client

title: dhclient(8)

text:
# dhclient(8)

## NAME
dhclient - Dynamic Host Configuration Protocol Client

## SYNOPSIS
dhclient [ -4 | -6 ] [ -S ] [ -N [ -N... ] ] [ -T [ -T... ] ] [ -P [ -P... ] ] [ -R ] [ -i ] [ -I ] [ -4o6 port ] [ -D LL|LLT ] [ -p port-number ] [ -d ] [ -df duid-lease-file ] [ -e VAR=value ] [ -q ] [ -1 ] [ --onetime ] [ --nounicast ] [ -r | -x ] [ -lf lease-file ] [ -pf pid-file ] [ --no-pid ] [ -cf config-file ] [ -sf script-file ] [ -s server-addr ] [ -g relay ] [ -n ] [ -nw ] [ -w ] [ -B ] [ -C dhcp-client-identifier ] [ -H host-name ] [ -F fqdn.fqdn ] [ -V vendor-class-identifier ] [ --request-options request-option-list ] [ --timeout timeout ] [ --dad-wait-time seconds ] [ --prefix-len-hint length ] [ --decline-wait-time seconds ] [ -v ] [ --version ] [ if0 [ ...ifN ] ]

## DESCRIPTION
The Internet Systems Consortium DHCP Client, dhclient, provides a means for configuring one or more network interfaces using the Dynamic Host Configuration Protocol, BOOTP protocol, or if these protocols fail, by statically assigning an address.

## OPERATION
The DHCP protocol allows a host to contact a central server which maintains a list of IP addresses which may be assigned on one or more subnets. A DHCP client may request an address from this pool, and then use it on a temporary basis for communication on network. The DHCP protocol also provides a mechanism whereby a client can learn important details about the network to which it is attached, such as the location of a default router, the location of a name server, and so on.

There are two versions of the DHCP protocol DHCPv4 and DHCPv6. At startup the client may be started for one or the other via the -4 or -6 options.

On startup, dhclient reads the dhclient.conf for configuration instructions. It then gets a list of all the network interfaces that are configured in the current system. For each interface, it attempts to configure the interface using the DHCP protocol.

In order to keep track of leases across system reboots and server restarts, dhclient keeps a list of leases it has been assigned in the dhclient.leases file. On startup, after reading the dhclient.conf file, dhclient reads the dhclient.leases file to refresh its memory about what leases it has been assigned.

When a new lease is acquired, it is appended to the end of the dhclient.leases file. In order to prevent the file from becoming arbitrarily large, from time to time dhclient creates a new dhclient.leases file from its in-core lease database. The old version of the dhclient.leases file is retained under the name dhclient.leases~ until the next time dhclient rewrites the database.

Old leases are kept around in case the DHCP server is unavailable when dhclient is first invoked (generally during the initial system boot process). In that event, old leases from the dhclient.leases file which have not yet expired are tested, and if they are determined to be valid, they are used until either they expire or the DHCP server becomes available.

A mobile host which may sometimes need to access a network on which no DHCP server exists may be preloaded with a lease for a fixed address on that network. When all attempts to contact a DHCP server have failed, dhclient will try to validate the static lease, and if it succeeds, will use that lease until it is restarted.

A mobile host may also travel to some networks on which DHCP is not available but BOOTP is. In that case, it may be advantageous to arrange with the network administrator for an entry on the BOOTP database, so that the host can boot quickly on that network rather than cycling through the list of old leases.

## COMMAND LINE
The names of the network interfaces that dhclient should attempt to configure may be specified on the command line. If no interface names are specified on the command line dhclient will normally identify all network interfaces, eliminating non-broadcast interfaces if possible, and attempt to configure each interface.

It is also possible to specify interfaces by name in the dhclient.conf file. If interfaces are specified in this way, then the client will only configure interfaces that are either specified in the configuration file or on the command line, and will ignore all other interfaces.

The client normally prints no output during its startup sequence. It can be made to emit verbose messages displaying the startup sequence events until it has acquired an address by supplying the -v command line argument. In either case, the client logs messages using the syslog(3) facility.

## OPTIONS
-4

Use the DHCPv4 protocol to obtain an IPv4 address and configuration parameters. This is the default and cannot be combined with -6.

-6

Use the DHCPv6 protocol to obtain whatever IPv6 addresses are available along with configuration parameters. It cannot be combined with -4. The -S -T -P -N and -D arguments provide more control over aspects of the DHCPv6 processing. Note: it is not recommended to mix queries of different types together or even to share the lease file between them.

-4o6 port

Participate in the DHCPv4 over DHCPv6 protocol specified by RFC 7341. This associates a DHCPv4 and a DHCPv6 client to allow the v4 client to send v4 requests encapsulated in a v6 packet. Communication between the two clients is done on a pair of UDP sockets bound to ::1 port and port + 1. Both clients must be launched using the same port argument.

-1

Try to get a lease once. On failure exit with code 2. In DHCPv6 this sets the maximum duration of the initial exchange to timeout (from dhclient.conf with a default of sixty seconds).

--onetime, -onetime

Similar to above, but on successful configuration exit with code 0.

-d

Force dhclient to run as a foreground process. Normally the DHCP client will run in the foreground until is has configured an interface at which time it will revert to running in the background. This option is useful when running the client under a debugger, or when running it out of inittab on System V systems. This implies -v.

-nw

Become a daemon immediately (nowait) rather than waiting until an IP address has been acquired.

-q

Be quiet at startup, this is the default.

-v

Enable verbose log messages.

-w

Continue running even if no broadcast interfaces were found. Normally DHCP client will exit if it isn't able to identify any network interfaces to configure. On laptop computers and other computers with hot-swappable I/O buses, it is possible that a broadcast interface may be added after system startup. This flag can be used to cause the client not to exit when it doesn't find any such interfaces. The omshell(1) program can then be used to notify the client when a network interface has been added or removed, so that the client can attempt to configure an IP address on that interface.

-B

Set the BOOTP broadcast flag in request packets so servers will always broadcast replies.

-C <dhcp-client-identifier>

Specify the dhcp-client-identifier option to send to the DHCP server.

-H <host-name>

Specify the host-name option to send to the DHCP server. The host-name string only contains the client's hostname prefix, to which the server will append the ddns-domainname or domain-name options, if any, to derive the fully qualified domain name of the client. The -H option cannot be used with the -F option.

-F <fqdn.fqdn>

Specify the fqdn.fqdn option to send to the DHCP server. This option cannot be used with the -H option. The fqdn.fqdn option must specify the complete domain name of the client host, which the server may use for dynamic DNS updates.

-V <vendor-class-identifier>

Specify the vendor-class-identifier option to send to the DHCP server.

--request-options, -request-options <option>[,<option>...]

Specify the list of options the client is to request from the server. The option list must be a single string consisting of option names separated by at least one command and optional space characters. The default option list is:

subnet-mask, broadcast-address, time-offset, routers,

domain-search, domain-name, domain-name-servers, host-name,

nis-domain, nis-servers, ntp-servers, interface-mtu

Note that --request-options option does not append options to the default request, it overrides the default request list. Keep this in mind if you want to request an additional option besides the default request list. You will have to specify all option names for the --request-options parameter.

--timeout, -timeout <timeout>

Specify the time after which dhclient will decide that no DHCP servers can be contacted when no responses have been received.

-n

Do not configure any interfaces. This is most likely to be useful in combination with the -w flag.

--nounicast, -nounicast

Do not send unicast requests for refreshing the configuration. Makes sense when connected to the switch acting as a DHCP Relay.

-e VAR=value

Define additional environment variables for the environment where dhclient-script executes. You may specify multiple -e options on the command line.

-r

Release the current lease and stop the running DHCP client as previously recorded in the PID file. When shutdown via this method dhclient-script will be executed with the specific reason for calling the script set. The client normally doesn't release the current lease as this is not required by the DHCP protocol but some cable ISPs require their clients to notify the server if they wish to release an assigned IP address.

-x

Stop the running DHCP client without releasing the current lease. Kills existing dhclient process as previously recorded in the PID file. When shutdown via this method dhclient-script will be executed with the specific reason for calling the script set.

-p port-number

The UDP port number on which the DHCP client should listen and transmit. If unspecified, dhclient uses the default port of 68. This is mostly useful for debugging purposes. If a different port is specified on which the client should listen and transmit, the client will also use a different destination port - one less than the specified port.

-s server-addr

Specify the server IP address or fully qualified domain name to use as a destination for DHCP protocol messages before dhclient has acquired an IP address. Normally, dhclient transmits these messages to 255.255.255.255 (the IP limited broadcast address). Overriding this is mostly useful for debugging purposes. This feature is not supported in DHCPv6 (-6) mode.

-g relay

Set the giaddr field of all packets to the relay IP address simulating a relay agent. This is for testing purposes only and should not be expected to work in any consistent or useful way.

-i

Use a DUID with DHCPv4 clients. If no DUID is available in the lease file one will be constructed and saved. The DUID will be used to construct a RFC4361 style client id that will be included in the client's messages. This client id can be overridden by setting a client id in the configuration file. Overriding the client id in this fashion is discouraged.

-I

Use the standard DDNS scheme from RFCs 4701 & 4702.

--decline-wait-time seconds

Specify the time (in seconds) that an IPv4 client should wait after declining an address before issuing a discover. The default is 10 seconds as recommended by RFC 2131, Section 3.1.5. A value of zero equates to no wait at all.

--version Print version number and exit.

Options available for DHCPv6 mode:

-S

Use Information-request to get only stateless configuration parameters (i.e., without address). This implies -6. It also doesn't rewrite the lease database.

-T

Ask for IPv6 temporary addresses, one set per -T flag. This implies -6 and also disables the normal address query. See -N to restore it.

-P

Enable IPv6 prefix delegation. This implies -6 and also disables the normal address query. See -N to restore it. Multiple prefixes can be requested with multiple -P flags. Note only one requested interface is allowed.

-R

Require that responses include all of the items requested by any -N, -T, or -P options. Normally even if the command line includes a number of these the client will be willing to accept the best lease it can even if the lease doesn't include all of the requested items. This option causes the client to only accept leases that include all of the requested items. Note well: enabling this may prevent the client from using any leases it receives if the servers aren't configured to supply all of the items.

-D LL or LLT

Override the default when selecting the type of DUID to use. By default, DHCPv6 dhclient creates an identifier based on the link-layer address (DUID-LL) if it is running in stateless mode (with -S, not requesting an address), or it creates an identifier based on the link-layer address plus a timestamp (DUID-LLT) if it is running in stateful mode (without -S, requesting an address). When DHCPv4 is configured to use a DUID using -i option the default is to use a DUID-LLT. -D overrides these default, with a value of either LL or LLT.

-N

Restore normal address query for IPv6. This implies -6. It is used to restore normal operation after using -T or -P. Multiple addresses can be requested with multiple -N flags.

--address-prefix-len length

Specify the length of the prefix for IPv6 addresses. This value is passed by dhclient into the client script via the environment variable, ip6_prefixlen, when binding IPv6 addresses. The default value is 128. Alternatively you may change the default at compile time by setting DHCLIENT_DEFAULT_PREFIX_LEN in includes/site.h.

--dad-wait-time seconds

Specify maximum time (in seconds) that the client should wait for the duplicate address detection (DAD) to complete on an interface. This value is propagated to the dhclient script in a dad_wait_time environment variable. If any of the IPv6 addresses on the interface are tentative (DAD is in progress), the script will wait for the specified number of seconds for DAD to complete. If the script ignores this variable the parameter has no effect.

--prefix-len-hint length

When used in conjunction with -P, it directs the client to use the given length to use a prefix hint of, "::/length", when requesting new prefixes.

Modifying default file locations: The following options can be used to modify the locations a client uses for its files. They can be particularly useful if, for example, /var/lib/dhcp/dhclient/state or RUNDIR have not been mounted when the DHCP client is started.

-cf config-file

Path to the client configuration file. If unspecified, the default ETCDIR/dhcp/dhclient.conf is used. See dhclient.conf(5) for a description of this file.

-df duid-lease-file

Path to a secondary lease file. If the primary lease file doesn't contain a DUID this file will be searched. The DUID read from the secondary will be written to the primary. This option can be used to allow an IPv4 instance of the client to share a DUID with an IPv6 instance. After starting one of the instances the second can be started with this option pointing to the lease file of the first instance. There is no default. If no file is specified no search is made for a DUID should one not be found in the main lease file.

-lf lease-file

Path to the lease database file. If unspecified, the default /var/lib/dhcp/dhclient/state/dhclient.leases is used. See dhclient.leases(5) for a description of this file.

-pf pid-file

Path to the process ID file. If unspecified, the default RUNDIR/dhclient.pid is used.

--no-pid

Option to disable writing pid files. By default the program will write a pid file. If the program is invoked with this option it will not attempt to kill any existing client processes even if invoked with -r or -x.

-sf script-file

Path to the network configuration script invoked by dhclient when it gets a lease. If unspecified, the default CLIENTBINDIR/dhclient-script is used. See dhclient-script(8) for a description of this file.

## PORTS
During operations the client may use multiple UDP ports to provide different functions. Which ports are opened depends on both the way you compiled your code and the configuration you supply. The following should provide you an idea of what ports may be in use.

Normally a DHCPv4 client will open a raw UDP socket to receive and send most DHCPv4 packets. It also opens a fallback UDP socket for use in sending unicast packets. Normally these will both use the well known port number for BOOTPC.

For DHCPv6 the client opens a UDP socket on the well known client port and a fallback UDP socket on a random port for use in sending unicast messages. Unlike DHCPv4 the well known socket doesn't need to be opened in raw mode.

If you have included an omapi port statement in your configuration file then the client will open a TCP socket on that port to listen for OMPAI connections. When something connects another port will be used for the established connection.

When DDNS is enabled at compile time (see includes/site.h) the client will open both a v4 and a v6 UDP socket on random ports. These ports are not opened unless/until the client first attempts to do an update. If the client is not configured to do updates, the ports will never be opened.

## CONFIGURATION
The syntax of the dhclient.conf(5) file is discussed separately.

## OMAPI
The DHCP client provides some ability to control it while it is running, without stopping it. This capability is provided using OMAPI, an API for manipulating remote objects. OMAPI clients connect to the client using TCP/IP, authenticate, and can then examine the client's current status and make changes to it.

Rather than implementing the underlying OMAPI protocol directly, user programs should use the dhcpctl API or OMAPI itself. Dhcpctl is a wrapper that handles some of the housekeeping chores that OMAPI does not do automatically. Dhcpctl and OMAPI are documented in dhcpctl(3) and omapi(3). Most things you'd want to do with the client can be done directly using the omshell(1) command, rather than having to write a special program.

## THE CONTROL OBJECT
The control object allows you to shut the client down, releasing all leases that it holds and deleting any DNS records it may have added. It also allows you to pause the client - this unconfigures any interfaces the client is using. You can then restart it, which causes it to reconfigure those interfaces. You would normally pause the client prior to going into hibernation or sleep on a laptop computer. You would then resume it after the power comes back. This allows PC cards to be shut down while the computer is hibernating or sleeping, and then reinitialized to their previous state once the computer comes out of hibernation or sleep.

The control object has one attribute - the state attribute. To shut the client down, set its state attribute to 2. It will automatically do a DHCPRELEASE. To pause it, set its state attribute to 3. To resume it, set its state attribute to 4.

## ENVIRONMENT VARIABLES
The following environment variables may be defined to override the builtin defaults for file locations. Note that use of the related command-line options will ignore the corresponding environment variable settings.

PATH_DHCLIENT_CONF

The dhclient.conf configuration file.

PATH_DHCLIENT_DB

The dhclient.leases database.

PATH_DHCLIENT_PID

The dhclient PID file.

PATH_DHCLIENT_SCRIPT

The dhclient-script file.

## FILES
CLIENTBINDIR/dhclient-script, ETCDIR/dhcp/dhclient.conf, /var/lib/dhcp/dhclient/state/dhclient.leases, RUNDIR/dhclient.pid, /var/lib/dhcp/dhclient/state/dhclient.leases~.

## SEE ALSO
dhcpd(8), dhcrelay(8), dhclient-script(8), dhclient.conf(5), dhclient.leases(5), dhcp-eval(5).

## AUTHOR
dhclient(8) To learn more about Internet Systems Consortium, see https://www.isc.org

This client was substantially modified and enhanced by Elliot Poger for use on Linux while he was working on the MosquitoNet project at Stanford.

The current version owes much to Elliot's Linux enhancements, but was substantially reorganized and partially rewritten by Ted Lemon so as to use the same networking framework that the Internet Systems Consortium DHCP server uses. Much system-specific configuration code was moved into a shell script so that as support for more operating systems is added, it will not be necessary to port and maintain system-specific configuration code to these operating systems - instead, the shell script can invoke the native tools to accomplish the same purpose.


dhclient-script

title: dhclient-script(8)

text:
# dhclient-script(8)

## NAME
dhclient-script - DHCP client network configuration script

## DESCRIPTION
The DHCP client network configuration script is invoked from time to time by dhclient(8). This script is used by the dhcp client to set each interface's initial configuration prior to requesting an address, to test the address once it has been offered, and to set the interface's final configuration once a lease has been acquired. If no lease is acquired, the script is used to test predefined leases, if any, and also called once if no valid lease can be identified.

This script is not meant to be customized by the end user. If local customizations are needed, they should be possible using the enter and exit hooks provided (see HOOKS for details).

No standard client script exists for some operating systems, even though the actual client may work, so a pioneering user may well need to create a new script or modify an existing one. In general, customizations specific to a particular computer should be done in the ETCDIR/dhcp/dhclient.conf file. If you find that you can't make such a customization without customizing ETCDIR/dhcp/dhclient.conf or using the enter and exit hooks, please submit a bug report.

## HOOKS
The dhclient-script is used to run any system and user defined hook scripts.

System hook scripts are found in /etc/dhcp/dhclient-hooks.d/ and the user defined hooks are /etc/dhcp/dhclient-enter-hooks and /etc/dhcp/dhclient-exit-hooks. You can disable some hooks in the /etc/sysconfig/dhclient config file using SKIP_HOOKS option.

## OPERATION
When dhclient needs to invoke the client configuration script, it defines a set of variables in the environment, and then invokes CLIENTBINDIR/dhclient-script. In all cases, $reason is set to the name of the reason why the script has been invoked. The following reasons are currently defined: MEDIUM, PREINIT, BOUND, RENEW, REBIND, REBOOT, EXPIRE, FAIL, STOP, RELEASE, NBI and TIMEOUT.

## MEDIUM
The DHCP client is requesting that an interface's media type be set. The interface name is passed in $interface, and the media type is passed in $medium.

## PREINIT
The DHCP client is requesting that an interface be configured as required in order to send packets prior to receiving an actual address. For clients which use the BSD socket library, this means configuring the interface with an IP address of 0.0.0.0 and a broadcast address of 255.255.255.255. For other clients, it may be possible to simply configure the interface up without actually giving it an IP address at all. The interface name is passed in $interface, and the media type in $medium.

If an IP alias has been declared in dhclient.conf, its address will be passed in $alias_ip_address, and that ip alias should be deleted from the interface, along with any routes to it.

## BOUND
The DHCP client has done an initial binding to a new address. The new ip address is passed in $new_ip_address, and the interface name is passed in $interface. The media type is passed in $medium. Any options acquired from the server are passed using the option name described in dhcp-options, except that dashes (´-´) are replaced by underscores (´_´) in order to make valid shell variables, and the variable names start with new_. So for example, the new subnet mask would be passed in $new_subnet_mask. Options from a non-default universe will have the universe name prepended to the option name, for example $new_dhcp6_server_id. The options that the client explicitly requested via a PRL or ORO option are passed with the same option name as above but prepended with requested_ and with a value of 1, for example requested_subnet_mask=1. No such variable is defined for options not requested by the client or options that don't require a request option, such as the ip address (*_ip_address) or expiration time (*_expiry).

Before actually configuring the address, dhclient-script should somehow ARP for it and exit with a nonzero status if it receives a reply. In this case, the client will send a DHCPDECLINE message to the server and acquire a different address. This may also be done in the RENEW, REBIND, or REBOOT states, but is not required, and indeed may not be desirable.

When a binding has been completed, a lot of network parameters are likely to need to be set up. A new /etc/resolv.conf needs to be created, using the values of $new_domain_name and $new_domain_name_servers (which may list more than one server, separated by spaces). A default route should be set using $new_routers, and static routes may need to be set up using $new_static_routes.

If an IP alias has been declared, it must be set up here. The alias IP address will be written as $alias_ip_address, and other DHCP options that are set for the alias (e.g., subnet mask) will be passed in variables named as described previously except starting with $alias_ instead of $new_. Care should be taken that the alias IP address not be used if it is identical to the bound IP address ($new_ip_address), since the other alias parameters may be incorrect in this case.

## RENEW
When a binding has been renewed, the script is called as in BOUND, except that in addition to all the variables starting with $new_, and $requested_ there is another set of variables starting with $old_. Persistent settings that may have changed need to be deleted - for example, if a local route to the bound address is being configured, the old local route should be deleted. If the default route has changed, the old default route should be deleted. If the static routes have changed, the old ones should be deleted. Otherwise, processing can be done as with BOUND.

## REBIND
The DHCP client has rebound to a new DHCP server. This can be handled as with RENEW, except that if the IP address has changed, the ARP table should be cleared.

## REBOOT
The DHCP client has successfully reacquired its old address after a reboot. This can be processed as with BOUND.

## EXPIRE
The DHCP client has failed to renew its lease or acquire a new one, and the lease has expired. The IP address must be relinquished, and all related parameters should be deleted, as in RENEW and REBIND.

## FAIL
The DHCP client has been unable to contact any DHCP servers, and any leases that have been tested have not proved to be valid. The parameters from the last lease tested should be deconfigured. This can be handled in the same way as EXPIRE.

## STOP
The dhclient has been informed to shut down gracefully, the dhclient-script should unconfigure or shutdown the interface as appropriate.

## RELEASE
The dhclient has been executed using the -r flag, indicating that the administrator wishes it to release its lease(s). dhclient-script should unconfigure or shutdown the interface.

## NBI
No-Broadcast-Interfaces...dhclient was unable to find any interfaces upon which it believed it should commence DHCP. What dhclient-script should do in this situation is entirely up to the implementor.

## TIMEOUT
The DHCP client has been unable to contact any DHCP servers. However, an old lease has been identified, and its parameters have been passed in as with BOUND. The client configuration script should test these parameters and, if it has reason to believe they are valid, should exit with a value of zero. If not, it should exit with a nonzero value.

## V6ONLY
The DHCPv4 client has received a requested valid v6-only-preferred option. The system should disable IPv4 on the interface. On its side the dhclient waits for V6ONLY_WAIT seconds (the timer is carried by the option with a minimum of MIN_V6ONLY_WAIT) before returning in the INIT state.

The usual way to test a lease is to set up the network as with REBIND (since this may be called to test more than one lease) and then ping the first router defined in $routers. If a response is received, the lease must be valid for the network to which the interface is currently connected. It would be more complete to try to ping all of the routers listed in $new_routers, as well as those listed in $new_static_routes, but current scripts do not do this.

## FILES
Each operating system should generally have its own script file, although the script files for similar operating systems may be similar or even identical. The script files included in Internet Systems Consortium DHCP distribution appear in the distribution tree under client/scripts, and bear the names of the operating systems on which they are intended to work.

## BUGS
If more than one interface is being used, there's no obvious way to avoid clashes between server-supplied configuration parameters - for example, the stock dhclient-script rewrites /etc/resolv.conf. If more than one interface is being configured, /etc/resolv.conf will be repeatedly initialized to the values provided by one server, and then the other. Assuming the information provided by both servers is valid, this shouldn't cause any real problems, but it could be confusing.

## SEE ALSO
dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and dhclient.leases(5).

## AUTHOR
dhclient-script(8) To learn more about Internet Systems Consortium, see https://www.isc.org.


dhcrelay

package: dhcp-relay

title: dhcrelay(8)

text:
# dhcrelay(8)

## NAME
dhcrelay - Dynamic Host Configuration Protocol Relay Agent

## SYNOPSIS
dhcrelay [ -4 ] [ -dqaD ] [ -p port | -rp relay-port ] [ -c count ] [ -A length ] [ -pf pid-file ] [ --no-pid ] [ -m append | replace | forward | discard ] [ -i interface0 [ ... -i interfaceN ] ] [ -iu interface0 [ ... -iu interfaceN ] ] [ -id interface0 [ ... -id interfaceN ] ] [ -U interface -Un user ] [ -j chroot-dir ] [ -g ipaddr ] server0 [ ...serverN ]

dhcrelay -6 [ -dqI ] [ -p port | -rp relay-port ] [ -c count ] [ -pf pid-file ] [ --no-pid ] [ -s subscriber-id ] -l lower0 [ ... -l lowerN ] -u upper0 [ ... -u upperN ]

## DESCRIPTION
The Internet Systems Consortium DHCP Relay Agent, dhcrelay, provides a means for relaying DHCP and BOOTP requests from a subnet to which no DHCP server is directly connected to one or more DHCP servers on other subnets. It supports both DHCPv4/BOOTP and DHCPv6 protocols.

## OPERATION
The DHCP Relay Agent listens for DHCPv4 or DHCPv6 queries from clients or other relay agents on one or more interfaces, passing them along to ``upstream'' servers or relay agents as specified on the command line. When a reply is received from upstream, it is multicast or unicast back downstream to the source of the original request.

Upon startup, this version of dhcrelay will switch to a non-root pseudo-user and enter a chroot jail. The default username (dhcrelay) and the default chroot jail directory path (/var/empty) may be overridden with the -U and -j options, respectively.

## COMMAND LINE
Protocol selection options:

-6

Run dhcrelay as a DHCPv6 relay agent. Incompatible with the -4 option.

-4

Run dhcrelay as a DHCPv4/BOOTP relay agent. This is the default mode of operation, so the argument is not necessary, but may be specified for clarity. Incompatible with -6.

Specifying DHCPv4/BOOTP servers

In DHCPv4 mode, a list of one or more server addresses must be specified on the command line, to which DHCP/BOOTP queries should be relayed.

Options available for both DHCPv4 and DHCPv6:

-c count

Maximum hop count. When forwarding packets, dhcrelay discards packets which have reached a hop count of COUNT. Default is 10. Maximum is 255.

-d

Force dhcrelay to run as a foreground process. Useful when running dhcrelay under a debugger, or running out of inittab on System V systems.

-p port

Listen and transmit on port PORT. This is mostly useful for debugging purposes. Default is port 67 for DHCPv4/BOOTP, or port 547 for DHCPv6. Incompatible with -rp.

-rp relay-port

Alternative source port for upstream (i.e toward the server) messages with DHCPv4 RAI relay-port sub-option or DHCPv6 relay-source-port option. Relay port support is only available if the code was compiled with (./configure --enable-relay-port) and requires LPF or BPF link layer access.

-q

Quiet mode. Prevents dhcrelay6 from printing its network configuration on startup.

-pf pid-file

Path to alternate pid file.

--no-pid

Option to disable writing pid files. By default the program will write a pid file.

Options available in DHCPv4 mode only:

-a

Append an agent option field to each request before forwarding it to the server. Agent option fields in responses sent from servers to clients will be stripped before forwarding such responses back to the client. The agent option field will contain two agent options: the Circuit ID suboption and the Remote ID suboption. Currently, the Circuit ID will be the printable name of the interface on which the client request was received. The client supports inclusion of a Remote ID suboption as well, but this is not used by default.

-A length

Specify the maximum packet size to send to a DHCPv4/BOOTP server. This might be done to allow sufficient space for addition of relay agent options while still fitting into the Ethernet MTU size.

-D

Drop packets from upstream servers if they contain Relay Agent Information options that indicate they were generated in response to a query that came via a different relay agent. If this option is not specified, such packets will be relayed anyway.

-g ipaddr

When a package gets sent back to the client, replace the gateway's IP address (giaddr) with the given ipaddr. This can be used as a workaround for bogus clients like Solaris 11 grub, which use the giaddr instead of the announced router (3) to setup its default route.

-i ifname

Listen for DHCPv4/BOOTP traffic on interface ifname. Multiple interfaces may be specified by using more than one -i option. If no interfaces are specified on the command line, dhcrelay will identify all network interfaces, eliminating non-broadcast interfaces if possible, and attempt to listen on all of them.

-iu ifname

Specifies an upstream network interface: an interface from which replies from servers and other relay agents will be accepted. Multiple interfaces may be specified by using more than one -iu option. This argument is

intended to be used in conjunction with one or more -i or -id arguments.

-id ifname

Specifies a downstream network interface: an interface from which requests from clients and other relay agents will be accepted. Multiple interfaces may be specified by using more than one -id option. This argument is intended to be used in conjunction with one or more -i or -iu arguments.

-m append|replace|forward|discard

Control the handling of incoming DHCPv4 packets which already contain relay agent options. If such a packet does not have giaddr set in its header, the DHCP standard requires that the packet be discarded. However, if giaddr is set, the relay agent may handle the situation in four ways: It may append its own set of relay options to the packet, leaving the supplied option field intact; it may replace the existing agent option field; it may forward the packet unchanged; or, it may discard it.

-U ifname

Enables the addition of a RFC 3527 compliant link selection suboption for clients directly connected to the relay. This RFC allows a relay to specify two different IP addresses: one for the server to use when communicating with the relay (giaddr) the other for choosing the subnet for the client (the suboption). This can be useful if the server is unable to send packets to the relay via the address used for the subnet. When enabled, dhcrelay will add an agent option (as per -a above) that includes the link selection suboption to the forwarded packet. This will only be done to packets received from clients that are directly connected to the relay (i.e. giaddr is zero). The address used in the suboption will be that of the link upon which the inbound packet was received (which would otherwise be used for giaddr). The value of giaddr will be set to that of interface ifname.

Only one interface should be marked in this fashion. Currently enabling this option on an interface causes the relay to process all DHCP traffic similar to the -i option, in the future we may split the two more completely.

This option is off by default. Note that enabling this option automatically enables the -a option.

Keep in mind that using options such as -m replace or -m discard on relays upstream from one using -U can pose problems. The upstream relay will wipe out the initial agent option containing the link selection while leaving the re-purposed giaddr value in place, causing packets to go astray.

Options available in DHCPv6 mode only:

-I

Force use of the DHCPv6 Interface-ID option. This option is automatically sent when there are two or more downstream interfaces in use, to disambiguate between them. The -I option causes dhcrelay to send the option even if there is only one downstream interface.

-s subscriber-id

Add an option with the specified subscriber-id into the packet. This feature is for testing rather than production as it will put the same subscriber-id into the packet for all clients.

-l [address%]ifname[#index]

Specifies the ``lower'' network interface for DHCPv6 relay mode: the interface on which queries will be received from clients or from other relay agents. At least one -l option must be included in the command line when running in DHCPv6 mode. The interface name ifname is a mandatory parameter. The link address can be specified by address%; if it isn't, dhcrelay will use the first non-link-local address configured on the interface. The optional #index parameter specifies the interface index.

-u [address%]ifname

Specifies the ``upper'' network interface for DHCPv6 relay mode: the interface to which queries from clients and other relay agents should be forwarded. At least one -u option must be included in the command line when running in DHCPv6 mode. The interface name ifname is a mandatory parameter. The destination unicast or multicast address can be specified by address%; if not specified, the relay agent will forward to the DHCPv6 All_DHCP_Relay_Agents_and_Servers multicast address.

It is possible to specify the same interface with different addresses more than once, and even, when the system supports it, to use the same interface as both upper and lower interfaces.

## SEE ALSO
dhclient(8), dhcpd(8), RFC3315, RFC2132, RFC2131.

## BUGS
Using the same interface on both upper and lower sides may cause loops, so when running this way, the maximum hop count should be set to a low value.

The loopback interface is not (yet) recognized as a valid interface.

## AUTHOR
dhcrelay(8) To learn more about Internet Systems Consortium, see https://www.isc.org.

This version of dhcrelay has been modified for ALT Linux (http://www.altlinux.com/). In particular, the privilege reduction functionality and the -u and -j options are Openwall/ALT Linux extensions.


dhcpd

package: dhcp-server

title: dhcpd(8)

text:
# dhcpd(8)

## NAME
dhcpd - Dynamic Host Configuration Protocol Server

## SYNOPSIS
dhcpd [ -p port ] [ -f ] [ -d ] [ -q ] [ -t | -T ] [ -4 | -6 ] [ -4o6 port ] [ -s server ] [ -cf config-file ] [ -lf lease-file ] [ -pf pid-file ] [ --no-pid ] [ -user user ] [ -group group ] [ -chroot dir ] [ -tf trace-output-file ] [ -play trace-playback-file ] [ -u user ] [ -j chroot-dir ] [ if0 [ ...ifN ] ]

dhcpd --version

## DESCRIPTION
The Internet Systems Consortium DHCP Server, dhcpd, implements the Dynamic Host Configuration Protocol (DHCP) and the Internet Bootstrap Protocol (BOOTP). DHCP allows hosts on a TCP/IP network to request and be assigned IP addresses, and also to discover information about the network to which they are attached. BOOTP provides similar functionality, with certain restrictions.

## OPERATION
The DHCP protocol allows a host which is unknown to the network administrator to be automatically assigned a new IP address out of a pool of IP addresses for its network. In order for this to work, the network administrator allocates address pools in each subnet and enters them into the dhcpd.conf(5) file.

There are two versions of the DHCP protocol DHCPv4 and DHCPv6. At startup the server may be started for one or the other via the -4 or -6 arguments.

On startup, dhcpd reads the dhcpd.conf file and stores a list of available addresses on each subnet in memory. When a client requests an address using the DHCP protocol, dhcpd allocates an address for it. Each client is assigned a lease, which expires after an amount of time chosen by the administrator (by default, one day). Before leases expire, the clients to which leases are assigned are expected to renew them in order to continue to use the addresses. Once a lease has expired, the client to which that lease was assigned is no longer permitted to use the leased IP address.

In order to keep track of leases across system reboots and server restarts, dhcpd keeps a list of leases it has assigned in the dhcpd.leases(5) file. Before dhcpd grants a lease to a host, it records the lease in this file and makes sure that the contents of the file are flushed to disk. This ensures that even in the event of a system crash, dhcpd will not forget about a lease that it has assigned. On startup, after reading the dhcpd.conf file, dhcpd reads the dhcpd.leases file to refresh its memory about what leases have been assigned.

New leases are appended to the end of the dhcpd.leases file. In order to prevent the file from becoming arbitrarily large, from time to time dhcpd creates a new dhcpd.leases file from its in-core lease database. Once this file has been written to disk, the old file is renamed dhcpd.leases~, and the new file is renamed dhcpd.leases. If the system crashes in the middle of this process, whichever dhcpd.leases file remains will contain all the lease information, so there is no need for a special crash recovery process.

BOOTP support is also provided by this server. Unlike DHCP, the BOOTP protocol does not provide a protocol for recovering dynamically-assigned addresses once they are no longer needed. It is still possible to dynamically assign addresses to BOOTP clients, but some administrative process for reclaiming addresses is required. By default, leases are granted to BOOTP clients in perpetuity, although the network administrator may set an earlier cutoff date or a shorter lease length for BOOTP leases if that makes sense.

BOOTP clients may also be served in the old standard way, which is to simply provide a declaration in the dhcpd.conf file for each BOOTP client, permanently assigning an address to each client.

Whenever changes are made to the dhcpd.conf file, dhcpd must be restarted. To restart dhcpd, send a SIGTERM (signal 15) to the process ID contained in RUNDIR/dhcpd.pid, and then re-invoke dhcpd. Because the DHCP server database is not as lightweight as a BOOTP database, dhcpd does not automatically restart itself when it sees a change to the dhcpd.conf file.

Note: We get a lot of complaints about this. We realize that it would be nice if one could send a SIGHUP to the server and have it reload the database. This is not technically impossible, but it would require a great deal of work, our resources are extremely limited, and they can be better spent elsewhere. So please don't complain about this on the mailing list unless you're prepared to fund a project to implement this feature, or prepared to do it yourself.

Upon startup, this version of the DHCP server will switch to a non-root pseudo-user and enter a chroot jail. The default username (dhcpd) and the default chroot jail directory path (/var/lib/dhcp/dhcpd) may be overridden with the -u and -j options, respectively.

## COMMAND LINE
The names of the network interfaces on which dhcpd should listen for broadcasts may be specified on the command line. This should be done on systems where dhcpd is unable to identify non-broadcast interfaces, but should not be required on other systems. If no interface names are specified on the command line dhcpd will identify all network interfaces which are up, eliminating non-broadcast interfaces if possible, and listen for DHCP broadcasts on each interface.

## COMMAND LINE OPTIONS
-4

Run as a DHCP server. This is the default and cannot be combined with -6.

-6

Run as a DHCPv6 server. This cannot be combined with -4.

-4o6 port

Participate in the DHCPv4 over DHCPv6 protocol specified by RFC 7341. This associates a DHCPv4 and a DHCPv6 server to allow the v4 server to receive v4 requests that were encapsulated in a v6 packet. Communication between the two servers is done on a pair of UDP sockets bound to ::1 port and port + 1. Both servers must be launched using the same port argument.

-p port

The UDP port number on which dhcpd should listen. If unspecified dhcpd uses the default port of 67. This is mostly useful for debugging purposes.

-s address

Specify an address or host name to which dhcpd should send replies rather than the broadcast address (255.255.255.255). This option is only supported in IPv4.

-f

Force dhcpd to run as a foreground process instead of as a daemon in the background. This is useful when running dhcpd under a debugger, or when running it out of inittab on System V systems.

-d

Send log messages to the standard error descriptor. This can be useful for debugging, and also at sites where a complete log of all dhcp activity must be kept but syslogd is not reliable or otherwise cannot be used. Normally, dhcpd will log all output using the syslog(3) function with the log facility set to LOG_DAEMON. Note that -d implies -f (the daemon will not fork itself into the background).

-q

Be quiet at startup. This suppresses the printing of the entire copyright message during startup. This might be desirable when starting dhcpd from a system startup script (e.g., /etc/rc).

-t

Test the configuration file. The server tests the configuration file for correct syntax, but will not attempt to perform any network operations. This can be used to test a new configuration file automatically before installing it.

-T

Test the lease file. The server tests the lease file for correct syntax, but will not attempt to perform any network operations. In addition to reading the lease file it will also write the leases to a temporary lease file. The current lease file will not be modified and the temporary lease file will be removed upon completion of the test. This can be used to test a new lease file automatically before installing it.

-user user

Setuid to user after completing privileged operations, such as creating sockets that listen on privileged ports. This also causes the lease file to be owned by user. This option is only available if the code was compiled with the PARANOIA patch (./configure --enable-paranoia).

-group group

Setgid to group after completing privileged operations, such as creating sockets that listen on privileged ports. This also causes the lease file to use group. This option is only available if the code was compiled with the PARANOIA patch (./configure --enable-paranoia).

-chroot dir

Chroot to directory. This may occur before or after reading the configuration files depending on whether the code was compiled with the EARLY_CHROOT option enabled (./configure --enable-early-chroot). This option is only available if the code was compiled with the PARANOIA patch (./configure --enable-paranoia).

-tf tracefile

Specify a file into which the entire startup state of the server and all the transactions it processes are logged. This can be useful in submitting bug reports - if you are getting a core dump every so often, you can start the server with the -tf option and then, when the server dumps core, the trace file will contain all the transactions that led up to it dumping core, so that the problem can be easily debugged with -play.

-play playfile

Specify a file from which the entire startup state of the server and all the transactions it processed are read. The -play option must be specified with an alternate lease file, using the -lf switch, so that the DHCP server doesn't wipe out your existing lease file with its test data. The DHCP server will refuse to operate in playback mode unless you specify an alternate lease file.

--version

Print version number and exit.

Modifying default file locations: The following options can be used to modify the locations dhcpd uses for its files. Because of the importance of using the same lease database at all times when running dhcpd in production, these options should be used only for testing lease files or database files in a non-production environment.

-cf config-file

Path to alternate configuration file.

-lf lease-file

Path to alternate lease file.

-pf pid-file

Path to alternate pid file.

--no-pid

Option to disable writing pid files. By default the program will write a pid file. If the program is invoked with this option it will not check for an existing server process.

## PORTS
During operations the server may use multiple UDP and TCP ports to provide different functions. Which ports are opened depends on both the way you compiled your code and the configuration you supply. The following should provide you an idea of what ports may be in use.

Normally a DHCPv4 server will open a raw UDP socket to receive and send most DHCPv4 packets. It also opens a fallback UDP socket for use in sending unicast packets. Normally these will both use the well known port number for BOOTPS.

For each DHCPv4 failover peer you list in the configuration file there will be a TCP socket listening for connections on the ports specified in the configuration file. When the peer connects there will be another socket for the established connection. For the established connection the side (primary or secondary) opening the connection will use a random port.

For DHCPv6 the server opens a UDP socket on the well known dhcpv6-server port.

The server opens an icmp socket for doing ping requests to check if addresses are in use.

If you have included an omapi-port statement in your configuration file then the server will open a TCP socket on that port to listen for OMPAI connections. When something connects another port will be used for the established connection.

When DDNS is enabled at compile time (see includes/site.h) the server will open both a v4 and a v6 UDP socket on random ports, unless DDNS updates are globally disabled by setting ddns-update-style to none in the configuration file.

## CONFIGURATION
The syntax of the dhcpd.conf(5) file is discussed separately. This section should be used as an overview of the configuration process, and the dhcpd.conf(5) documentation should be consulted for detailed reference information.

## Subnets
dhcpd needs to know the subnet numbers and netmasks of all subnets for which it will be providing service. In addition, in order to dynamically allocate addresses, it must be assigned one or more ranges of addresses on each subnet which it can in turn assign to client hosts as they boot. Thus, a very simple configuration providing DHCP support might look like this:

```
	subnet 239.252.197.0 netmask 255.255.255.0 {
	  range 239.252.197.10 239.252.197.250;
	}
```

Multiple address ranges may be specified like this:

```
	subnet 239.252.197.0 netmask 255.255.255.0 {
	  range 239.252.197.10 239.252.197.107;
	  range 239.252.197.113 239.252.197.250;
	}
```

If a subnet will only be provided with BOOTP service and no dynamic address assignment, the range clause can be left out entirely, but the subnet statement must appear.

## Lease Lengths
DHCP leases can be assigned almost any length from zero seconds to infinity. What lease length makes sense for any given subnet, or for any given installation, will vary depending on the kinds of hosts being served.

For example, in an office environment where systems are added from time to time and removed from time to time, but move relatively infrequently, it might make sense to allow lease times of a month or more. In a final test environment on a manufacturing floor, it may make more sense to assign a maximum lease length of 30 minutes - enough time to go through a simple test procedure on a network appliance before packaging it up for delivery.

It is possible to specify two lease lengths: the default length that will be assigned if a client doesn't ask for any particular lease length, and a maximum lease length. These are specified as clauses to the subnet command:

```
	subnet 239.252.197.0 netmask 255.255.255.0 {
	  range 239.252.197.10 239.252.197.107;
	  default-lease-time 600;
	  max-lease-time 7200;
	}
```

This particular subnet declaration specifies a default lease time of 600 seconds (ten minutes), and a maximum lease time of 7200 seconds (two hours). Other common values would be 86400 (one day), 604800 (one week) and 2592000 (30 days).

Each subnet need not have the same lease—in the case of an office environment and a manufacturing environment served by the same DHCP server, it might make sense to have widely disparate values for default and maximum lease times on each subnet.

## BOOTP Support
Each BOOTP client must be explicitly declared in the dhcpd.conf file. A very basic client declaration will specify the client network interface's hardware address and the IP address to assign to that client. If the client needs to be able to load a boot file from the server, that file's name must be specified. A simple bootp client declaration might look like this:

```
	host haagen {
	  hardware ethernet 08:00:2b:4c:59:23;
	  fixed-address 239.252.197.9;
	  filename "/tftpboot/haagen.boot";
	}
```

## Options
DHCP (and also BOOTP with Vendor Extensions) provide a mechanism whereby the server can provide the client with information about how to configure its network interface (e.g., subnet mask), and also how the client can access various network services (e.g., DNS, IP routers, and so on).

These options can be specified on a per-subnet basis, and, for BOOTP clients, also on a per-client basis. In the event that a BOOTP client declaration specifies options that are also specified in its subnet declaration, the options specified in the client declaration take precedence. A reasonably complete DHCP configuration might look something like this:

```
	subnet 239.252.197.0 netmask 255.255.255.0 {
	  range 239.252.197.10 239.252.197.250;
	  default-lease-time 600;
	  max-lease-time 7200;
	  option subnet-mask 255.255.255.0;
	  option broadcast-address 239.252.197.255;
	  option routers 239.252.197.1;
	  option domain-name-servers 239.252.197.2, 239.252.197.3;
	  option domain-name "isc.org";
	}
```

A bootp host on that subnet that needs to be in a different domain and use a different name server might be declared as follows:

```
	host haagen {
	  hardware ethernet 08:00:2b:4c:59:23;
	  fixed-address 239.252.197.9;
	  filename "/tftpboot/haagen.boot";
	  option domain-name-servers 192.5.5.1;
	  option domain-name "example.com";
	}
```

A more complete description of the dhcpd.conf file syntax is provided in dhcpd.conf(5).

## OMAPI
The DHCP server provides the capability to modify some of its configuration while it is running, without stopping it, modifying its database files, and restarting it. This capability is currently provided using OMAPI - an API for manipulating remote objects. OMAPI clients connect to the server using TCP/IP, authenticate, and can then examine the server's current status and make changes to it.

Rather than implementing the underlying OMAPI protocol directly, user programs should use the dhcpctl API or OMAPI itself. Dhcpctl is a wrapper that handles some of the housekeeping chores that OMAPI does not do automatically. Dhcpctl and OMAPI are documented in dhcpctl(3) and omapi(3).

OMAPI exports objects, which can then be examined and modified. The DHCP server exports the following objects: lease, host, failover-state and group. Each object has a number of methods that are provided: lookup, create, and destroy. In addition, it is possible to look at attributes that are stored on objects, and in some cases to modify those attributes.

## THE LEASE OBJECT
Leases can't currently be created or destroyed, but they can be looked up to examine and modify their state.

Leases have the following attributes:

state integer lookup, examine

```
1 = free
2 = active
3 = expired
4 = released
5 = abandoned
6 = reset
7 = backup
8 = reserved
9 = bootp
```

ip-address data lookup, examine

The IP address of the lease.

dhcp-client-identifier data lookup, examine, update

The client identifier that the client used when it acquired the lease. Not all clients send client identifiers, so this may be empty.

client-hostname data examine, update

The value the client sent in the host-name option.

host handle examine

the host declaration associated with this lease, if any.

subnet handle examine

the subnet object associated with this lease (the subnet object is not currently supported).

pool handle examine

the pool object associated with this lease (the pool object is not currently supported).

billing-class handle examine

the handle to the class to which this lease is currently billed, if any (the class object is not currently supported).

hardware-address data examine, update

the hardware address (chaddr) field sent by the client when it acquired its lease.

hardware-type integer examine, update

the type of the network interface that the client reported when it acquired its lease.

ends time examine

the time when the lease's current state ends, as understood by the client.

tstp time examine

the time when the lease's current state ends, as understood by the server.

tsfp time examine the adjusted time when the lease's current state ends, as understood by the failover peer (if there is no failover peer, this value is undefined). Generally this value is only adjusted for expired, released, or reset leases while the server is operating in partner-down state, and otherwise is simply the value supplied by the peer.

atsfp time examine the actual tsfp value sent from the peer. This value is forgotten when a lease binding state change is made, to facilitate retransmission logic.

cltt time examine

The time of the last transaction with the client on this lease.

## THE HOST OBJECT
Hosts can be created, destroyed, looked up, examined and modified. If a host declaration is created or deleted using OMAPI, that information will be recorded in the dhcpd.leases file. It is permissible to delete host declarations that are declared in the dhcpd.conf file.

Hosts have the following attributes:

name data lookup, examine, modify

the name of the host declaration. This name must be unique among all host declarations.

group handle examine, modify

the named group associated with the host declaration, if there is one.

hardware-address data lookup, examine, modify

the link-layer address that will be used to match the client, if any. Only valid if hardware-type is also present.

hardware-type integer lookup, examine, modify

the type of the network interface that will be used to match the client, if any. Only valid if hardware-address is also present.

dhcp-client-identifier data lookup, examine, modify

the dhcp-client-identifier option that will be used to match the client, if any.

ip-address data examine, modify

a fixed IP address which is reserved for a DHCP client that matches this host declaration. The IP address will only be assigned to the client if it is valid for the network segment to which the client is connected.

statements data modify

a list of statements in the format of the dhcpd.conf file that will be executed whenever a message from the client is being processed.

known integer examine, modify

if nonzero, indicates that a client matching this host declaration will be treated as known in pool permit lists. If zero, the client will not be treated as known.

## THE GROUP OBJECT
Named groups can be created, destroyed, looked up, examined and modified. If a group declaration is created or deleted using OMAPI, that information will be recorded in the dhcpd.leases file. It is permissible to delete group declarations that are declared in the dhcpd.conf file.

Named groups currently can only be associated with hosts - this allows one set of statements to be efficiently attached to more than one host declaration.

Groups have the following attributes:

name data

the name of the group. All groups that are created using OMAPI must have names, and the names must be unique among all groups.

statements data

a list of statements in the format of the dhcpd.conf file that will be executed whenever a message from a client whose host declaration references this group is processed.

## THE CONTROL OBJECT
The control object allows you to shut the server down. If the server is doing failover with another peer, it will make a clean transition into the shutdown state and notify its peer, so that the peer can go into partner down, and then record the "recover" state in the lease file so that when the server is restarted, it will automatically resynchronize with its peer.

On shutdown the server will also attempt to cleanly shut down all OMAPI connections. If these connections do not go down cleanly after five seconds, they are shut down preemptively. It can take as much as 25 seconds from the beginning of the shutdown process to the time that the server actually exits.

To shut the server down, open its control object and set the state attribute to 2.

## THE FAILOVER-STATE OBJECT
The failover-state object is the object that tracks the state of the failover protocol as it is being managed for a given failover peer. The failover object has the following attributes (please see dhcpd.conf (5) for explanations about what these attributes mean):

name data examine

Indicates the name of the failover peer relationship, as described in the server's dhcpd.conf file.

partner-address data examine

Indicates the failover partner's IP address.

local-address data examine

Indicates the IP address that is being used by the DHCP server for this failover pair.

partner-port data examine

Indicates the TCP port on which the failover partner is listening for failover protocol connections.

local-port data examine

Indicates the TCP port on which the DHCP server is listening for failover protocol connections for this failover pair.

max-outstanding-updates integer examine

Indicates the number of updates that can be outstanding and unacknowledged at any given time, in this failover relationship.

mclt integer examine

Indicates the maximum client lead time in this failover relationship.

load-balance-max-secs integer examine

Indicates the maximum value for the secs field in a client request before load balancing is bypassed.

load-balance-hba data examine

Indicates the load balancing hash bucket array for this failover relationship.

local-state integer examine, modify

Indicates the present state of the DHCP server in this failover relationship. Possible values for state are:

```
1   - startup
2   - normal
3   - communications interrupted
4   - partner down
5   - potential conflict
6   - recover
7   - paused
8   - shutdown
9   - recover done
10  - resolution interrupted
11  - conflict done
254 - recover wait
```

(Note that some of the above values have changed since DHCP 3.0.x.)

In general it is not a good idea to make changes to this state. However, in the case that the failover partner is known to be down, it can be useful to set the DHCP server's failover state to partner down. At this point the DHCP server will take over service of the failover partner's leases as soon as possible, and will give out normal leases, not leases that are restricted by MCLT. If you do put the DHCP server into the partner-down when the other DHCP server is not in the partner-down state, but is not reachable, IP address assignment conflicts are possible, even likely. Once a server has been put into partner-down mode, its failover partner must not be brought back online until communication is possible between the two servers.

partner-state integer examine

Indicates the present state of the failover partner.

local-stos integer examine

Indicates the time at which the DHCP server entered its present state in this failover relationship.

partner-stos integer examine

Indicates the time at which the failover partner entered its present state.

hierarchy integer examine

Indicates whether the DHCP server is primary (0) or secondary (1) in this failover relationship.

last-packet-sent integer examine

Indicates the time at which the most recent failover packet was sent by this DHCP server to its failover partner.

last-timestamp-received integer examine

Indicates the timestamp that was on the failover message most recently received from the failover partner.

skew integer examine

Indicates the skew between the failover partner's clock and this DHCP server's clock

max-response-delay integer examine

Indicates the time in seconds after which, if no message is received from the failover partner, the partner is assumed to be out of communication.

cur-unacked-updates integer examine

Indicates the number of update messages that have been received from the failover partner but not yet processed.

## FILES
ETCDIR/dhcp/dhcpd.conf, /var/lib/dhcp/dhcpd/state/dhcpd.leases, RUNDIR/dhcpd.pid, /var/lib/dhcp/dhcpd/state/dhcpd.leases~.

## SEE ALSO
dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5)

## AUTHOR
dhcpd(8) was originally written by Ted Lemon under a contract with Vixie Labs. Funding for this project was provided by Internet Systems Consortium. Version 3 of the DHCP server was funded by Nominum, Inc. Information about Internet Systems Consortium is available at https://www.isc.org/.

This version of dhcpd has been modified for ALT Linux (http://www.altlinux.com/). In particular, the privilege reduction functionality and the -u and -j options are Openwall/ALT Linux extensions.


title: dhcp_probe(8)

text:
# dhcp_probe(8)

## NAME
dhcp_probe - locate DCHP and BootP servers on a directly-attached network

## SYNOPSIS
dhcp_probe [ -c config_file ] [ -d debuglevel ] [ -f ] [ -h ] [ -l log_file ] [ -o capture_file ] [ -p pid_file ] [ -Q vlan_id ] [ -s capture_bufsize ] [ -T ] [ -v ] [ -w cwd ] interface_name

## DESCRIPTION
dhcp_probe attempts to discover DHCP and BootP servers on a directly-attached Ethernet network. A network administrator can use this tool to locate unauthorized DHCP and BootP servers.

The program must be run with root privilege.

The program periodically broadcasts a number of DHCP and BootP request packets out a single physical interface. Several different kinds of request packets are sent, as a DHCP or BootP server may only respond to certain requests, depending on the server's configuration. Essentially, dhcp_probe mimics a BootP or DHCP client in a variety of possible states, attempting to provoke responses from servers.

After sending each request packet, dhcp_probe listens for responses. After filtering out responses that do not appear to be in response to the probe, and responses from known DHCP and BootP servers (identified by their IP source addresses and optionally by their Ethernet source addresses), it logs any responses from unknown servers.

Optionally, responses from unknown servers may also be written to a packet capture file.

Optionally, an external program may be called each time a response from an unknown server is received.

dhcp_probe may not be able to locate all DHCP and BootP servers; see LIMITATIONS below.

As DHCP broadcasts do not ordinarily cross IP routers, dhcp_probe will locate only servers that are attached to the same physical network as the interface specified on the command line. Although BootP Relay Agents running on this network may help the broadcasts cross IP routers, these agents typically are configured to convert the broadcasts to unicasts directed to only the well-known DHCP or BootP servers located on other physical networks. As a result, BootP Relay Agents will allow your the servers to receive the requests issued by dhcp_probe, but will not cause remote unknown servers to hear these requests. Therefore, if you have multiple physical networks, you may wish to run dhcp_probe on each of these networks to discover unknown DHCP and BootP servers on each of them.

dhcp_probe functions on a single Ethernet interface specified on the command line; it does not listen on multiple interfaces. However, if the host has multiple physical interfaces, you may run an instance of dhcp_probe on each interface. If your physical interface supports 802.1Q, you can use that to create a logical interface on each VLAN, then run an instance of dhcp_probe on each logical interface.

dhcp_probe is intended for use by a network administrator. Before running dhcp_probe on any network other than one for which you are responsible, contact that network's administrator to learn if it is acceptable for you to run this software on that network. Running this software may violate on a network where you don't have permission to do so may violate that network's acceptable use policy.

## AVAILABILITY
dhcp_probe is a product of the Network Systems Group at Princeton University's Office of Information Technology, and is available from http://www.net.princeton.edu/software/dhcp_probe/

Presently the product builds and runs on Solaris 9 on SPARC with gcc. The program relies on the pcap(3) and libnet(3) libraries.

## OPTIONS
-c config_file

Specifies the configuration file. If not specified, this defaults to /etc/dhcp_probe.cf. The configuration file is read at startup, and is re-read whenever a SIGHUP is received. See dhcp_probe.cf(5).

-d debuglevel

Sets the debuglevel variable that controls the amount of debugging messages generated. If not specified, this defaults to 0 (no debugging). For a summary of the types of messages produced at each debug level, see DEBUG LEVELS below.

-f

Specifies that the program should not fork, but instead remain in the foreground. Only use this when you are starting the program manually for testing purposes. When in the foreground, any messages produced by the program are written to stderr instead of to syslog(3) or any log_file you might specify with the -l option.

-h

Display a brief usage summary, then exit.

-l log_file

Log messages to the specified file instead of to syslog(3). (This option is ignored if you also specify the -f option, as that directs messages to stderr.) The log file is opened shortly after the program starts. It is closed and re-opened when the program receives a SIGUSR1 signal.

-o capture_file

When a response packet is received from an unexpected server, write the packet to the specified file. The file is opened and truncated shortly after the program starts. It is closed and re-opened (and truncated) when the program receives a SIGUSR2 signal. The file is a pcap(3) savefile, and may be read with any program that understands the pcap savefile format; e.g. tcpdump(1).

-p pid_file

Specifies the file that will contain the program's processid. If not specified, this defaults to /var/run/dhcp_probe.pid. The pid_file is written shortly after the program starts, and is removed when the program exits under its own control.

-Q vlan_id

Specifies that the packets we send should be tagged with an 802.1Q VLAN ID vlan_id. Valid values range from 0 to 4095. If not specified, the packets we send do not contain an 802.1Q header.

-s capture_bufsize

Specifies the size of the buffer that will be used to capture all the responses (Ethernet frames) to a single request packet; responses which do not fit are silently dropped. The value is specified in bytes, and must fit into your host's range for an int; values outside that range may result in unpredictable results. If not specified, this defaults to 30280, which is enough for twenty maximum-size Ethernet frames (1514*20). Typical responses are Ethernet frames ranging from 342-590 bytes, so the default capture buffer size should hold over 50 of them.

-T

Enables the 'socket receive timeout' feature. On some platforms, dhcp_probe may ignore the response_wait_time (described in dhcp_probe.cf(5)), instead waiting forever for a response after it sends a probe packet. As per pcap(3), this is because the read timeout we pass to pcap_open_live() is not supported on all platforms. If you encounter this issue, try enabling our 'socket receive timeout' feature; it might help. Enabling this feature causes the program to also set a socket receive timeout on the socket underlying the pcap capture; we set this timeout to the response_wait_time. On some platforms, the program's socket receive timeout feature does not work; instead the program will report that it cannot set the receive timeout, and will exit.

-v

Display the program's version number, then exit.

-w cwd

Specifies the working directory; shortly after starting the program changes its current working directory to this. If not specified, this defaults to /.

interface_name

Specifies the name of the interface the program should use; this argument is required. This must be an Ethernet interface which is up and has been assigned an IP address.

## OPERATION
After initialization, the program enters its main event loop, in which it remains until you signal the program to exit with a SIGINT, SIGTERM, or SIGQUIT.

The main event loop (a.k.a. the "probe cycle") consists of the following actions, repeated until the program receives a request to quit:

1.

Handle any signals that have been received.

2.

Install a pcap(3) filter to listen for UDP packets destined to the BootP client port (UDP port 68).

3.

Broadcast a DHCP or BootP request packet out the specified interface.

4.

Listen for response_wait_time milliseconds for any responses received by the pcap(3) filter. (The response_wait_time defaults to 5000 milliseconds (5 seconds), and may be changed in the dhcp_probe.cf(5) file.) Any responses that contains a bootp_chaddr field not equal to the chaddr used in the probe is ignored, as are any that have incorrect bootp_htype or bootp_hlen fields. These are not responses to our probe.

Any responses from known DHCP and BootP servers are ignored. The IP source address for responses from each known server is declared using a legal_server statement in the dhcp_probe.cf(5) file. Any response with an IP source address that does not appear in a legal_server statement is treated as an unknown server.

The Ethernet source address for responses from each known server is also optionaly declared using a legal_server_ethersrc statement in the dhcp_probe.cf(5) file. If at least one legal_server_ethersrc is specified, then any response with an Ethernet source address that does not appear in a legal_server_ethersrc statement is treated as an unknown server. If no legal_server_ethersrc statements appear, then the response's Ethernet source address is not checked. (The legal_server_ethersrc statement is considered experimental in version 1.3.0, as it has received only limited testing.)

For each response from an unknown server:

a)

If the reponse packet contains a non-zero yiaddr field, and one or more lease_network_of_concern statements were specified, determine if the yiaddr value falls within any of the "Lease Networks of Concern".

a)

Log a message showing the response packet's source IP and Ethernet addresses. If the response packet's yiaddr is non-zero and falls within a "Lease Networks of Concern", the log message also reports that.

b)

If the -o option was specified, the packet is also written to a packet capture file.

c)

If an alert_program_name was specified in the dhcp_probe.cf(5) file, that program is executed, with the following arguments in order: the name of the calling program (e.g. dhcp_probe), the name of the interface on which the unexpected response packet was received, the IP source address of the packet, and the Ethernet source address of the packet. (We do not wait for the alert_program_name to complete; it runs in a child process.)

d)

If an alert_program_name2 was specified in the dhcp_probe.cf(5) file, that program is executed, with the following required options:

```
   -p the name of the calling program (e.g. dhcp_probe)

   -I the name of the interface on which the unexpected response packet was received

   -i the IP source address of the packet

   -m and the Ethernet source address of the packet
```

If the response packet's yiaddr is non-zero and falls within a "Lease Networks of Concern", the following optional options are also passed:

```
   -y the non-zero yiaddr value
```

(We do not wait for the alert_program_name2 to complete; it runs in a child process.)

5.

Remove the pcap(3) filter installed earlier.

6.

If any signals have arrived requesting that we quit, exit gracefully.

7.

Repeat steps 2-6 for each flavor of DHCP and BootP request packet the program supports (see PACKET FLAVORS below).

8.

Handle any signals that have been received.

9.

Sleep for cycle_time seconds. (The cycle_time defaults to 300 seconds, and and may be changed in the dhcp_probe.cf(5) file.)

The pcap(3) filter the program installs normally does not specify that the interface should be placed into promiscuous mode (although it is possible the interface is already in promiscuous mode for some other reason). However, if in the dhcp_probe.cf(5) file you specify a chaddr or ether_src value other than the interface's actual hardware address, then the pcap filter will specify that the interface should be placed into promiscuous mode.

Although the filter used with pcap(3) specifies only UDP packets destined to port bootpc should be collected, on systems where bpf isn't part of the kernel, pcap(3) must implement bpf as part of the application. This can increase the number of packets that must be passed from the kernel to user space to be filtered. The program attempts to minimize the side-effects of this by removing the pcap(3) filter when it isn't actually listening for responses. In particular, the filter is not installed during the time the program sleeps between each probe cycle (the cycle_time).

If you do specify an alert_program_name, take care that the program you specify is safe for a privileged user to run; it is executed with the same (i.e. root) privileges as the calling program.

## PACKET FLAVORS
No single request packet is likely to provoke a response from every possible BootP and DHCP server. Some servers may only response to either BootP, or DHCP, but not both. Some servers may be configured to only respond to a small set of known clients. Some DHCP servers will only provide leases to a small set of known clients, but may be willing to respond (negatively) to unknown clients that request a lease renewal on an inappropriate IP address. Therefore, dhcp_probe actually sends not one, but five different flavor request packets, in the hopes of provoking responses from a wider variety of unknown servers.

The packet flavors are:

BOOTPREQUEST

This packet is typical of a BootP client requesting an IP address. It will typically provoke a BOOTPREPLY from a BootP server willing to respond to any BootP client. (BootP servers configured to only respond to a set of known clients may not respond.)

DHCPDISOVER (INIT)

This packet is typical of a DHCP client in the INIT state. The options field contains a DHCP Message Type specifying DHCPDISCOVER.

The options field contains a DHCP Client Identifier, which is computed by prepending 0x'01' to the value of chaddr. (The value chaddr is specified in the dhcp_probe.cf(5) file, otherwise it defaults to the interface's Ethernet address.)

This packet will typically provoke a DHCPOFFER from a DHCP server willing to respond to any DHCP client. (DHCP servers configured to only offer leases to a set of known clients may not respond.)

DHCPREQUEST (SELECTING):

This packet is typical of a DHCP client in the SELECTING state; i.e. a client which has previously issued a DHCPDISCOVER, then received a DHCPOFFER from some DHCP server. The options field contains a DHCP Message Type specifying DHCPREQUEST.

The options field contains a DHCP Client Identifier, which is computed by prepending 0x'01' to the value of chaddr. (The value chaddr is specified in the dhcp_probe.cf(5) file, otherwise it defaults to the interface's Ethernet address.)

The options field contains a DHCP Server Identifier specifying server_id, which should be an IP address that does not correspond to any valid DHCP Server Identifier on your network. (The value server_id is specified in the dhcp_probe.cf(5) file, otherwise it defaults to 10.254.254.254.)

The options field contains a DHCP Requested IP Address specifying client_ip_address, which should be an IP address that does not correspond to any valid IP address on your network. (The value client_ip_address is specified in the dhcp_probe.cf(5) file, otherwise it defaults to 172.31.254.254.)

This packet occassionally provokes a response from a broken DHCP server that fails to respect the DHCP Server Identifier option.

DHCPREQUEST (INIT-REBOOT):

This packet is typical of a DHCP client in the INIT-REBOOT state; i.e. a client which has obtained a DHCP lease in the past, is bringing up its IP stack, and hopes to obtain (or extend) a DHCP lease on the same IP address as in the past. The options field contains a DHCP Message Type specifying DHCPREQUEST.

The options field contains a DHCP Client Identifier, which is computed by prepending 0x'01' to the value of chaddr. (The value chaddr is specified in the dhcp_probe.cf(5) file, otherwise it defaults to the interface's Ethernet address.)

The options field contains a DHCP Requested IP Address specifying client_ip_address, which should be an IP address that does not correspond to any valid IP address on your network; ideally it should be one that is topologically inappropriate for your network. (The value client_ip_address is specified in the dhcp_probe.cf(5) file, otherwise it defaults to 172.31.254.254.)

If the Requested IP Address option is topologically inappropriate for your network, this packet may provoke a DHCPNAK from any DHCP server that believes it is authoritative for the network's IP topology.

DHCPREQUEST (REBINDING)

This packet is typical of a DHCP client in the REBINDING state; i.e. a client which has obtained a DHCP lease which is between its DHCP T2 and expiration time. The options field contains a DHCP Message Type specifying DHCPREQUEST.

The options field contains a DHCP Client Identifier, which is computed by prepending 0x'01' to the value of chaddr. (The value chaddr is specified in the dhcp_probe.cf(5) file, otherwise it defaults to the interface's Ethernet address.)

The ciaddr field contains client_ip_address, which should be an IP address that does not correspond to any valid IP address on your network; ideally it should be one that is topologically inappropriate for your network. (The value client_ip_address is specified in the dhcp_probe.cf(5) file, otherwise it defaults to 172.31.254.254.)

If the value of ciaddr is topologically inappropriate for your network, this packet will provoke a DHCPNAK from any DHCP server that believes it is authoritative for the network's IP topology.

All the request packets sent by the program share the following common characteristics:

Ethernet Header

destination: ff:ff:ff:ff:ff:ff

source: ether_src from dhcp_probe.cf(5), else interface hardware address

type: ETHERTYPE_IP (0x0800)

IP Header

version: 4

header length: 5

tos: 0

total length: 328 (20-byte IP header + 8-byte UDP header + 300-byte BootP/DHCP payload)

identifier: 1

flags: 0

fragment offset: 0

ttl: 60

protocol: IPPROTO_UDP (17)

header checksum: (computed)

source address: 0.0.0.0

destination address: 255.255.255.255

options: (none)

UDP Header

source port: PORT_BOOTPC (68)

dest port: PORT_BOOTPS (67)

checksum: (computed)

BootP/DHCP Payload

op: BOOTREQUEST (1)

htype: HTYPE_ETHER (1)

hlen: HLEN_ETHER (6)

hops: 0

xid: 1

secs: 0

flags: 0

ciaddr: 0.0.0.0 (except for DHCPREQUEST (REBINDING) packets it is client_ip_address from dhcp_probe.cf(5), else 172.31.254.254)

siaddr: 0.0.0.0

giaddr: 0.0.0.0

chaddr: chaddr from dhcp_probe.cf(5), else interface hardware address

sname: (all 0's)

file: (all 0's)

options: RFC1048 cookie (0x63825363), possibly followed by DHCP options, followed by END option (0xFF), followed by PAD options (0x00) to bring the field to 64 bytes

## MULTIPLE INTERFACES
Although dhcp_probe only supports monitoring a single physical interface, you may run an instance of the program on each physical interface; each monitors a different physical network.

When running multiple copies of dhcp_probe, be sure to specify a different pid_file for each instance.

If you specify a log_file and/or a capture_file, be sure to specify a different one for each instance.

You may specify a different config_file for each instance. If you don't need to customize the settings in that file for each instance, you may use the same configuration file for all instances.

If you have multiple logical interfaces on the same physical interface, or multiple logical IP networks running on a single physical network, there is no need to run multiple instances of dhcp_probe to monitor each logical interfaces or logical network. A single instance of the program running on a physical interface is sufficient to provoke any servers on that physical network that might be willing to respond.

If your physical interface supports 802.1Q, you can use a single physical interface to monitor multiple VLANs. Use your operating system to create a logical interface on each VLAN, then run an instance of the program on each logical interface. Since the program is responsible for constructing Ethernet frame headers, you will probably need to specify the -Q option to instruct it to add to outgoing frames an 802.1Q VLAN header with the appropriate VLAN ID.

## SIGNALS
The program will respond to a number of signals:

SIGUSR1

If logging to a file, close and re-open it. If the program is in the middle of a probe cycle, handling the signal is deferred until the end of the cycle. (Has no effect if logging to syslog(3) or if the -f option was specified.)

SIGUSR2

If capturing to a file, close and re-open it. If the program is in the middle of a probe cycle, handling the signal is deferred until the end of the cycle. (Has no effect if the -o option was not specified.) Because re-opening the capture file causes the file to be truncated and a new pcap(3) header to be written to it, if you want to save the prior contents of the capture file, move the existing capture file aside before sending the signal.

SIGHUP

Reread the configuration file. If the program is in the middle of a probe cycle, handling the signal is deferred until the end of the cycle.

SIGTERM, SIGINT, SIGQUIT

Exit gracefully. If the program is in the middle of a probe cycle, handling the signal is deferred until the program finishes sending and receiving responses for the current flavor request packet.

## LEASE NETWORKS OF CONCERN
Most rogue BootP/DHCP servers distribute private IP addresses to clients, or send DHCPNAK messages to legitimate clients. Some even more disruptive rogue BootP/DHCP servers may distribute IP addresses that fall within your own networks' IP ranges. The "Lease Networks of Concern" feature is intended to help you identify these particularly disruptive servers.

You may activate the feature by specifying the lease_network_of_concern statement in your configuration file. Use the statement multiple times to specify all your legitimate network ranges.

When a rogue BootP/DHCP server is detected, if the rogue's response packet contains a non-zero yiaddr value, the value is compared to the "Lease Networks of Concern" you specified. If the value falls within any of those network ranges, the message logged by dhcp_probe is extended to make note of this, and to report the yiaddr value. Furthermore, if you are using the alert_program_name2 feature, the alert program is called with an extra -y yiaddr option so that alert program can take any additional action desired.

## DEBUG LEVELS
The program produces increasingly detailed output as the debuglevel increases. Under normal circumstances, you can run at debuglevel 0. Here's roughly what messages are added at each debuglevel.

0

Display the IP source (and Ethernet source) of each unexpected DHCP or BootP response packet. Startup and shutdown notice.

Non-fatal errors in the configuration file.

Fatal errors.

1

At startup, show some information about the program's configuration.

2

Show each time we start and finish (re-)reading the configuration file. Show each time we close and re-open the logfile or capture file.

Report on response packets that could not be parsed (e.g. truncated).

3

Each time we (re-)read the configuration file, echo the information we obtain from it.

7

For each parsable response packet, show the Ethernet source and destination, the IP source and destination, and indicate when the IP source is a legal (known) server.

11

For each probe cycle, show when the cycle begins and ends, when we write a packet, and when we begin and end listening for response packets.

## AUTHOR
The program was written by Irwin Tillman of Princeton University's OIT Network Systems Group. It was written to run on Solaris, relying on the generally-available pcap(3) and libnet(3) libraries.

## FILES
/etc/dhcp_probe.cf

Configuration file read by the program. See dhcp_probe.cf(5). The name of this file can be overridden by a command-line option.

/etc/dhcp_probe.pid

Contains the program's processid. The name of this file can be overridden by a command-line option.

## LIMITATIONS
dhcp_probe is not guaranteed to locate all unknown DHCP and BootP servers attached to a network. If a BootP server is configured so it only responds to certain clients (e.g. those with certain hardware addresses), it will not respond to the BOOTPREQUEST packet we sent. If a DHCP server is configured so it only responds to certain clients (e.g. those with certain hardware addresses or DHCP Client Identifiers), it will not respond to the packets we send that mimic DHCP clients in the INIT state. If a DHCP server is configured so it does not send DHCPNAK packets to clients requesting topologically-inappropriate IP addresses, it will not respond the packets we send that mimic DHCP clients in the INIT-REBOOT and REBINDING states.

The upshot is that it is possible that dhcp_probe will be unable to provoke some BootP and DHCP servers into responding at all.

Flushing out such servers can be extremely difficult. One approach is to capture all UDP/IP packet destined to the BootP client port which cross your network; since most of these packets are unicast at Layer 2, capturing is only effective if all such packets must pass by your capture device's Ethernet interface (e.g. the capture device is located at a network choke point, or the network does not involve any Layer 2 switching). Another approach is to do UDP port scanning for all devices listening on the BootP server port, and assume that those which are listening on that port are running a BootP or DHCP server.

Malicious BootP or DHCP servers that forge the IP source address (and possibly the Ethernet source address) of their responses to match the values specified by legal_server and legal_server_ethersrc statements will not be detected.

## BUGS
The packet capture buffer size is limited; if a single request packet provokes more responses than will fit into the buffer, those that do not fit are silently dropped, without any diagnostic indicating that the buffer was too small. You can adjust the size of the packet capture buffer size using the -s capture_bufsize option.

We do not support non-Ethernet interfaces.

Because (re-)opening a packet capture file causes the file to be opened for writing (not appending), the contents of any existing packet capture file of the same name is lost when the program starts or receives a SIGUSR2 signal. If the file's previous contents should be preserved, move the old file aside before starting the program or sending it a SIGUSR2 signal. (This "feature" exists because opening a pcap(3) savefile always involves writing a pcap header record to the start of the file, so pcap always opens the file using mode "w".)

Because pcap(3) opens the packet capture file with a simple fopen(3) without checking to see if the file already exists, dhcp_probe may be tricked into overwriting or corrupting an existing file. As dhcp_probe is run with root privileges, this is a serious concern. To avoid this problem, if you use the -o option, ensure that the directory that will contain the capture file is writable only by root.

The packet capture file that is written is unparseable after the first packet. E.g. if read with tcpdump(8), it reports: tcpdump: pcap_loop: truncated dump file.

On platforms where pcap(3) is unable to support the timeout argument to pcap_open_live, the program may not reliably detect responses from DHCP and BootP servers, or may not function at all.

## SEE ALSO
dhcp_probe.cf(5)

pcap(3)

(a.k.a. libpcap, a packet capture library), available from http://www.tcpdump.org. (An older version is available from ftp://ftp.ee.lbl.gov/libpcap.tar.Z.)

libnet(3)

(a.k.a libwrite, a packet writing library), available from http://www.packetfactory.net/libnet