As the name implies, the DHCP Client daemon (dhcpcd) provides the client side of the DHCP protocol exchange, and it provides the means for moving the information received from the DHCP server into the client's configuration. The syntax of the dhcpcd command is dhcpcd [-dknrBCDHRT] [-t timeout] [-c filename] [-h hostname]
[-i vendorClassID] [-1 clientID] [-l leasetime] [-s [ipaddr]] [interface]
The name of the interface that dhcpcd should use for DHCP can be defined on the command line. An interface is specified only when the computer has more than one interface, and you want to use DHCP on only one of those interfaces.
The dhcpcd command accepts a large number of arguments. Two of these, -d and -T, are used for testing and debugging. The -T argument is only used for testing. It causes dhcpcd to run through the protocol exchanges with the server, but prevents it from reconfiguring the interface with the information it obtains. This allows you to check the server responses without affecting the client's configuration. The -d argument tells dhcpcd to log status messages via syslogd. These messages can be used for both monitoring and debugging.
A few of the command-line arguments impact the address lease. Two arguments, -k and -n, pass signals to the dhcpcd process. The dhcpcd -n command sends a SIGALRM signal that causes dhcpcd to renew the address lease. The command dhcpcd -k sends a SIGHUP signal to the dhcpcd process, which causes dhcpcd to release the current address lease, and delete the cached information about the lease. Because dhcpcd no longer has information about the address, it will not attempt to renew the lease on the address. Instead, it will negotiate with the server as if it had never been assigned an address. Although there is no command-line argument for the SIGTERM signal, dhcpcd does handle that signal. When dhcpcd receives a SIGTERM signal, it releases the address and terminates, but it does not remove the address from its cache. Therefore, when dhcpcd restarts after a SIGTERM, it attempts to renew its lease on the address.
Two of the arguments set timers relating to the address lease. The -t argument defines the maximum number of seconds that dhcpcd will wait for a server to provide a valid address. By default, it will wait 60 seconds. If dhcpcd gets an address before the timer expires, it exits with status of 0; if it doesn't get an address it exits with a status of l to indicate failure.
The other timer argument is -l, which defines the number of seconds the client will request for an address lease lifetime. As you saw in the section on server configuration, the server does not have to grant the lease for the amount of time requested by the client. The server's max-lease-time parameter defines the upper time limit the server will allow. By default, the dhcpcd software asks for an infinite lease that, in effect, asks for the amount of time defined by max-lease-time.
Several of the command-line arguments control the protocol interactions. By default, dhcpcd is compliant with RFC 2131. The -r argument forces compliance with the older RFC 1541 specification to make dhcpcd backward-compatible with old servers. The -B argument causes the client to request that the server respond only via broadcasting. Normally, the server sends a broadcast response only when the client does not have an address. When an address is being renewed, the client uses that address during the negotiations, and the packets are all sent in both directions via unicast. -B asks the server to respond via broadcast, even if it could respond via unicast. -C tells dhcpcd to calculate a checksum for the packets it receives. Normally, checksums are done at the transport protocol level—by UDP in the case of DHCP—not at the application level. Finally, the -s option is used if the client will not accept an address from the server. A client that has its own permanent static address uses the -s argument to tell the server that address, and to request that the server send the client any other configuration information that the server can provide. Clearly, all of these arguments (-r, -B, -C, and -s) are used for exceptional cases. Average configurations do not need these arguments.
Three of the dhcpcd arguments, -h, -i and -I, are used to send information to the server that the server can use to identify the client. -h uses the DHCP hostname option to send a hostname string to servers that require it. Most server implementations do not require this information from clients. The -I argument defines the client identifier. By default, DHCP clients use their Ethernet MAC address as an identifier. The -I argument can be used to define some other identifier. However, if a special identifier is defined with -I, the same identifier must be defined on a dhcp-client-identifier option in the dhcpd.conf file on the server. Finally, the -i argument can be used to define a non-standard vendor identifier. By default, the vendor identifier is a combination of the operating system name and the machine type. For example, the vendor identifier for our sample Red Hat system is "Linux 2.4.7-10 i686."
There are also a few arguments that control the way dhcpcd uses the information it receives from the server. Normally, the client's hostname and domain name are set by the Linux hostname command very early in the startup process (see the discussion of the rc.sysinit script in Chapter 1), and dhcpcd does not override those values. Use -D to force dhcpcd to set the client's domain name from the DHCP domainname option supplied by the server. Use -H to cause dhcpcd to set the client's hostname using the hostname option supplied by the server.
Finally, the -R argument prevents dhcpcd from replacing the existing /etc/resolv.conf file with information it receives from the server. By default, dhcpcd overwrites any existing resolver configuration with the new configuration that the server provides. When the -R argument is specified, dhcpcd leaves the old /etc/resolv.conf file untouched, and writes the new resolv.conf file in the /etc/dhcpc directory.
dhcpcd stores the configuration information it receives in the following files in the /etc/dhcpc directory:
resolv.conf This is a standard resolv.conf file created by dhcpcd from the search list and DNS server list received from the DHCP server. This file is created only in the
/etc/dhcpc directory when -R is specified on the dhcpcd command line. Normally, this file is written to the /etc directory.
dhcpcd-eth0.info This file contains the address lease information and other configuration options received from the server.
dhcpcd-eth0.cache This file contains data to be used in the DHCP packet when the client requests address renewal.
Notice that two of the filenames contain the device name eth0. This varies, based on the name of the interface on which the configuration information arrived. Most DHCP clients have only one network interface, so for most Linux clients, the filenames will be the ones listed here. Of these three files, dhcpcd-eth0.info is the most interesting. The resolv.conf file is usually a very simple resolver configuration that contains only name server addresses and a search list. The dhcpcd-ethO.cache file is unreadable, except for the string that defines the vendor identifier. On the other hand, the dhcpcd-ethO.info file is a human-readable ASCII file that contains the configuration values used by the client. Listing 8.2 shows the dhcpcd-ethO.info file from a Red Hat system.
Listing 8.2: A Sample dhcpcd-eth0.info File
[root]# ls /etc/dhcpc dhcpcd-ethO.cache dhcpcd-ethO.info [root]# cat /etc/dhcpc/dhcpcd-eth0.info
LEASETIME=42 94 9672 95
RENEWALTIME=214 74 83 64 7
The sample file shown in Listing 8.2 starts with eight basic configuration values, including the client's IP address, the network mask, the broadcast address, the default gateway, the hostname, the domain name, and the address of the DNS server. This file can be incorporated in a shell script, and the values can be used inside that script to configure the system. The keyword value pairs used in this file are very similar to those used in the /etc/sysconfig/network-script/ifcfg-ethO file mentioned in Chapter 2, "The Network Interface."
A Red Hat system with a static network configuration might contain an ifcfg-ethO file such as the one shown in Listing 8.3.
Listing 8.3: A Sample ifcfg-eth0 File
$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
Notice the BROADCAST, NETWORK, NETMASK, and IPADDR lines. These keywords exactly match keywords shown in Listing 8.2. In Listing 8.3, these values were statically defined by the system administrator. In Listing 8.2, the values came from the DHCP server. There are a few additional keyword/value pairs in Listing 8.3:
• DEVICE defines the device name, in this case eth0.
• ONBOOT specifies whether or not the interface is initialized when the system boots. Normally, an Ethernet interface is brought up and running every time the system boots.
• USERCTL specifies whether or not users can run usernetctl to bring the interface up or down. The usernetctl command is found on only a few versions of Linux. In this case, the value no prevents the user from downing the interface.
• BOOTPROTO identifies the configuration service used to configure the interface. In Listing 8.3, it is none, meaning that the interface is configured locally. Alternates are bootp if an old-fashioned BootP server is used or dhcp if a DHCP server is used.
The script /sbin/ifup performs the initial configuration of the network interface. The ifup script loads the keyword/value pairs from ifcfg-eth0. If BOOTPROTO is set to either dhcp or bootp, the script runs dhcpcd to update the network configuration values. If dhcpcd is not installed on the system, the script will run pump to update the network configuration.
Was this article helpful?