Minix Man Pages
home | helpDHCP.CONF(5) File Formats Manual DHCP.CONF(5) NAME dhcp.conf - dynamic host configuration protocol configuration SYNOPSIS /etc/dhcp.conf DESCRIPTION The file /etc/dhcp.conf contains the configuration for the DHCP client/server program dhcpd. This text is a long summation of all the elements that can be found in this configuration file. For a more "just tell me what to do" approach see boot(8). The syntax used is that of the common configuration file described in configfile(5). To find information for a client we first need its IP address. Occasionally this IP address is already known (the special "INFORM" query), but normally we have to make a first pass through the configuration file for a client entry. If that fails then we use an IP address from the pool file. If we now have an IP address then the real information gathering can begin. The DHCP daemon reads the configuration file from beginning to end and gathers all information that matches, and information from all macros that are mentioned within the elements that match. If we end up with DHCP information that includes at least a netmask definition, and is good for the network the request came in from, then it is returned to the client. If a DHCP tag is specified twice then the last one wins. In the description below we use [ and ] to denote optional things, and | to show a choice between two things. Client IDs can be either ordinary Ethernet addresses, that are treated as a seven octet string (01 followed by the Ethernet address), or any random octet string in hexadecimal. IP addresses can be simply that, or host names. These host names are searched in /etc/hosts by dhcpd itself using a domain based prefix match, i.e. you can use "flotsam" for "flotsam.example.com", but not "alpha" for "alphabeta". Once the program decides to be a server it will also look up names normally in the DNS. If a host has more than one IP address then the address on the network the query was seen on is used. Case isn't important in the configuration file, "client", "CLIENT" and "ClIeNt" are all treated the same. Some elements may optionally name a macro or a curly braces enclosed parameter list of more elements. If the element matches then the data in the macro body or parameter list is gathered. The following elements can be used: client client-ID [ip#] host [macro|{params}]; Defines a client with a given client ID that is to have the IP address denoted by host . On the first pass only the client ID is matched looking for an IP address that lies on the network the request came in on. On the information gathering pass both client ID and IP address must match. If a machine has the same Ethernet address on two or more interfaces then the IP address given out is the one on the same network as the request came in on. The optional interface name (ip#) must be used if the DHCP daemon is gathering data for itself at boot time to differentiate interfaces with the same ethernet addresses. This is only necessary under Minix-vmd when ethernets on different VLANs share the same physical ethernet. The interface name is only used for a machine's own networks, it ignored on entries for other hosts. class class-name ... macro|{params}; Includes the macro or parameters if one of the class names is matched. A host normally includes a class ID in its request. MINIX 3 and Minix-vmd use "Minix" as the class name. For Windows the class ID starts with "MSFT", and Solaris' starts with "SUNW". (Use dhcpd -d3 to find out what the full IDs are exactly.) The class names are matched if a class-name is a prefix of the class ID sent by the client. host host-spec macro|{params}; Includes the macro or parameters if the IP address of the client matches the host specification. This can either be an ordinary hostname, or a netblock in CIDR notation, e.g. 172.35.0.0/16. The example includes all IP addresses whose top 16 bits are the same as the top 16 bits of 172.35.0.0. Such a netblock automatically defines a netmask (255.255.0.0 in the example) if no netmask has been specified yet. interface ip# host [macro|{params}]; Makes dhcpd set the IP address of interface ip# (where # is a number) to the IP address denoted by host. This element should only be used for interfaces that are not true Ethernets, and so do not have a unique Ethernet address that can be used for a client element. If the machine has at least one true Ethernet then all interface elements should be added to the parameter list of a host or client element for that Ethernet interface. This binds them to that machine and allows a single configuration file to be shared among machines. Especially a server should never have "free" interface elements. The macro or parameters are only evaluated if data is gathered for the given interface. (Note that they will be hidden by a client element for another interface.) macro macro-name; Include the parameter list of the macro named macro-name defined elsewhere. (This means that "host flotsam stuff" is just short for "host flotsam { macro stuff; }".) macro macro-name {params}; Defines a macro with the given parameter list. Whenever the macro is used the parameter list is substituted instead. A macro can not be defined within another parameter list. option [ip#] server [inform]; option [ip#] relay host; option [ip#] possessive; option [ip#] hostname name; Makes dhcpd set special options for the interface that it is gathering data for, or the interface denoted by the optional ip# argument. The options are: server [inform] Be a DHCP server on the network connected to the interface. Add the word inform if DHCPINFORM requests must be answered for hosts we don't have an address for. relay host Be a DHCP relay to the indicated host. possessive Do not disable the interface if the DHCP lease expires. Useful if the DHCP server of the provider is unreliable, crashing a lot and causing the lease to expire. (Think twice before turning this option on. You have to be absolutely sure that it's the DHCP server that's the culprit and not a flaky network. You don't want an IP address conflict to be your fault.) hostname name Use the given name as our hostname in the DHCP queries. Some sites key on that bit of information instead of a client ID. tag number name type granularity max; Defines a DHCP tag for the given tag number and gives it a name. The name can be used in the configuration file to set tag values when gathering data. The type field can be one of ascii, boolean, ip, number or octet to specify the type of the tag as a simple string, a boolean, an IP address, a number, or a string of octet values. The granularity field specifies that that number of items must be given or a multiple thereof, unless the type is a number, then it is the size of the number (1, 2 or 4). The max field tells the maximum number of items that may be used with the tag, with 0 meaning "unlimited". Three tags, the ones that MINIX 3 really cares about, have been predefined, and there are also a few pseudotags predefined for the static fields in a DHCP packet that one may want to set: tag ? siaddr ip 1 1; tag ? sname ascii 1 64; tag ? file ascii 1 128; tag 1 netmask ip 1 1; tag 3 gateway ip 1 0; tag 6 DNSserver ip 1 0; The file /usr/etc/dhcptags.conf contains tag definitions for all standard DHCP tags. It is wise to include this file at the top of any DHCP configuration file. no tag-name; Removes a tag with the given name from the data gathered at this point. Useful if one host is different from all others, for instance if it doesn't need a gateway definition, because it happens to be the gateway. ascii-tag string; Adds an ASCII tag to the gathered data. The string can be a simple word, or a quoted string. boolean-tag false|true; Set a boolean tag to be false or true. (Encoded as a octet of value 0 or 1. Note that if you prefer to use 0 or 1 instead of false or true then you can define a boolean tag as a size 1 number instead.) ip-tag host ...; Sets a tag that needs one or more IP addresses. The host names are translated as usual. To make it easier to specify netmasks one can use a slash followed by a number, e.g. netmask /27, which is a handy alternative for netmask 255.255.255.224. number-tag number ...; Set a number tag. octet-tag hexdigits; Set an octet string tag. Hexdigits is a series of hexadecimal digits that are two by two used to set the octets. EXAMPLE As an example the DHCP configuration used by the author of this document is included. His network at home consists of a number of PCs, an ISDN router named rhone and a PC named saone serving as router/tunnel to/via a cable ISP. Both the rhone and the saone connect the home net to the network of the Vrije Universiteit, but the rhone is only active if the cable doesn't work. The saone is a DHCP server, and one of the ordinary PCs is a backup DHCP server. Both use the same configuration file, which is added below, with extra commentary introduced by ## at a deeper indent level: include /usr/etc/dhcptags.conf; ## With the help of the tag definitions we can use tags like "DHCPlease". host 130.37.102.64/27 { DNSserver saone darask; host 130.37.102.88/29 { DHCPlease 259200; } }; ## This defines the network 130.37.102.64/27, with netmask 255.255.255.224 (implicit from the network definition). The DNS servers for this net are saone and darask. A smaller subrange of addresses is used as an address pool on the saone, so a lease of 259200 seconds (3 days) is defined. The netmask is still /27, as set by the outer network definition. host 130.37.102.248/30 {}; ## A network of two addresses for routing tests. host saone { option server; option ip1 possessive; interface ip2 saone-net2; DNSserver 130.37.24.3 130.37.24.6; }; ## With the network definitions done we turn our attention to the hosts. Saone is a DHCP server on its main interface. The second interface (ip1) is connected to the cable modem. It gets its address from the cableco's DHCP server, and if that server decides to go deaf then the saone keeps the interface up ("possessive") even if the lease expires. The pseudo IP interface ip2 is set to the IP address of saone-net2, one side of the encrypted tunnel over the cable to a Minix-vmd box at the VU. The DNS servers specified override the default setting for the network, naming two external servers at the VU that know the world. host darask { option server; DNSserver saone; class MINIX 3 { DNSserver saone 130.37.24.3 130.37.24.6; }; }; ## The darask is also a server, the backup for saone on the odd chance that it is unavailable. It uses saone and the external name servers, but only when it is running MINIX 3. When running Windows it only uses saone. client 0:1:1b:a:68:ce darask; # NE2000 client 0:1:1b:a:77:23 burask; # NE2000 #lient 0:0:c0:b0:da:64 burask; # WD8013EWC client 8:0:5a:38:b2:f finiah; # PCMCIA NE2000 client 0:0:c0:3a:12:10 bardelask; # WD8003 #lient 2:60:8c:ab:8a:6d bardelask; # 3C503 client 0:a0:c5:20:9:6d rhone; client 0:1:1b:a:4c:3b saone; # NE2000 #lient 0:0:c0:fb:2:6a saone-net1; # WD8013EWC ## Lastly the ethernet addresses of all the hosts are listed, so that they can be translated to IP addresses. The lines that are commented out are for extra network cards that are currently unused. The last is used to connect to the cable modem, so it's only here because it's nice to have the ethernet address written down somewhere. The host names shown above are translated by DHCP using this /etc/hosts: 604800 %ttl 2419200 %stale 130.37.102.65 darask.kjb.upwind.org 130.37.102.66 burask.kjb.upwind.org 130.37.102.67 finiah.kjb.upwind.org 130.37.102.68 bardelask.kjb.upwind.org 130.37.102.69 roniah.kjb.upwind.org 130.37.102.70 saone.kjb.upwind.org 130.37.102.2 saone-net2.kjb.upwind.org 130.37.102.88 rhone.kjb.upwind.org 130.37.102.89 dyn89.kjb.upwind.org 130.37.102.90 dyn90.kjb.upwind.org 130.37.102.91 dyn91.kjb.upwind.org 130.37.102.92 dyn92.kjb.upwind.org 130.37.102.93 dyn93.kjb.upwind.org 130.37.102.94 dyn94.kjb.upwind.org 130.37.102.249 tst1.kjb.upwind.org 130.37.102.250 tst2.kjb.upwind.org FILES /usr/etc/dhcptags.conf A supplied list of standard tag definitions as per RFC-1533. (Well, the tag numbers and their meaning are standard, the names are made up.) SEE ALSO RFC-2131, RFC-1533, configfile(5), hosts(5), boot(8), dhcpd(8). NOTES The amount of memory dhcpd needs increases with the size of configuration file. MINIX 3 can handle dhcptags.conf and a modest sized dhcp.conf. You have to increase the stack size to accommodate more. (No problem under Minix-vmd, of course.) NOTES Items that are only necessary for a certain host should only be specified for that host. Items for a whole network are best added to a netblock specification. Use class elements for a certain type of host, and macros for exceptions. Try to limit information as much as possibly to those hosts that need it. (Don't go overboard. A MINIX 3 machine won't be bothered by a few NetBIOS tags.) DHCPINFORM requests should always be answered when being a server, but J. Random Sysadmin trying to diagnose problems doesn't like it when little MINIX 3 machines show up in a packet trace unexpectedly. It's best to be inconspicuous on a network you don't own. BUGS There are a few too many subtle mistakes one can make. AUTHOR Kees J. Bot <kjb@cs.vu.nl> DHCP.CONF(5)
NAME | SYNOPSIS | DESCRIPTION | EXAMPLE | FILES | SEE ALSO | NOTES | NOTES | BUGS | AUTHOR