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 or logical interfaces, you may run an instance of dhcp_probe on each physical or logical interface. If your physical interface supports 802.1Q, you can use that to create a logical (untagged) interface on each VLAN, then run an instance of dhcp_probe on each logical (untagged) 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 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 https://www.net.princeton.edu/software/dhcp_probe/

Presently the product builds and runs on Solaris 10 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 when the program constructs a packet to send, it should add an 802.1Q tag with the specified vlan_id. Valid values range from 0 to 4095. If not specified, the program does not add an 802.1Q tag to the packets it constructs. (The operating system or Ethernet driver may still do so.)

-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. Typically this interface must also have an IP address assigned; specifying do_not_lookup_enet_and_ip_addresses in dhcp_probe.cf(5) may allow the program to operate on an interface which lacks 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 versions 1.3.0 - 1.3.1, 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 or logical interface, you may run an instance of the program on each physical or logical interface; each monitors a different 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 VLAN on the same physical interface, or multiple logical IP networks on the same VLAN running on a single physical network, there is no need to run multiple instances of dhcp_probe to monitor each logical interface or logical network. A single instance of the program running on a physical interface or logical interface is sufficient to provoke any servers on that one VLAN on that physical (or logical) 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 the same physical interface) for each VLAN. When frames arrive on the physical interface containing the 802.1Q tag you specified for the logical interface, your operating system is responsible for delivering those frames to the logical interface with the 802.1Q tag removed. (Some Ethernet drivers will retain the 802.1Q tag but change the VLAN ID to 0; we understand that format.) Run an instance of the program on each logical interface. If your operating system and network driver does not automatically add an 802.1Q header to the packets we transmit, you will also need to specify the -Q option to instruct the program to add an 802.1Q header to the packets it constructs. (If the operating system or network driver automatically adds the 802.1Q header to these packets, then specifying -Q will likely not do what you want. Selecting the wrong choice often means that the packets we construct will be transmitted incorrectly, or may be silently discarded by the operating system or the Ethernet switch.)

## 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 overriden 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.

If the network contains any Ethernet switch which selectively filters (rather than floods) layer 2 broadcasts sent by DHCP/BootP clients, dhcp_probe will be unable to locate DHCP and BootP servers on the far side of that Ethernet switch. Such switches prevent the probe packets from reaching rogue DHCP/BootP servers. For example, some Cisco Nexus(R) switch/routers models configured to act as a network's IPv4 router and BootP Relay Agent may not flood such frames, instead delivering them only to the router's embedded BootP Relay Agent.

## 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

## TRADEMARKS
Cisco Nexus(R) is a trademark of Cisco Systems.


dhcpcd

package: dhcpcd

title: dhcpcd(8)

summary: a DHCP client

text:
# dhcpcd(8)

## NAME
dhcpcd — a DHCP client

## SYNOPSIS
dhcpcd

[-146ABbDdEGgHJKLMNPpqTV] [-C, --nohook hook] [-c, --script script] [-e, --env value] [-F, --fqdn FQDN] [-f, --config file] [-h, --hostname hostname] [-I, --clientid clientid] [-i, --vendorclassid vendorclassid] [-j, --logfile logfile] [-l, --leasetime seconds] [-m, --metric metric] [-O, --nooption option] [-o, --option option] [-Q, --require option] [-r, --request address] [-S, --static value] [-s, --inform address[/cidr[/broadcast_address]]] [--inform6] [-t, --timeout seconds] [-u, --userclass class] [-v, --vendor code, value] [-W, --whitelist address[/cidr]] [-w] [--waitip=[4 | 6]] [-y, --reboot seconds] [-X, --blacklist address[/cidr]] [-Z, --denyinterfaces pattern] [-z, --allowinterfaces pattern] [--inactive] [--configure] [--noconfigure] [interface] [...]

dhcpcd

-n, --rebind [interface]

dhcpcd

-k, --release [interface]

dhcpcd

-U, --dumplease [interface]

dhcpcd

--version

dhcpcd

-x, --exit [interface]

## DESCRIPTION
dhcpcd is an implementation of the DHCP client specified in RFC 2131. dhcpcd gets the host information (IP address, routes, etc) from a DHCP server and configures the network interface of the machine on which it is running. dhcpcd then runs the configuration script which writes DNS information to resolvconf(8), if available, otherwise directly to /etc/resolv.conf. If the hostname is currently blank, (null) or localhost, or force_hostname is YES or TRUE or 1 then dhcpcd sets the hostname to the one supplied by the DHCP server. dhcpcd then daemonises and waits for the lease renewal time to lapse. It will then attempt to renew its lease and reconfigure if the new lease changes when the lease begins to expire or the DHCP server sends a message to renew early.

If any interface reports a working carrier then dhcpcd will try to obtain a lease before forking to the background, otherwise it will fork right away. This behaviour can be modified with the -b, --background and -w, --waitip options.

dhcpcd is also an implementation of the BOOTP client specified in RFC 951.

dhcpcd is also an implementation of the IPv6 Router Solicitor as specified in RFC 4861 and RFC 6106.

dhcpcd is also an implementation of the IPv6 Privacy Extensions to AutoConf as specified in RFC 4941. This feature needs to be enabled in the kernel and dhcpcd will start using it.

dhcpcd is also an implementation of the DHCPv6 client as specified in RFC 3315. By default, dhcpcd only starts DHCPv6 when instructed to do so by an IPV6 Router Advertisement. If no Identity Association is configured, then a Non-temporary Address is requested.

### Local Link configuration
If dhcpcd failed to obtain a lease, it probes for a valid IPv4LL address (aka ZeroConf, aka APIPA). Once obtained it restarts the process of looking for a DHCP server to get a proper address.

When using IPv4LL, dhcpcd nearly always succeeds and returns an exit code of 0. In the rare case it fails, it normally means that there is a reverse ARP proxy installed which always defeats IPv4LL probing. To disable this behaviour, you can use the -L, --noipv4ll option.

### Multiple interfaces
If a list of interfaces are given on the command line, then dhcpcd only works with those interfaces, otherwise dhcpcd discovers available Ethernet interfaces that can be configured. When dhcpcd is not limited to one interface on the command line, it is running in Manager mode. The dhcpcd-ui project expects dhcpcd to be running this way.

If a single interface is given then dhcpcd only works for that interface and runs as a separate instance to other dhcpcd processes. The -w, --waitip option is enabled in this instance to maintain compatibility with older versions. Using a single interface, optionally further limited to an address protocol, also affects the -k, -N, -n and -x options, where the same interface and any address protocol will need to be specified, as a lack of an interface will imply Manager mode which this is not. To force starting in Manager mode with only one interface, the -M, --manager option can be used.

Interfaces are preferred by carrier, DHCP lease/IPv4LL and then lowest metric. For systems that support route metrics, each route will be tagged with the metric, otherwise dhcpcd changes the routes to use the interface with the same route and the lowest metric. See options below for controlling which interfaces we allow and deny through the use of patterns.

Non-ethernet interfaces and some virtual ethernet interfaces such as TAP and bridge are ignored by default, as is the FireWire interface. To work with these devices they either need to be specified on the command line, be listed in --allowinterfaces or have an interface directive in /etc/dhcpcd.conf.

### Hooking into events
dhcpcd runs /lib/dhcpcd/dhcpcd-run-hooks, or the script specified by the -c, --script option. This script runs each script found in /lib/dhcpcd/dhcpcd-hooks in a lexical order. The default installation supplies the scripts 01-test, 20-resolv.conf and 30-hostname. You can disable each script by using the -C, --nohook option. See dhcpcd-run-hooks(8) for details on how these scripts work. dhcpcd currently ignores the exit code of the script.

More scripts are supplied in /usr/share/dhcpcd/hooks and need to be copied to /lib/dhcpcd/dhcpcd-hooks if you intend to use them. For example, you could install 29-lookup-hostname so that dhcpcd can lookup the hostname of the IP address in DNS if no hostname is given by the lease and one is not already set.

### Fine tuning
You can fine-tune the behaviour of dhcpcd with the following options:

-b, --background

Background immediately. This is useful for startup scripts which don't disable link messages for carrier status.

-c, --script script

Use this script instead of the default /lib/dhcpcd/dhcpcd-run-hooks.

-D, --duid [ll | lt | uuid | value]

Use a DHCP Unique Identifier. If persistent storage is available then a DUID-LLT (link local address + time) is generated, otherwise DUID-LL is generated (link local address). The DUID type can be hinted as an optional parameter if the file /var/lib/dhcpcd/duid does not exist. If not ll, lt or uuid then value will be converted from 00:11:22:33 format. This, plus the IAID will be used as the -I, --clientid. The DUID generated will be held in /var/lib/dhcpcd/duid and should not be copied to other hosts. This file also takes precedence over the above rules except for setting a value.

-d, --debug

Echo debug messages to the stderr and syslog.

-E, --lastlease

If dhcpcd cannot obtain a lease, then try to use the last lease acquired for the interface.

--lastleaseextend

Same as the above, but the lease will be retained even if it expires. dhcpcd will give it up if any other host tries to claim it for their own via ARP. This violates RFC 2131, section 3.7, which states the lease should be dropped once it has expired.

-e, --env value

Push value to the environment for use in dhcpcd-run-hooks(8). For example, you can force the hostname hook to always set the hostname with -e force_hostname=YES.

-g, --reconfigure

dhcpcd will re-apply IP address, routing and run dhcpcd-run-hooks(8) for each interface. This is useful so that a 3rd party such as PPP or VPN can change the routing table and / or DNS, etc and then instruct dhcpcd to put things back afterwards. dhcpcd does not read a new configuration when this happens - you should rebind if you need that functionality.

-F, --fqdn fqdn

Requests that the DHCP server update DNS using FQDN instead of just a hostname. Valid values for fqdn are disable, none, ptr and both. dhcpcd itself never does any DNS updates. dhcpcd encodes the FQDN hostname as specified in RFC 1035.

-f, --config file

Specify a config to load instead of /etc/dhcpcd.conf. dhcpcd always processes the config file before any command line options.

-h, --hostname hostname

Sends hostname to the DHCP server so it can be registered in DNS. If hostname is an empty string then the current system hostname is sent. If hostname is a FQDN (i.e., contains a .) then it will be encoded as such.

-I, --clientid clientid

Send the clientid. If the string is of the format 01:02:03 then it is encoded as hex. For interfaces whose hardware address is longer than 8 bytes, or if the clientid is an empty string then dhcpcd sends a default clientid of the hardware family and the hardware address.

-i, --vendorclassid vendorclassid

Override the DHCPv4 vendorclassid field sent. The default is dhcpcd-<version>:<os>:<machine>:<platform>. For example dhcpcd-5.5.6:NetBSD-6.99.5:i386:i386

If not set then none is sent. Some badly configured DHCP servers reject unknown vendorclassids. To work around it, try and impersonate Windows by using the MSFT vendorclassid.

-j, --logfile logfile

Writes to the specified logfile. dhcpcd still writes to syslog(3). The logfile is reopened when dhcpcd receives the SIGUSR2 signal.

-k, --release [interface]

This causes an existing dhcpcd process running on the interface to release its lease and de-configure the interface regardless of the -p, --persistent option. If no interface is specified then this applies to all interfaces in Manager mode. If no interfaces are left running, dhcpcd will exit.

-l, --leasetime seconds

Request a lease time of seconds. -1 represents an infinite lease time. By default dhcpcd does not request any lease time and leaves it in the hands of the DHCP server.

-M, --manager

Start dhcpcd in Manager mode even if only one interface specified on the command line. See the Multiple Interfaces section above.

-m, --metric metric

Metrics are used to prefer an interface over another one, lowest wins. dhcpcd will supply a default metric of 1000 + if_nametoindex(3). This will be offset by 2000 for wireless interfaces, with additional offsets of 1000000 for IPv4LL and 2000000 for roaming interfaces.

-n, --rebind [interface]

Notifies dhcpcd to reload its configuration and rebind the specified interface. If no interface is specified then this applies to all interfaces in Manager mode. If dhcpcd is not running, then it starts up as normal.

-N, --renew [interface]

Notifies dhcpcd to renew existing addresses on the specified interface. If no interface is specified then this applies to all interfaces in Manager mode. If dhcpcd is not running, then it starts up as normal. Unlike the -n, --rebind option above, the configuration for dhcpcd is not reloaded.

-o, --option option

Request the DHCP option variable for use in /lib/dhcpcd/dhcpcd-run-hooks.

-p, --persistent

dhcpcd de-configures the interface when it exits unless this option is enabled. Sometimes, this isn't desirable if, for example, you have root mounted over NFS or SSH clients connect to this host and they need to be notified of the host shutting down. You can use this option to stop this from happening.

-r, --request address

Request the address in the DHCP DISCOVER message. There is no guarantee this is the address the DHCP server will actually give. If no address is given then the first address currently assigned to the interface is used.

-s, --inform address[/cidr[/broadcast_address]]

Behaves like -r, --request as above, but sends a DHCP INFORM instead of DISCOVER/REQUEST. This does not get a lease as such, just notifies the DHCP server of the address in use. You should also include the optional cidr network number in case the address is not already configured on the interface. dhcpcd remains running and pretends it has an infinite lease. dhcpcd will not de-configure the interface when it exits. If dhcpcd fails to contact a DHCP server then it returns a failure instead of falling back on IPv4LL.

--inform6

Performs a DHCPv6 Information Request. No address is requested or specified, but all other DHCPv6 options are allowed. This is normally performed automatically when the IPv6 Router Advertises that the client should perform this operation. This option is only needed when dhcpcd is not processing IPv6RA messages and the need for DHCPv6 Information Request exists.

-S, --static value

Configures a static DHCP value. If you set ip_address then dhcpcd will not attempt to obtain a lease and just use the value for the address with an infinite lease time. Here is an example which configures a static address, routes and DNS.

dhcpcd -S ip_address=192.168.0.10/24 \

-S routers=192.168.0.1 \

-S domain_name_servers=192.168.0.1 \

eth0

You cannot presently set static DHCPv6 values. Use the -e, --env option instead.

-t, --timeout seconds

Timeout after seconds, instead of the default 30. A setting of 0 seconds causes dhcpcd to wait forever to get a lease. If dhcpcd is working on a single interface then dhcpcd will exit when a timeout occurs, otherwise dhcpcd will fork into the background.

-u, --userclass class

Tags the DHCPv4 message with the userclass class. DHCP servers use this to give members of the class DHCP options other than the default, without having to know things like hardware address or hostname.

-v, --vendor code,value

Add an encapsulated vendor option. code should be between 1 and 254 inclusive. To add a raw vendor string, omit code but keep the comma. Examples. Set the vendor option 01 with an IP address.

dhcpcd -v 01,192.168.0.2 eth0

Set the vendor option 02 with a hex code. dhcpcd -v 02,01:02:03:04:05 eth0

Set the vendor option 03 with an IP address as a string. dhcpcd -v 03,\"192.168.0.2\" eth0

Set un-encapsulated vendor option to hello world. dhcpcd -v ,"hello world" eth0

--version

Display both program version and copyright information. dhcpcd then exits before doing any configuration.

-w

Wait for an address to be assigned before forking to the background. Does not take an argument, unlike the below option.

--waitip=[4 | 6]

Wait for an address to be assigned before forking to the background. 4 means wait for an IPv4 address to be assigned. 6 means wait for an IPv6 address to be assigned. If no argument is given, dhcpcd will wait for any address protocol to be assigned. It is possible to wait for more than one address protocol and dhcpcd will only fork to the background when all waiting conditions are satisfied.

-x, --exit [interface]

This will signal an existing dhcpcd process running on the interface to exit. If no interface is specified, then the above is applied to all interfaces in Manager mode. See the -p, --persistent option to control configuration persistence on exit, which is enabled by default in dhcpcd.conf(5). dhcpcd then waits until this process has exited.

-y, --reboot seconds

Allow reboot seconds before moving to the discover phase if we have an old lease to use. Allow reboot seconds before starting fallback states from the discover phase. IPv4LL is started when the first reboot timeout is reached. The default is 5 seconds. A setting of 0 seconds causes dhcpcd to skip the reboot phase and go straight into discover. This has no effect on DHCPv6 other than skipping the reboot phase.

### Restricting behaviour
dhcpcd will try to do as much as it can by default. However, there are sometimes situations where you don't want the things to be configured exactly how the DHCP server wants. Here are some options that deal with turning these bits off.

Note that when dhcpcd is restricted to a single interface then the interface also needs to be specified when asking dhcpcd to exit using the commandline. If the protocol is restricted as well then the protocol needs to be included with the exit instruction.

-1, --oneshot

Exit after configuring an interface. Use the -w, --waitip option to specify which protocol(s) to configure before exiting.

-4, --ipv4only

Configure IPv4 only.

-6, --ipv6only

Configure IPv6 only.

-A, --noarp

Don't request or claim the address by ARP. This also disables IPv4LL.

-B, --nobackground

Don't run in the background when we acquire a lease. This is mainly useful for running under the control of another process, such as a debugger or a network manager.

-C, --nohook script

Don't run this hook script. Matches full name, or prefixed with 2 numbers optionally ending with .sh. So to stop dhcpcd from touching your DNS settings you would do:-

dhcpcd -C resolv.conf eth0

-G, --nogateway

Don't set any default routes.

-H, --xidhwaddr

Use the last four bytes of the hardware address as the DHCP xid instead of a randomly generated number.

-J, --broadcast

Instructs the DHCP server to broadcast replies back to the client. Normally this is only set for non-Ethernet interfaces, such as FireWire and InfiniBand. In most instances, dhcpcd will set this automatically.

-K, --nolink

Don't receive link messages for carrier status. You should only have to use this with buggy device drivers or running dhcpcd through a network manager.

-L, --noipv4ll

Don't use IPv4LL (aka APIPA, aka Bonjour, aka ZeroConf).

-O, --nooption option

Removes the option from the DHCP message before processing.

-P, --printpidfile

Print the pidfile dhcpcd will use based on command-line arguments to stdout.

-Q, --require option

Requires the option to be present in all DHCP messages, otherwise the message is ignored. To enforce that dhcpcd only responds to DHCP servers and not BOOTP servers, you can -Q dhcp_message_type.

-q, --quiet

Quiet dhcpcd on the command line, only warnings and errors will be displayed. If this option is used another time then all console output is disabled. These messages are still logged via syslog(3).

-T, --test

On receipt of DHCP messages just call /lib/dhcpcd/dhcpcd-run-hooks with the reason of TEST which echos the DHCP variables found in the message to the console. The interface configuration isn't touched and neither are any configuration files. The rapid_commit option is not sent in TEST mode so that the server does not lease an address. To test INFORM the interface needs to be configured with the desired address before starting dhcpcd.

-U, --dumplease [interface]

Dumps the current lease for the interface to stdout. If no interface is given then all interfaces are dumped. Use the -4 or -6 flags to specify an address family. If a lease is piped in via standard input then use the special interface named - to dump it. In this case, specifying an address family is mandatory.

-V, --variables

Display a list of option codes, the associated variable and encoding for use in dhcpcd-run-hooks(8). Variables are prefixed with new_ and old_ unless the option number is -. Variables without an option are part of the DHCP message and cannot be directly requested.

-W, --whitelist address[/cidr]

Only accept packets from address[/cidr]. -X, --blacklist is ignored if -W, --whitelist is set.

-X, --blacklist address[/cidr]

Ignore all packets from address[/cidr].

-Z, --denyinterfaces pattern

When discovering interfaces, the interface name must not match pattern which is a space or comma separated list of patterns passed to fnmatch(3).

-z, --allowinterfaces pattern

When discovering interfaces, the interface name must match pattern which is a space or comma separated list of patterns passed to fnmatch(3). If the same interface is matched in -Z, --denyinterfaces then it is still denied.

--inactive

Don't start any interfaces other than those specified on the command line. This allows dhcpcd to be started in Manager mode and then wait for subsequent dhcpcd commands to start each interface as required.

--configure

Allows dhcpcd to configure the system. This is the default behaviour and sets if_configured=true.

--noconfigure

dhcpcd will not configure the system at all. This is only of use if the --script that dhcpcd calls at each network event configures the system instead. This is different from -T, --test mode in that it's not one shot and the only change to the environment is the addition of if_configured=false.

--nodev

Don't load any /dev management modules.

## 3RDPARTY LINK MANAGEMENT
Some interfaces require configuration by 3rd parties, such as PPP or VPN. When an interface configuration in dhcpcd is marked as STATIC or INFORM without an address then dhcpcd will monitor the interface until an address is added or removed from it and act accordingly. For point to point interfaces (like PPP), a default route to its destination is automatically added to the configuration. If the point to point interface is configured for INFORM, then dhcpcd unicasts INFORM to the destination, otherwise it defaults to STATIC.

## NOTES
dhcpcd requires a Berkeley Packet Filter, or BPF device on BSD based systems and a Linux Socket Filter, or LPF device on Linux based systems for all IPv4 configuration.

If restricting dhcpcd to a single interface and optionally address family via the command-line then all further calls to dhcpcd to rebind, reconfigure or exit need to include the same restrictive flags so that dhcpcd knows which process to signal.

Some DHCP servers implement ClientID filtering. If dhcpcd is replacing an in-use DHCP client then you might need to adjust the clientid option dhcpcd sends to match. If using a DUID in place of the ClientID, edit /var/lib/dhcpcd/duid accordingly.

## FILES
/etc/dhcpcd.conf

Configuration file for dhcpcd. If you always use the same options, put them here.

/lib/dhcpcd/dhcpcd-run-hooks

Bourne shell script that is run to configure or de-configure an interface.

/usr/lib64/dhcpcd/dev

Linux /dev management modules.

/lib/dhcpcd/dhcpcd-hooks

A directory containing Bourne shell scripts that are run by the above script. Each script can be disabled by using the -C, --nohook option described above.

/var/lib/dhcpcd/duid

Text file that holds the DUID used to identify the host.

/var/lib/dhcpcd/secret

Text file that holds a secret key known only to the host.

/var/lib/dhcpcd/interface-ssid.lease

The actual DHCP message sent by the server. We use this when reading the last lease and use the file's mtime as when it was issued.

/var/lib/dhcpcd/interface-ssid.lease6

The actual DHCPv6 message sent by the server. We use this when reading the last lease and use the file's mtime as when it was issued.

/var/lib/dhcpcd/rdm_monotonic

Stores the monotonic counter used in the replay field in Authentication Options.

/run/dhcpcd/pid

Stores the PID of dhcpcd running on all interfaces.

/run/dhcpcd/interface.pid

Stores the PID of dhcpcd running on the interface.

/run/dhcpcd/sock

Control socket to the manager daemon.

/run/dhcpcd/unpriv.sock

Unprivileged socket to the manager daemon, only allows state retrieval.

/run/dhcpcd/interface.sock

Control socket to per interface daemon.

/run/dhcpcd/interface.unpriv.sock

Unprivileged socket to per interface daemon, only allows state retrieval.

## SEE ALSO
fnmatch(3), if_nametoindex(3), dhcpcd.conf(5), resolv.conf(5), dhcpcd-run-hooks(8), resolvconf(8)

## STANDARDS
RFC 951, RFC 1534, RFC 2104, RFC 2131, RFC 2132, RFC 2563, RFC 2855, RFC 3004, RFC 3118, RFC 3203, RFC 3315, RFC 3361, RFC 3633, RFC 3396, RFC 3397, RFC 3442, RFC 3495, RFC 3925, RFC 3927, RFC 4039, RFC 4075, RFC 4242, RFC 4361, RFC 4390, RFC 4702, RFC 4074, RFC 4861, RFC 4833, RFC 4941, RFC 5227, RFC 5942, RFC 5969, RFC 6106, RFC 6334, RFC 6355, RFC 6603, RFC 6704, RFC 7217, RFC 7550, RFC 7844.

## AUTHORS
Roy Marples <roy@marples.name>

## BUGS
Please report them to https://roy.marples.name/projects/dhcpcd

branch: sisyphus


dhcpcd-run-hooks

title: dhcpcd-run-hooks(8)

summary: DHCP client configuration script

text:
# dhcpcd-run-hooks(8)

## NAME
dhcpcd-run-hooks — DHCP client configuration script

## DESCRIPTION
dhcpcd-run-hooks is used by dhcpcd(8) to run any system and user defined hook scripts. System hook scripts are found in /lib/dhcpcd/dhcpcd-hooks and the user defined hooks are /etc/dhcpcd.enter-hook. and /etc/dhcpcd.exit-hook. The default install supplies hook scripts for configuring /etc/resolv.conf and the hostname. Your distribution may have included other hook scripts to say configure ntp or ypbind. A test hook is also supplied that simply echos the dhcp variables to the console from DISCOVER message.

The hooks scripts are loaded into the current shell rather than executed in their own process. This allows each hook script, such as /etc/dhcpcd.enter-hook to customise environment variables or provide alternative functions to hooks further down the chain. As such, using the shell builtins exit, exec or similar will cause dhcpcd-run-hooks to exit at that point.

Each time dhcpcd-run-hooks is invoked, $interface is set to the interface that dhcpcd is run on and $reason is set to the reason why dhcpcd-run-hooks was invoked. DHCP information to be configured is held in variables starting with the word new_ and old DHCP information to be removed is held in variables starting with the word old_. dhcpcd can display the full list of variables it knows about by using the -V, --variables argument.

Here's a list of reasons why dhcpcd-run-hooks could be invoked:

PREINIT

dhcpcd is starting up and any pre-initialisation required should be performed now.

CARRIER

dhcpcd has detected the carrier is up. This is generally just a notification and no action need be taken.

NOCARRIER

dhcpcd lost the carrier. The cable may have been unplugged or association to the wireless point lost.

NOCARRIER_ROAMING

dhcpcd lost the carrier but the interface configuration is persisted. The OS has to support wireless roaming or IP Persistence for this to happen.

INFORM | INFORM6

dhcpcd informed a DHCP server about its address and obtained other configuration details.

BOUND | BOUND6

dhcpcd obtained a new lease from a DHCP server.

RENEW | RENEW6

dhcpcd renewed its lease.

REBIND | REBIND6

dhcpcd has rebound to a new DHCP server.

REBOOT | REBOOT6

dhcpcd successfully requested a lease from a DHCP server.

RELEASE | RELEASE6

dhcpcd has released the lease.

DELEGATED6

dhcpcd assigned a delegated prefix to the interface.

IPV4LL

dhcpcd obtained an IPV4LL address, or one was removed.

STATIC

dhcpcd has been configured with a static configuration which has not been obtained from a DHCP server.

3RDPARTY

dhcpcd is monitoring the interface for a 3rd party to give it an IP address.

TIMEOUT | TIMEOUT6

dhcpcd failed to contact any DHCP servers but was able to use an old lease.

EXPIRE | EXPIRE6

dhcpcd's lease or state expired and it failed to obtain a new one.

NAK

dhcpcd received a NAK from the DHCP server. This should be treated as EXPIRE.

RECONFIGURE

dhcpcd has been instructed to reconfigure an interface.

ROUTERADVERT

dhcpcd has received an IPv6 Router Advertisement, or one has expired.

STOP | STOP6

dhcpcd stopped running on the interface.

STOPPED

dhcpcd has stopped entirely.

DEPARTED

The interface has been removed.

FAIL

dhcpcd failed to operate on the interface. This normally happens when dhcpcd does not support the raw interface, which means it cannot work as a DHCP or ZeroConf client. Static configuration and DHCP INFORM is still allowed.

TEST

dhcpcd received an OFFER from a DHCP server but will not configure the interface. This is primarily used to test the variables are filled correctly for the script to process them.

## ENVIRONMENT
dhcpcd will clear the environment variables aside from $PATH. The following variables will then be set, along with any protocol supplied ones.

$interface

the name of the interface.

$protocol

the protocol that triggered the event.

$reason

as described above.

$pid

the pid of dhcpcd.

$ifcarrier

the link status of $interface: unknown, up or down.

$ifmetric

$interface preference, lower is better.

$ifwireless

1 if $interface is wireless, otherwise 0.

$ifflags

$interface flags.

$ifmtu

$interface MTU.

$ifssid

the SSID the interface is connected to.

$interface_order

A list of interfaces, in order of preference.

$if_configured

true if dhcpcd has configured the interface otherwise false.

$if_up

true if the interface is up, otherwise false. This is more than IFF_UP and may not be equal.

$if_down

true if the interface is down, otherwise false. This is more than IFF_UP and may not be equal.

$af_waiting

Address family waiting for, as defined in dhcpcd.conf(5).

$profile

the name of the profile selected from dhcpcd.conf(5).

$new_delegated_dhcp6_prefix

space-separated list of delegated prefixes.

## FILES
When dhcpcd-run-hooks runs, it loads /etc/dhcpcd.enter-hook, any scripts found in /lib/dhcpcd/dhcpcd-hooks in lexical order, then finally /etc/dhcpcd.exit-hook.

## SEE ALSO
dhcpcd(8)

## AUTHORS
Roy Marples <roy@marples.name>

## BUGS
Please report them to https://roy.marples.name/projects/dhcpcd

## SECURITY CONSIDERATIONS
dhcpcd will validate the content of each option against its encoding. For string, ascii, raw or binhex encoding it's up to the user to validate it for the intended purpose.

When used in a shell script, each variable must be quoted correctly.


dhcpdump

package: dhcpdump

title: dhcpdump(8)

summary: DHCP packet dumper

text:
# dhcpdump(8)

## NAME
dhcpdump - DHCP packet dumper

## SYNOPSIS
dhcpdump [-h regular-expression] [-H] -i interface

dhcpdump [-h regular-expression] [-H] -r pcapfile

## DESCRIPTION
This command listens on a network interface to display the dhcp-packets for easier checking and debugging.

## USAGE
dhcpdump -i /dev/fxp0

If you want to filter a specific Client Hardware Address (CHADDR), then you can specify it as a regular expression:

dhcpdump -i /dev/fxp0 -h ^00:c0:4f

This will display only the packets with Client Hardware Addresses which start with 00:c0:4f.

Option -H will additionally show full packet hex dump.

Instead of getting live data from an interface, a pcap dump file can be used:

dhcpdump -r pcapfile

## OUTPUT

```
  TIME: 15:45:02.084272
    IP: 0.0.0.0.68 (0:c0:4f:82:ac:7f) > 255.255.255.255.67 (ff:ff:ff:ff:ff:ff)
    OP: 1 (BOOTPREQUEST)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 28f61b03
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:c0:4f:82:ac:7f:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type         3 (DHCPREQUEST)
OPTION:  54 (  4) Server identifier         130.139.64.101
OPTION:  50 (  4) Request IP address        130.139.64.143
OPTION:  55 (  7) Parameter Request List      1 (Subnet mask)
                                              3 (Routers)
                                             58 (T1)
                                             59 (T2)
```

At the option field, the first field is the value of the option, the second one (between brackets) is the length of the option-datafield, the third field is the name of the option, the fourth field is the data of the option.

## RETURN VALUES
Always 0.

## NOTES
Privileged access is often needed for accessing the interface.

## BUGS
Not all the parameter options are printed verbose, because of lack of documentation. Not all the options are tested, because of lack of clients/servers with these options. If you have a dump of one of them, please send them to me and I'll incorporate them.

## THANKS TO
Ralph Droms and Ted Lemons "The DHCP Handbook", ISBN 1-57870-137-6.

Peter Apian-Bennewitz <apian@ise.fhg.de> for his Client Hardware Address filtering

## AUTHOR
Edwin Groothuis, edwin@mavetju.org (http://www.mavetju.org)

## SEE ALSO
dhcpd(8), tcpdump(1), RFC2132


dhcping

package: dhcping

title: dhcping(8)

text:
# dhcping(8)

## NAME
dhcping - send a DHCP request to DHCP server to see if it's up and running

## SYNOPSIS
dhcping [-v] [-q] [-i] [-r] -t maxwait -c client-IP-address -s server-IP-address -h client-hardware-address [-g gateway-IP-address]

## DESCRIPTION
This command allows the system administrator to check if a remote DHCP server is still functioning.

Options are:

-v

Verbose, print some information.

-i

Use DHCPINFORM packets.

-r

Use DHCPREQUEST packets (default behaviour).

-q

Quiet, print nothing on the screen.

-t maxwait

Maximum time to wait for an answer from the server in seconds. Default is 3 seconds.

-c client-IP-address

Request this IP address. Note that this is also the IP address the answer will be sent to.

-s server-IP-address

Send the DHCP packet to this IP address.

-h client-hardware-address

Use this hardware-address in the DHCP request. It can be up to sixteen octets seperated by colons (i.e. 01:02:03:04)

-g gateway-IP-address

Use this IP address for the gateway IP address in the DHCP packet. This option is currently broken.

## RETURN VALUES
If everything goes okay, it returns 0. If there went something wrong, it returns 1.

## SETUP
This program should be installed setuid root or ran by root only. See SECURITY for more information.

On your DHCP server, add these lines to the dhcpd.conf:

```
  host <your monitoring host FQDN> {
     hardware ethernet <your monitor host mac address>;
     fixed-address     <your monitoring host IP address>;
  }
```

Then try it: $ dhcping -c your monitoring host IP address \

-s your DHCP server IP address \

-h your monitor host mac address

It will either respond with "no answer" or "Got answer from: your DHCP server IP address"

The DHCP server logfile will give:

DHCPREQUEST for 192.168.1.1 from 00:20:18:56:29:8f via ed0

DHCPACK on 192.168.1.1 to 00:20:18:56:29:8f via ed0

DHCPRELEASE of 192.168.1.1 from 00:20:18:56:29:8f via ed0 (found)

Running in DHCPINFORM mode with -i:

If you see "DHCPINFORM from 192.168.1.1 via xl0: not authoritative for subnet 192.168.1.0", you should add the authoritative statement to the subnet, See dhcpd.conf(5) for details.

When running in very verbose mode, dhcping tries to dump all data of the send and received DHCP packets. It will first dump the packet in hex-format, then decodes the header and finally the options.

## HOW IT WORKS
The client either sends a DHCPREQUEST or DHCPINFORM packet to the server and waits for an answer. Then, if a DHCPREQUEST was send, it will send a DHCPRELEASE back to the server.

## SECURITY
This program is installed setuid root as it requires the privileges to bind itself to port 68 (bootpc). Root privileges are dropped as soon as the program has bound itself to that port.

## BUGS
Currently (this may, or may not, change in the future) the ISC DHCP daemon does not write leases with a fixed IP address in the dhcpd.leases file.

DHCPINFORM packets can only be used on subnets the server is authori- tative for. If the monitoring script runs on a subnet the server isn't authoritative for, it should use the DHCPREQUEST packets. I also experienced some problems with ISC DHCPD v2 servers, but that is also in the README of it.

The -V option is still working, but shouldn't be used for debugging of the packets. Better use dhcpdump(8) for that, which is available on my website. I wanted to remove it, but decided only to do it from the documentation, not from the code. Maybe I'll need it one day for debugging.

## AUTHOR
Edwin Groothuis, edwin@mavetju.org (http://www.mavetju.org)

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