Dynamic Host Control Protocol (“DHCP”) (for IPv4)

Note: This section is about DHCP for IPv4. (For DHCP for IPv6, often called DHCPv6, see: automatic addressing for IPv6.)

RFC 2131: Dynamic Host Configuration Protocol, RFC 2132: DHCP Options and BOOTP Vendor Extensions, and several other RFCs related to some DHCP extensions.

Wikipedia's section on DHCP security says “Although support for” RFC 3118: Authentication for DHCP Messages “is widespread, a large number of clients and servers still do not fully support authentication, thus forcing servers to support clients that do not support this feature. As a result, other security measures are usually implemented around the DHCP server (such as IPsec) to ensure that only authenticated clients and servers are granted access to the network.”
[#dhcprtnm]: Port numbers/names

The most basic DHCP software (DHCP clients, DHCP servers, and DHCRelay) uses the same ports as BOOTP. They are described more by the section about BOOTP UDP (and TCP) ports and names. (As a quick note for possible convenient reference: 67 is “bootps” and 68 is “bootpc”.)

IANA does also have some ports reserved for DHCP software: 647 is called “dhcp-failover” and 847 is called “dhcp-failover2”. 2490 is called “qip-qdhcp”. (These other ports might also be related to the DHCP protocol?)

Microsoft Technet: Port Assignments for Commonly-Used Services refers to DHCP port 135 as “DHCP Manager”. (IANA's Service Name and Transport Protocol Port Number Registry refers to this port by the “Service Name” of “epmap”.)

[#dhclient]: Using a DCHP Client
Some details about the network traffic

For more details about the port names, see DHCP port names/numbers (and UDP (and TCP) ports named after BOOTP).

A DCHP client sends a UDP port request (likely, or perhaps required) that comes from UDP port 68 (which is the port named “bootpc”), to the server's UDP port 67 (“bootps”).

RFC 2131 page 23 (which is in section 4.1) notes, “DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0.”

The client expects a response on UDP port 68 (“bootpc”) to the client's MAC address. (Because the client may not have a clearly available IPv4 address yet, in an act more similar to promiscuous mode than following standard IP handling, the destination IP address of that packet may be something that is not really paid attention to (by the DHCP client). This is mentioned with RFC 2131 page 11.)

However, support may vary. E-Mail list “dhcp-users” archived message from 2006-Oct-28 6:55:07 discusses problems when using a source port of 1. (The article also mentions a destination port of 67, although a destination of 68 would make more sense for clients to be receiving.) The article says, “Many Windows client don't seem to like this offer because of the source port of 1 and just drop the packet, issuing another DHCP Discover.”

In Unix
Using DHCP on one network card

If the goal is simply to run DHCP on a single network card, one time, immediately, then try just running dhclient as an administrator. (See running a program as an Administrator.)

Using DHCP on a single NIC each time the system starts

Find the name of the NIC.

The most common method to change the long-term configuration of a network card is to modify a text file which gets processed by the /etc/netstart command. The full path of the text file used to configure a network card starts with “/etc/hostname.” and is then followed by the name fo the name of the network interface. (It is because the filename includes the name of the network interface that an earlier step is to find the network identifier of the network.)

To re-hash that, using a hypothetical interface name of “if0”, the full path of the relevant would be /etc/hostname.if0 (so, a network card with an interface identifier called ne3 would generally be configured with a filename such as /etc/hostname.ne3).

The following two lines, customzied so the correct network interface is referenced, can generally be used to set up the network card to be available using an address obtained with IPv4 DHCP.

echo up | sudo -n tee -a /etc/hostname.if0
echo dhcp NONE NONE NONE | sudo -n tee -a /etc/hostname.if0

To make a long story short, the system ends up running something like the following on detected network cards:

/etc/netstart if0

This sort of script may also be called at other times: perhaps by Files used by apmd for OpenBSD/i386?

For full details of the potential contents of this text file are documented by the man page for OpenBSD's /etc/hostname.* files, which can be used by looking up the manual page for “hostname.if” (either on the web page, or by running “ man hostname.if ”. One of the syntaxes offered by that man page is to start a line with !. The rest of the contents will be executed in a shell that has some variables set. For example:

echo \!echo Now setting up \$if... >> /etc/hostname.if0
[#dhconics]: Using DHCP client on multiple NICs

This can be done. However, the default behavior can be a bit disruptive, so there may commonly be a need to change default behavior before deploying this.

By default, each time a client obtains a lease (possibly including renewing a lease), the DHCP client software may decide to update system-wide settings that it figures out based on the conversation with the DHCP server. Therefore, system-wide settings such as default routes and available DNS servers may be entirely overwritten. It is possible that these system-wide settings may be written by invalid information (such as saying there is no valid DNS server available). This may happen even if valid information had been obtained earlier (possibly by DHCP client software that runs on the same system and uses a different NIC). Even if the settings get fixed after they get broken, the DHCP client software may re-break the settings whenever it renews its lease. This default behavior may be quite chaotic. It would seem that the basic design was made assuming that only one NIC would have settings automatically assigned.

One solution may be to make sure that identical information is provided by every single DHCP server that the computer might use. However, there is another user: change the behavior of the DHCP client software so that the client software isn't using this limiting default behavior.

To proceed with that latter option, find the configuration file for the DHCP server, which might be dhclient.conf and might be located in /etc/.

(These directions may still need to be tested...)

First, cd to the location where there is a copy of the dhclient.conf file. Then create a new custom file. The file could be named something like “dhclimy.cnf” or “dhclicustom.cnf”, but perhaps even better is to name it after the network interface.

If this is not being done in /etc/ then superuser privileges may not be strictly needed to copy the file. (The file is readable by all users.) However, superuser privileges will be needed by the time that the file is effectively being created. Therefore, from here on out, this documentation is going to assume the configuration file is placed in /etc/ and is therefore going to use sudo when making further modifications to the file.

sudo -n cp /etc/dhclient.conf ./dhclif0.cnf
echo initial-interval 1\; >> ./dhclif0.cnf
echo 'send host-name "myNicName"\;' >> ./dhclif0.cnf
echo request subnet-mask, broadcast-address, routers, domain-name, | sudo -n tee -a ./dhclif0.cnf

The next section depends on whether or not the subnet is expected to provide valid information about a DNS server. If so, use:

echo '\tdomain-name-servers, host-name\;' | sudo -n tee -a ./dhclif0.cnf
cat ./dhclif0.cnf

If the network interface being configured is expected to get a valid IP address, but will not be getting valid information about what DNS servers to use, then leave off the reference to “domain-name-servers, ”.

The reference to \t is to cause the shell to output a tab character. The desired text, as it should appear in the text file, should be:

initial-interval 1;
send host-name "myNicName";
request subnet-mask, broadcast-address, routers, domain-name,
domain-name-servers, host-name;

(If for some reason the text in the text file does not match what was intended, fix this using a preferred method to edit a text file.)

It might be true that the “request” command line then refers to DHCP “options”.

It is possible to have the DHCP Client adjust network settings using information in this text file, instead of using information that is obtained by any DHCP server that was contacted by the DHCP client. This may or may not be desirable; if it is, here is how to do it:

echo "supersede domain-name-servers;" | sudo -n tee -a ./dhclif0.cnf
echo 'supersede domain-name "lcl.example";' | sudo -n tee -a ./dhclif0.cnf

(lcl.example represents the name of a private domain that was used.)

Then, make sure that the DHCP client uses this text file when it is being used on that interface. (This process involves editing a text file.) In OpenBSD, this means not using a line starting with DHCP in the relevant /etc/hostname.* file. Instead, the text to use may be something like:

!dhclient -c ./dhcl$if.cnf $if

Naturally, if the custom text file was placed somewhere else, either move the text file (which might require superuser permissions) or specify the different location fo the text file.)


the dhcpcd software also looks promising. It has a nice license. (The page says “dhcpcd is released under the 2 clause BSD license.” The hyperlink goes to the web page for FreeBSD's license.) ArchLinux page for dhcpcd says, “It is currently the most feature-rich open source DHCP client”. LinuxQuestions: dhcpcd shows some dated information. http://wiki.linuxquestions.org/wiki/Dhcpcd#Distribution_Specific_Information mentions, “Debian, Red Hat, and most of their derivatives prefer dhclient over dhcpcd. Slackware uses dhcpd by default, although it does come with dhclient.”

LinuxQuetions Forum: dhclient vs. dhcpcd indicates that sometimes one of those pieces of software works better, and sometimes the other.

Is mentioned by: The Linux Documetnation Project: DHCP.
In Microsoft Windows
Using the GUI

In Windows 95, 98, ME, and other operating systems, DHCP can be set up using the graphical interface through the control panel. (For details on how, see: network control panel applet.

Once there, find the icon related to the desired connection. Access its shortcut menu and choose “Properties”.

Choose “Internet Protocol Version 4 (TCP/IPv4)” On operating systems that pre-date (Vista? IPv6 support? the name will be different.

If it is desired to use DHCP to assign a single IPv4 address, then choose “Obtain an IP address automatically”.

Using the command line utility to set an address
Using netsh

If using Windows 2000, XP, or newer, one may have netsh available.

C:\>netsh interface ipv4 show interfaces

Idx  Met   MTU   State        Name
---  ---  -----  -----------  -------------------
  1   50 4294967295  connected    Loopback Pseudo-Interface 1
 10   20   1500  connected    Local Area Connection
 11   10   1500  disconnected  Local Area Connection 2

C:\>netsh interface ipv4 set address name="Local Area Connection" source=dhcp store=active



  • In the above command line, the interface name and the surrounding quotation marks could be replaced with a numeric interface identifier (probably, untested).
  • In Windows Vista, the netsh command line that sets the IPv4 address may show an error (just above the two blank lines that are printed out), which is a single simple sentence: “The requested operation requires elevation.” If this is seen, see: User basic operations: Handling User Account Control from the command line.
  • The example above does not change the long-term configuration, but only the immediate configuration being used. When the system reboots, the changes will be lost. To make the changes take affect long term, simply change “ store=active” to “ store=persistent”. Or, since store=persistent is the default, simply remove the entire reference to store= (and the next word, which comes right after the equal sign), and the change will take effect long term.
Using WMI

First, find the index:

WMIC NICCONFIG WHERE IPEnabled='True' GET Index,Caption

Then, customize the Index number (to specify which NIC to set), IPv4 address, and subnet size (specified via IPv4 “subnet mask” notation).

Renewing an address
ipconfig with /release and /renew options. Windows 95 does not have ipconfig but Win9x does have WinIPCfg which has release and renew options.
[#dhcpd]: Setting up one, or multiple, authorized DHCP servers
Some details about the network traffic

For more details about the port names, see DHCP port names/numbers (and UDP (and TCP) ports named after BOOTP).

A DHCP server listens on UDP port 67 (which is the port named “bootps”). (These incoming messages are likely, or perhaps required, to come from UDP port 68 (which is the port named “bootpc”).

If the server receives traffic from a DHCP client, the server's response (to a DHCP client) will be on UDP port 68 (“bootpc”), and will be sent to the client's MAC address. (Because the client may not have a clearly available IPv4 address yet, in an act more similar to promiscuous mode than following standard IP handling, the destination IP address of that packet may be something that is not really paid attention to (by the DHCP client). This is mentioned with RFC 2131 page 11.)

If the server receives traffic from a DHCP Relay, then the server provides the necessary information to the DHCP Relay. This information might even be routed, using normal IP routing behaviors. Such traffic may be normal UDP/IP traffic (without weirdnesses that may be seen in traffic sent directly to a DHCP client, like not having a normal/correct IP destination address).

Here is some information about implementations:


This section does not have extenstive details. (For now, see the section on using OpenBSD's DHCPd software, as that software is likely to be similar.)

ISC... or not ISC?
Evidence to suggest that OpenBSD's DHCPd server is ISC
Why OpenBSD's DHCP is discussed separately from ISC's DHCP

There are software packages for ISC DHCP software. (For instance, they are listed on a web page showing OpenBSD/i386 4.6's packages.) Also, Calomel.org's guide to using DHClient discusses “the native version of dhclient that comes with OpenBSD. OpenBSD's version of dhclient is very secure, but does not have all of the options of the Internet Systems Consortium, Inc. (ISC) version of dhclient everyone else uses; the option "-r" for release for example. For this reason we will need to download the latest version of ISC's dhclient” software (if/when following that guide that is being quoted).

The OpenBSD Manual Page for dhcpd: section titled “Authors” states, “The current implementation was reworked by Henning Brauer”, and the manual page then shows Henning's E-Mail address at the OpenBSD DNS domain. So, there is no doubt that the OpenBSD team has customized this software. A post by Henning Brauer indicates he whacked at “the dhcp code to make it readable and do privilege drop” and other things. Another item that he mentions doing is that he “fixed its logging”.

Kliment Andreev' blog about ISC DHCP on OpenBSD 4.2 states, “The original DHCP server that is provided with OpenBSD is a custom build based on ISC DHCP v2.” That blog mentioned ISC DHCP server version 3.0.4p0; since then ISC has released newer code (including at least ISC DHCP version 4). So OpenBSD's version has been working with some old code for a long time, while lacking DHCPv6 support and probably also lacks support for features like Failover and Dynamic DNS.

Historical notes
[#dhciffil]: Historical note: dropped support for the unneeded /etc/dhcpd.interfaces configuration file

Versions of OpenBSD prior to version 4.4 may have a /etc/dhcpd.interfaces file that can list the interfaces. The system startup script, /etc/rc, would then parse the /etc/dhcpd.interfaces and put the names of the interfaces on a command line so that dhcpd would then be able to see the names of the interfaces.

Perhaps somebody thought that process seemed overly convoluted. People can just simply specify the names of the interfaces by including them in the command line. OpenBSD 4.4 upgrade guide: section on /etc/dhcpd.interfaces (and OpenBSD 4.4 changes) mentions that the /etc/dhcpd.interfaces is no longer used in OpenBSD 4.4.

The elusive -q option

Some versions of OpenBSD may have included -q in a default setting for setting dhcpd_flags in the /etc/dhcpd.conf file. However, the option was undocumented (in at least some version that had this option be used by default, probably at least OpenBSD 3.8 and maybe even newer).

A post by Henning Brauer shows that the option had previously reduced unnecessary logging, and a post by Arnaud Bergeron says that now it “should not be used.” (However, there has not been any real particular harm from continued use of this now-useless option.) OpenBSD 3.5's manual page for dhcpd does document the option.

Making a configuration file
An example file

Here is an example of what a final file may look like. (Following the example are sections with details about creating the file more from scratch, and what the individual lines do.) This example is intentionally a bit complicated, showing multiple interfaces and some of the simpler of popular optional features (such as using some of the DHCP “options”).

# (By default, many lines of comments may appear at the top of the file.

option domain-name "myzone";

# Using two example DNS servers
option domain-name-servers,;

# If we wanted to use more...
#option domain-name-servers,,,,,;

subnet netmask { #if0 = main internal (wired) LAN
option routers;
# A subnet does not require a filename for simple/basic
# configurations unless dhcpd is supporting PXE network booting
filename "pxeboot"

subnet netmask { #eth2 = WiFi
option routers;

subnet netmask { #ne3 = DMZ/segregated LAN
option routers;

# The following assigns a DHCP reservation
host systemname_eth0 {
hardware ethernet 52:54:00:12:04:03;
option domain-name-servers,,,,,;
option routers;

# Since the following address range is not being listened to by any of the local
#  network interfaces on this computer that runs the dhcpd server, no traffic
#  coming from a DHCP client will use this configuration. However, a DHCP relay
#  may send traffic that uses this configuration. This configuration
#  is based on version 1.1 of OpenBSD's example /etc/dhcpd.conf (available by
#  OpenBSD's CVSWeb site (section for /etc/dhcpd.conf) and other ways)
shared-network LOCAL-NET {
option domain-name "demozone";
option domain-name-servers,;

subnet netmask {
# This subnet is a pool for the LOCAL-NET shared-network
option routers;

Note: The OpenBSD manual page for the /etc/dhcpd.conf file may have some further details, such as noting that white space may be ignored (specifically, the cited manual page says, “The file may contain extra tabs and newlines for formatting purposes. Keywords in the file are case-insensitive.”

It is not necessary required that the host section have its own line to define routers. That line sets the default gateway. The host which is the default gateway for other machines will likely be needing a different default gateway than what is being handed out to other machines. In that case, that host may be provided its own customized value.

Gathering some pre-requisite knowledge

If all of this is too difficult to remember, then make notes as needed. This information may/will be needed when creating the configuration file.

Knowing the DNS server(s) to use

First, (before going into a text editor to start changing the configurations), figure out the nameserver IP addresses that clients should use. Chances are that the nameservers useful for other computers will be the same nameservers that serve the machine that provides the automatic addressing services. (To figure out the nameservers that are being used by a computer, see the section about seeing the local DNS server settings.)

If the DNS server listed is a loopback interface (IPv6 ::1 or IPv4 127/8, most commonly then that address probably should NOT be what gets handed out. (Instead, using a non-loopback IP address for the server may work well.)

If there are no internal DNS servers yet, then it makes sense to just use some known publicly usable external DNS servers to help some basic Internet functionality work. (Those settings should then be modified to use a local DNS server after a local internal forwarding DNS server gets set up.)

(If this is a computer that runs virtual machines, the computer might use external DNS servers so that the machine regularly has working DNS even if the virtual machine is not actively reachable. Setting things up in this way may/will prevent the host machine from being able to use internal domain names. If this is how things are set up, then chances are that other client machines on the network will be better off using a local virtual machine for DNS, instead of the DNS servers used by the operating system of the computer that runs the virtual machines.)

Know what IPv4 address the traffic is going to arrive from

This refers to a local IPv4 address assigned to a local NIC. If this dhcpd server is going to be listening to traffic on a NIC named eth0 then note down ALL the IP addresses that eth0 is using.

Know what addresses need to be handed out

Next, know the subnets that this dhcpd server is supposed to provide services for. (So if dhcpd is supposed to hand out addresses from the IPv4 subnet using the netmask, know that subnet address and netmask.)

Next steps for preparing to edit the file

Back up any existing configuration file before it gets modified. The default file is likely to be called dhcpd.conf and in OpenBSD this file is located in /etc/ (by default). An example command to back up the file (using the program described in the section about copying files to back them up):

[ ! -f /etc/dhcpddef.conf ] && sudo cp -i /etc/dhcpd.conf /etc/dhcpddef.conf
sudo cp -i /etc/dhcpd.conf /etc/dhcpddef.conf
cpytobak /etc/dhcpd.conf

Edit a text file, specifically the file called dhcpd.conf which may be in /etc/.

Presumably the text editor will show a copy of the file. If these instructions are being viewed when online, but without an initial copy of the file handy, then note that the contents are available online. To view a copy of the original (non-customized) file that came when installing the OpenBSD operating system, one may see OpenBSD's example /etc/dhcpd.conf file (latest version from CVSWeb).

Any lines that are not needed may be commented out and/or removed.

About “shared-network” (as seen in an older example)

To simplify things: for a basic setup (especially, for example, when serving just one unqiue subnet for each NIC), make sure that any line that says “shared-network” is commented out. If the line has a left curly bracket/brace, be sure to also comment out an appropriately paired right curly bracket/brace.

For anyone interested in why these lines are being commented out, here are a bit more details: OpenBSD's example /etc/dhcpd.conf file, version 1.1 showed an example with a reference to “shared-network”. The CVS log for OpenBSD's /etc/dhcpd.conf file, in the section for revision 1.2, correctly noted that this example was prone to cause some confusion. If this is seen, note that it is not needed for basic examples. It is probably best just to comment out such a line (and the matching right curly bracket/brace).

Just to describe what the shared-network is: from what I've been told, the shared-network section makes it so that all pools in that shared network are equivilent, meaning that if addresses run out of the first pool available for a NIC, then addresses will be pulled from a different pool in the shared network. Because it would not be good for a machine on one network to get an IP address meant for another network, each NIC's pool of address should not be in a shared-network as pools meant for other NICs (unless those NICs are meant to share a pool, perhaps due to bridging).

One approach to making sure that multiple NICs are not using the same pools of addresses is to have each NIC be placed in a different shared-network section. Another method, which is even more simple (and which is what happens with the newer example file), is for each NIC to simply not be in a shared-network. So, no shared-networks are required.

About being “authoritative

Based on ISC DHCP Server Authoritative Clause and OpenBSD manual page for a /etc/dhcpd.conf file, it appears that using authoritative is generally good for a subnet where a pool is being handed out, as long as DHCP is being used with recommended processes (namely having just one server per subnet, or having servers that communicate with each other in order to share a pool of addresses in a sufficiently cooperative manner) and as long as the DHCP server is authorized for that pool of addresses.

Desired contents of the file

Something should be done with the initial text in the file. Unless the network actually being supported is precisely matching the example configuration's subnet (, then quite a few lines would need to be chaned to be useful. One option may be to alter the pre-existing lines; another may be to make sure they are ineffective (by commenting out the lines, or by removing the lines), so go ahead and comment out anything already there. It might be possible to just leave in the details of a subnet that won't be getting used, without causing an error in the program's functionality, but that would be prone to confusion when someone edits the file at a later date, or if actually does start getting used at a later date. So, make sure those lines are not left active.

Global options

Start by creating lines for some global options (which are not within the boundaries of a section about a specific subnet, nor within the boundaries of a section about any specific “shared-network”). Here are some options that will freqeuntly make sense to be global:

local domain

If a local domain is going to be lcl.example, then a line could say:

option domain-name "lcl.dom"
DNS servers

In all likelihood, the desired domain name servers to use in the long term will be internal servers. That will allow internal domain names to be looked up. However, if such a server isn't started yet, don't hestitate to just go ahead and use one or more known publicly usable external DNS servers. The following example does use such known publicly available usable external DNS servers. So, unlike many examples that are referencing IP addresses, these example lines may be used verbatim):

option domain-name-servers,,,;

Note there is a comma after each name server except the last one, but a semi-colon after the last one. (That syntax is not flexible, so be sure to not leave off the semi-colon at the end.)

Make sections for subnets
Starting the subnet section

When traffic from a DHCP client is received on the system, then a NIC will be used. The traffic's contents may not have an identifiable subnet, because the traffic may just be broadcast traffic. The dhcpd will check which NIC the traffic came in on, and what IPv4 address(es) may be assigned to that NIC, and what subnets those IPv4 addresses are a part of. Then dhcpd will look in the configuration file for a appropriate subnet section.

In the configuration file, options related to a specific subnet come after the configuration file starts a line with the word subnet. After that word will be the details to help identify which precise subnet the remaining options refer to.

This file must have a section for a subnet that contains an IPv4 address assigned to each network interface that dhcpd listens on. So, if dhcpd is going to listen on a device called ral0, and if ral0 has two IP addresses: both and, then making a subnet section for either the (/24, netmask subnet or the (/24, netmask subnet will be sufficient for fulfilling this requirement to listen on ral0. If dhcpd is listening on multiple network interfaces, this requirement must be fulfilled for each interface. Therefore, although one can make extra subnet sections (that will work even if a NIC on this system isn't using the subnet, if a dhcrelay sends a matching sort of request), not having a requried subnet section can be a problem.

Note: Don't expect that dhcpd will be smart enough to accept any IPv4 address in the subnet range, nor the IPv4 address that is on the NIC: dhcpd very specifically wants a network ID.


This may not be technically required, but may still be a good idea anyway. Just before the section containing the configuration options for this subnet, put a description of the subnet in a comment above the line that started the subnet. For example, “internal wired LAN” might be a sufficient description. Simply place something useful just in case someone, perhaps yourself some number of months from now, looks at the file and doesn't remember what the specific range of IP addresses was for. If the DHCP server is listening to multiple NICs, then putting the NIC's name in the command may be helpful (particularly down the road, if/when maintenance gets done on this file).

For example, maybe down the road there is a new laptop that wants to connect to the network (perhaps via a wired connection, or a wireless connection, or both). Decisions that were made months ago, about which subnet was intended for which purpose, may not be instantly intuitive. Documenting the information in this file, while the information and/or its location may still be remembered, may take negligible time now and save time later.

The option for a router(s)

Each subnet should have a default gateway (or a "gateway of last resort" according to some Cisco educational material, or a "Default router" according to the dhcpd.conf comments). By having this, when clients ask for a default gateway, the server will be able to assign the default gateway address for the client to use. (The sensible gateway is going to be whatever router handles the traffic for the range of IP addresses that the DHCP request is coming from. If this dhcpd server is a host OS that is a firewall router, then giving out the DHCP server's IP address is the sensible thing to do. Otherwise, the address given out needs to be whatever other router is used for the specific subnet.) If there is one such router, the syntax can be: "option routers;".

Each subnet should have a set of IP addresses, called the range, that are a part of the subnet. Addresses then get handled out by this range. A lot of network topology designers like to use addresses towards the beginning and/or end of blocks for static addresses. An example for dynamic addresses could be: " range; " (If the subnet is using a netmask of then this would still leave through, and and all unicast addresses with a higher numeric value in the last octet, to be valid to hand out.

To reserve an IPv4 address for a specific MAC/EUI-48 address, first create a section for the machine. This starts out using a line that begins with the word host. The next “word” is a name for this configuration block: a great idea may be to name this configuration block after the computer's name and the name for the NIC. (Those things should be noted: By naming the configuration block after these things, there may be less/no need for another line to contain this info in a comment.) Inside this block should be a reference to the MAC/EUI-48 address, and a record of what fixed IPv4 address to use. Note that the fixed-address that is reserved is part of the subnet but it is NOT part of any of the ranges defined for that subnet. (This is different than Microsoft Windows Server operating systems which may require that the reserved address is part of a defined range, with the expectation that the DHCP server will be smart enough to not use that reserved address dynamically.)

Note: Other information, such as a unique domain name server, could be handed out to this specific system. For instance, if this system is not supposed to be dependent on the main nameserver, it could have a different set of nameservers used. (If most systems are using public external DNS servers, but if that will soon be changing for most systems, placing redundant information in this section could help this section to use public external DNS servers even after the internal DNS servers are launched.) To do this, simply put an “option domain-name-servers” line within the host block.)

Although the specified host name may be required, there may be much less importance to exactly what name gets assigned. (The name might be able to be just about any possible valid name without causing communications troubles.) (Speculation: perhaps that is less true when DHCP is interacting with a “dynamic DNS” implementation?) In this example, the virtual machine's name is firewall and the NIC being configured will be called if0 (for the example... it will likely have a different name such as eth0 or em0 or ne3. Details may be in the section about finding the names of available NICs).


Optional: If a filename is going to be provided for network booting, then specifying a filename may be done in this file.

filename "pxeboot";
[#odhcftst]: Testing the configuration file (OpenBSD's DHCP/IPv4 server, and also ISC DHCP)
Simpler (for OpenBSD's built-in DHCP/IPv4 server)

The following may be an easy way to test the configuration file before actually starting to listen to network traffic:

dhcpd -n
echo $?

If the output is 0 just the number zero), then proceed to run the server (if desired).

Lengthier overview
Different syntax for different implementations

This is one way that OpenBSD's DHCP server differs from ISC's DHCP server. With OpenBSD's DHCP server, run:

dhcpd -n

With the ISC DHCP server, the equivilent command is to run:

dhcpd -q -4 -t

With either implementation, follow up by running the following as the next command:

echo $?

Hopefully that will return zero (“0”). If it returns a value of one (“1”), be sure to check out the contents at the end of /var/log/messages (or perhaps the /var/log/daemon file).

If any changes are needed, run date before re-running the test. (The point to running date is to show a time-stamp. Make a temporary but accessible note of the time that it shows.) That way, if there appear to be troubles, the log entries can be compared to that time-stamp to help separate out older log entries from newer ones.

Running the DHCP server

OpenBSD's /etc/rc file specifies that, prior to running the server, the computer should run:

touch /var/db/dhcpd.leases

This is done before running the server. (This might simply be a way to make sure the file exists, creating a zero-byte file, just in case that ends up being needed.)

Finally, to run the server, just run:


There is typically no need for other command line parameters, although others may be available. For instance:

/usr/sbin/dhcpd -c /etc/dhcpd.conf
Troubleshooting DHCP

Feel free to use normal troubleshooting techniques, like making sure that other types of communications work. Firewalls could, at least in theory, be blocking the specific traffic that is being used. Especially if DHCP Relay is being used, make sure that the return traffic will get routed to where it needs to go.

If one is having troubles with the DHCPd software not seeimg to work as desired, check /var/log/messages (which has been known to have information like not being able to listen). If that fails, check /var/log/daemon which may have more information. Examples of some text found int hese files:

Found in /var/log/daemon
May 29 13:22:02 hostname dhcpd: Can't listen on tun0 - it has no IP address.
May 29 13:27:08 hostname dhcpd: DHCPREQUEST for from 01:23:45:67:89:01 via tun0
May 29 13:27:08 hostname dhcpd: DHCPACK on to 01:23:45:67:89:01 via tun0
Found in /var/log/messages
May 29 13:22:02 hostname dhcpd: Can't listen on tun0 - it has no IP address.
Microsoft's DHCP Service

See: Microsoft's DHCP service. (Some information has been moved from this location to that section.)

Other options
A server for DHCP, DNS, TFTP, and Syslog server; and TFTP client.
for Linux and Windows
Dual DHCP DNS Server
GPLv2. The SourceForge project page identifies this as having many features, including being for Windows and Linux. However, an icon suggests there is also compatability with at least FreeBSD.
Open DHCP DNS Server
Supports having multiple instances that share a database, providing load sharing and redundancy. For Windows and Linux, GPLv2.

JDHCPD (JDHCPD project) is written in Java, and is GPv3. Softcab (Win32/Win64) is available for purchase.

Cisco IOS

Cisco equipment may have a DHCP server that can be configured with the IOS CLI. The following section provides detials on how to set up the DHCP server software that is built into the IOS image. Note that additional steps, such as assigning an IP address, may be needed. This is typically not the first thing that is set up the first time that the device is logged into. (The login commands are just to help provide a starting point of reference.)

Create a DHCP pool and, while doing so, give the pool a name.

The following might be meant for IPv4 specifically.

deviceName#conf t
deviceName(config)#ip dhcp pool customPoolName

In addition to creating a pool and assigning the name, this also changes the prompt.

Specify a network, and then a prefix length. Some versions of IOS support CIDR-style prefix lengths, but IPv4 subnet masks may be a bit more widely supported.


Routing: this sets the “default gateway” router address that will be used by DHCP clients. (This address needs to be in the same subnet as the address that the client gets assigned.)

Specifying DNS server(s)

Set the IP address(es) of DNS server(s). (See usable DNS servers for publicly-available servers.)


Some documentation by Cisco had indicated that up to 8 DNS servers may be specified, although an IOS image used in Packet Tracer did not seem to want to accept more than one such address. (The IOS images in Packet Tracer may be simplified IOS images, though, and so this does not necessarily mean that any real physical products would have the same limit.) Some documentation also showed the command as being “dns server” (without a hyphen), but the hyphen was found to be necessary in a Packet Tracer image. (So either Cisco's documentation was wrong, or there may be differences in IOS images. The documentation being referred to is CCNA Discovery 4.0 module 2 (“Working at a Small-to-Medium Business or ISP”) Configuring DHCP Services.)

Specifying a router

Specify a domain name, which may affect DNS lookups (when a relative domain names, instead of a more FQDN, is specified).

deviceName(dhcp-config)#domain-name internal.example

Note: That option does not seem to be available in all versions of IOS. (It was missing from a version found with Cisco's Packet Tracer software. Presumably a workaround would be to use the “option” command. Further details could be found in the section on DHCP options. However, RFC 2132 section 3.17 specifies there should be a length and a domain name. Cisco IOS seems to want an IP address, which does not make sense. Perhaps this is just a limit of an incomplete IOS support by the Packet Tracer variation. IOS images in Packet Tracer may be simplified.)

Optional: Specify lease length
deviceName(dhcp-config)#lease numberOfDays optinalNumberOfHours optionalNUmberOfMinutes


deviceName(dhcp-config)#lease numberOfDays optinalNumberOfHours optionalNUmberOfMinutes

or, there is one alternate possibility. (Presumably that sets the lease time as described by RFC 2131 section 3.3.)

deviceName(dhcp-config)#lease infinite
Excluded addresses

This is probably most convenient to configure last.

All addresses may be handed out, except for those that are excluded. (The following is technically optional, as there is no strict requirement to exclude addresses. Presumably, though, the default gateway should be part of excluded addresses?) e.g.:

deviceName(config)#ip dhcp excluded-address firstExcludedIP lastExcludedIP

Or, to show that that really looks like a bit better:

deviceName(config)#ip dhcp excluded-address

The observant may notice that the prompt shown has changed: prior commands were shown as being at the deviceName(dhcp-config)# prompt, but this is shown as being at the deviceName(config)#. Well, the command can actually be entered in either location, but if the command is entered at the deviceName(dhcp-config)# prompt, then the prompt will change to a deviceName# prompt after the command is completed. So this effectively exits back to global configuration (terminal) mode.

Once exited back to global configuration mode, the other DHCP commands do not work until re-entering the mode (which requires using the command that specifies a specific dhcp pool). There may be no need to go back into the deviceName(dhcp-config)# prompt, but if there is, then knowing the name of the DHCP pool seems to be required. (Of course, viewing the configuration is a way to show the name of that pool.)

deviceName#conf t
deviceName(config)#ip dhcp pool customPoolName

After all is set, view config:

deviceName#sh run

(That last command is the same as “ show running-config ”)

[#dhcrelay]: DHCP Relay
(This section may have a lot of overview. This is largely because this section's text came from multiple versions of this guide, and the text from these different versions may not have been fully consolidated yet.)

To implement automatic addressing, one option is to use multiple automatic addressing DHCP servers. An automatic addressing DHCP server can run on each link/segment/subnet. By running a DHCP Relay agent, the software that responds to the DHCP client needs to communicate across the network to get the DHCP configuration details from a DHCP server. Wouldn't it just be simpler if the software responding the DHCP client was a DHCP server that had all the DHCP configuration details, so that the software could then immediately provide the needed details directly to the DHCP client? This could result in lower overall network bandwidth, faster response times, and less fragility caused by having multiple pieces.

The answer to that arguement is: Yes, it is true that multiple automatic addressing servers can be deployed around the network. Using a DHCP Relay agent is simply another option. The DHCP client shouldn't really notice any difference. (The DHCP server does, but that's okay.) There are some nice things about using the DHCP Relay method.

One advantage to using the DHCP Relay method is that a lot of the details, like which exact addresses may be handed out for a machine to use, and which nameservers to hand out, can be stored in just one location: the configuration of the DHCP server. This way, when a new pool of addresses is needed, a person may adjust the DHCP server's configuration, and might only need to adjust some parameters (like the pool addresses). Other details, like what nameservers are available, may already be configured on the DHCP server, with little to no effort needed to set up those details.

Another reason is that the configuration required for a DHCP Relay may be simpler. As there may be various types of devices that provide the service of routing traffic, there may be multiple DHCP implementations. Using a DHCP Relay may be easier than trying to set up a DHCP server and figuring out how to set up all the details like what nameserver is getting used. Using a DHCP Relay may involve less custom configuration, which means less work needed if the device needs to be replaced (due to breaking unrepairably, or due to being replaced by newer technology). If there are multiple links, this means that running many DHCP Relays may involve less fussing than using many automatic addressing servers. Deploying twice as many routers, for the purpose of redundancy, could involve deploying twice as many DHCP Relays, which may be less effort than needing to deploy twice as many DHCP servers.

Finally, automatic addressing should take up only a tiny amount of bandwidth, especially compared to the type of network traffic that usually takes up more bandwidth (such as content from web pages).


(This is older text, and may be redudant with the overview in the section about running the agent.)

A DHCP Relay listens for (unroutable) DHCP traffic from a DHCP client. If such traffic is received, then the DHCP communites to a DHCP server, possibly by routing traffic. The DHCP server then communicates information back to the DHCP Relay. The DHCP Relay then communicates with the DHCP client. Throughout a standard implementation of this process, the DHCP server can tell that the traffic is coming from a DHCP Relay agent. The DHCP client may not be able to tell that traffic coming from the DHCP server is going through a DHCP Relay before it reaches the client.

RFC 2131 notes that a BOOTP relay agent may serve to relay DHCP messages. Despite the fact that the UDP and TCP port numbers tend to have names reflecting BOOTP, the name of software that acts as a BOOTP agent may have a name that focuses on its ability to relay DHCP messages. For example, some software that performs this task is named dhcrelay. (There may/should be, or definitely-is??? no practical difference between software serving as a BOOTP BOOTP relay and software serving as a DHCP relay). However, see also RFC 3046: DHCP Relay Agent Information Option, which may have updated this.

Other RFCs cited by OpenBSD's man page for dhcrelay include RFC 2132: DHCP Options and BOOTP Vendor Extensions (an RFC which has been updated by multiple other RFC documents), and RFC 3456: Dynamic Host Control Protocol (DHCPv4) Configuration of IPSec Tunnel Mode.

Network traffic (more overview)

A server should be able to tell the difference between a DHCP relay and a DHCP client's initial request. First and foremost, it appears (verify this is being read correctly???) that a relay agent will identify itself in the “giaddr” field of the DHCP traffic. (This field uses bits # 193 through 224 as shown by RFC 2131 (DHCP): page 9, and the fact that giaddr is related to relay agents is shown on page 10.) Besides that, an additional reason is that traffic from a DHCP relay will be forwarded using standard IP rules, coming from a clear address. In contrast, traffic from a DHCP client may come from IPv4 and be sent to a broadcast address. The server needs to know how to craft the response. So, although a DHCP client may not have any reason to be able to detect that it is being handled by a relay, the DHCP server does have a reason to realize this and most certainly can realize this.

E-Mail list “dhcp-users” archived message from 2006-Oct-28 6:55:07

Running the DHC Relay agent

In order to run DHCRelay on a subnet, the machine needs to have a NIC which has an address on the subnet. By running DHCRelay, the machine will listen for broadcast traffic on that NIC. The machine will then use one of its own IPv4 addresses as the “source” traffic, and send an appropriate request to a DHCP server.

This server will realize that the traffic is coming from a DHCRelay agent. The DHCP server then replies to the DHCRelay agent. Note that the communication between the DHCRelay agent and the DHCP server are happening between computers that have established IPv4 addresses, so this traffic may be routed normally.

Once the DHCRelay agent gets the needed details from the DHCP server, the DHCRelay agent will communicate with the DHCP client that sent out the broadcast traffic.

dhcrelay -i if0 DHCPserverNameOrIPv4Address &

It is believed that is accurate. (Using a host name may not have been tested by the author of this text, at this time. This does work if specifying an IPv4 address.)

Trying to use an IPv6 has not been fully tested at the time of this writing. Certainly some older (and possibly current) versions of the server do not handle IPv6.

Modifying the DHCP server configuration

The other piece to configuring this is to make sure that the automatic addressing server has configuration details to know how to respond to traffic from the subnet that is used by the DHCRelay agent.

If the NIC has multiple IPv4 addresses, one consideration is which IPv4 address will be used by the DHCRelay agent when the DHCRelay agent sends its outgoing traffic. This does not seem to be covered by OpenBSD's manual page for dhcrelay. As there does not seem to be any real documentation to indicate which IPv4 address gets used by the DHCRelay agent, if the NIC has multiple subnets, it may be good to make sure the DHCP server's configuration is ready to support any of the subnets that may be used.

Details about changing the configuration of the DHCP server may be covered in the section about DHCPd.


Verify the basics. For instance, see if the logs help. “ ls -lt /var/log/ | more ” may show that /var/log/daemon has been updated. That file may show:

Mon DD HH:MM:SS sysname dhcpd[PID#]: DHCPOFFER on to 12:34:56:78:9a:bc via

The first IPv4 address (shown in that example-ish text) is the address being offered to the client. The MAC address is the MAC address of the client that sent out a request. The other IPv4 address is the address of the agent.

If that sort of line is seen, use network monitoring to verify that the traffic is making it to the machine that has the DHCP server.

If that machine is receiving the DHCP server traffic, and if firewalling is not the issue, check if that machine has any other sort of DHCP server software running. Such software has been known to cause a conflict with a DHCP agent listening on the server port, even if they are using different NICs (and different IPv4 addresses). (This may not be the most desirable long-term solution, but if things work then at least some information has been obtained by the troubleshooting efforts.)

[#dhcpdora]: DORA

Multiple books related to Microsoft certifications seem to have referenced DORA. (Therefore, it seems like that Microsoft may ask about such a term on an examination required to achieve a certification by Microsoft.) DORA is a reference to the fifth letter of the names of four message types. Remembering the acronym (similar to the female name “Dora”) may help to remember the order that the messages are sent. They are mentioned by RFC 2131 page 14. In order, they are:


Sent from client to server. Client asks for a server to provide details.


Server proposes an address for client. In theory, there might be multiple DHCP servers, in which case the client may get multiple offers.


Client lets server know that the client requests to use what server has offered.


Server lets client know that the request is acknowledged and accepted. At this point, the server should not re-use the same IP address, so the IP address that was given out is effectively reserved for use by the client that is using the address.

The client should not be using an address until the server has acknowledged that it is reserved. So, the client needs to receive the DHCPACK.

Note that there are other DHCP messages, such as DHCPNAK.

[#roguedhc]: Rogue DHCP server(s)
Specialized detection tool(s)

Checking for responses: In an elaborate setup, this could involve checking that the response came from a known server. In a simpler setup, this could just be detecting if there are more responses than what was expected, which would imply that even if the legitimate DHCP server won a race this time, that there is a rogue DHCP server that lost the race this time and there should be a message, or better yet a log, or better yet an alert, so that the rogue DHCP server may be identified before it ends up not losing a race to a legitimate DHCP server.

Microsoft's Dhcploc

Dhcploc Overview, Dhcploc Syntax, Dhcploc Examples. This software may not come installed by default, but may be part of the Windows Support Tools for the operating system (and specific service pack) which may come on the operating system CD or be downloaded from Microsoft. (For more information, locate and obtain and install the Service Tools.)

To use this program: Further info is needed to test command line syntax of multiple servers. Once running, pressing “d” causes the program to send DHCP information. Especially if there is more than one offer is shown, be very careful to check whether each response is from an authorized DHCP server. However, even one offer can be a rogue DHCP server causing problems. (The problems might not be competing with a valid DHCP server, but simply providing unwanted information.) Pressing q will quit the program: pressing other keys (including h, but, in practice, other keys also perform the same function) displays some brief help that simply describes the keys just mentioned here.


This option for Unix tragically does not seem to work. (That statement is made based on some quick testing with the OpenBSD package.) This is being mentioned anyway in case its source code ends up being somehow semi-useful for anyone to make a decent solution.

The software appears to be only designed for DHCP/IPv4.

This is also limited in usefulness because it doesn't do a typicaly broadcast request like most DHCP clients would do. Quite a bit of information needs to be specified, rather than being automatically detected. Some of that information is an IPv4 address on the client system, which won't even be available until (dynamic/automatic or manual) address assignment has already been successfully performed.

The general syntax is:

time sudo dhcping -v -c -s -h 01:23:45:67:89:ab

The address after -c is the client system's IPv4 address. The part after the -h is the system's MAC address (also known as a “link local” address, and typically shown by the lladdr portion of ifconfig's output). The address after the -c is the IPv4 address of the DHCP server. (That address probably needs to be non-loopback, because the DHCP server is probably not listening for traffic coming from the loopback address.)

General methods
If monitoring network traffic, the presense may be noticable. (Even if the exact contents of the responses isn't as easy to diagnose, simply seeing how many responses there are is something that can be enlightening.) Another method may be to cause the client to be unable to reach the desired DHCP server, and then have the DHCP client send out a request and see what happens. There may be multiple methods of preventing the client from reaching the desired DHCP server: routing networking traffic is one way. Another method that is likely to technically, functionally work as a way to perform this test is to shut off the DHCP server software temporarily, and then start it up again after the DHCP client has sent a request and had a chance to receive a response. However, this method is technically introducting downtime: Another DHCP client may send a request that fails to get a response if this is done. The impact of that may be minimal: On many networks there is not a need for there to be frequent DHCP requests, and a DHCP client might try multiple times so if the test is performed fairly quickly (assuming that the rogue DHCP server will respond very quickly) and if downtime can be kept very short, a client may not notice any actual problem (and just notice a slower-than-usual response). Whether or not any of this is considered to be acceptable in an organization may depend on the specific requirements that the organization has.
[#dhcpopts]: DHCP Options

For more details about such options, see RFC 2132: DHCP Options and BOOTP Extensions, and for Unix, a manual page called dhcp-options (e.g. OpenBSD Manual Page for dhcp-options).

Some options:

[#dhcopt81]: DHCP Option 81

RFC 4702: “The Dynamic Host Configuration Protocol (DHCP) Client” “Fully Qualified Domain Name (FQDN) Option”

TechNet: Using DNS servers with DHCP discusses the topic. Microsoft's DHCP server software will check for the presense of DHCP option 81. If DHCP is not specified, then Microsoft's DHCP server software will update the DNS's A record and PTR record. (See: DNS.) Windows 2000, XP, and newer DHCP may supply DHCP option 81. In this case, the common approach is that the DHCP is instructed not to provide the DNS server about updating the resource record of RR type “A”. However, the DHCP server will typically not receive the same instructions for PTR records, and so the DHCP will contact the DNS server with information about the PTR records.

Some old/unorganized notes are still available here. These may be merged into other areas.

[#dhcpdbeg] Enable other machines to connect to this one: Enable DHCPd: DHCP server
Has configuration to provides DHCP services for authorized machines (perhaps all of them) in the event that the main virtual DHCP server machine is unavailable. Here are a few examples on when the main virtual DHCP server machine may be unavailable:
  • This will initially be the case when the virtual machine DHCP server hasn't been made yet.
  • This will routinely be the case for two of the virtual machines: The virtual machine firewalling router (that passes traffic to/from the virtual machine DHCP server), and possibly the virtual machine DHCP server while it is still in its startup phases.
  • This can be the case in other events too, such as if the DHCP virtual machine firewalling router is shut down for whatever reason (such as some intentional maintenance including troubleshooting). In such an event, it may be desirable to be able to connect to the host machine and do whatever is planned, including possibly bringing the virtual DHCP server machine back up (possibly, for example, by rebooting the host machine).
Once the virtual machines are running, this machine could decide to simply route the DHCP packets to the virtual DHCP server machine (by using Layer 2 bridging) and allowing that machine to worry about anything more complex.
Backup original files
Just a reminder, before modifying these files, back them up if desired
One can do one of the following:
Copy from existing
  • echo do what is needed and then ; cp /whereever /etc/dhcpd.conf
(or instead of cp, use unzip, or whatever is appropriate.) Note: Even if copying a dhcpd.conf that previously worked, DHCPd won't work properly if the network devices it is listening on aren't using the expected IP addresses.
or make from scratch.
content moved

Note: The following may be old information, implemented by some older versions of OpenBSD? See: dhcp.interfaces file

Decide what interfaces dhcpd may listen on. If I'm remembering this right, DHCP will look at the command line and listen only on the interfaces listed there and in this file, so one may wish to be generous about including an interface in this file. For example, listing tun devices that dhcp requests are likely to come in on, and internal devices that this machine might want to respond to. (Don't include "external" interfaces: Those that connect to the Internet, as one's ISP isn't likely to have any legitimate use for connecting to your DHCP server.)

In fact, maybe the only purpose of this file is for /etc/rc to access it (using /etc/rc's stripcom code located inside the /etc/rc file) (Note: the dhcpd.interfaces may have been mentioned in a DHCP man page. It may be worthwhile to review reference in above paragraph to "remembering".)

DHCPd leases
Actually, I had gotten by without doing this one. (Ran DHCP a few times and rebooted a few times to get things working, but unrelated.) In case it is needed, though: touch /var/db/dhcpd.leases
Allow Internet traffic forwarding, if needed
It might be true that forwarding sysctl entries is needed, in order for DHCPd to really work effectively (even if the daemon is able to successfully run without the forwarding). (It seemed that this needed to be done, but it might have been some WiFi equipment/setup errors that caused DHCPd to not work, so this hasn't been fully verified yet.)
Long term
echo 'dhcpd_flags=""' >> /etc/rc.conf.local
(/etc/rc will put the names of the NICs on the dhcpd command line, based on what is in dhcpd.interfaces)
Immediate effect: Short term

reboot, or kill any running DHCP server processes (dhcpd), and run dhcpd followed by the names of the NICs to actually listen on: dhcpd nic1 nic2 nic3 nic4

One can try using a -q parameter before the names of the NICs (and inserting it between the quotation marks of dhcpd_flags). TOOGAM has been told this causes dhcpd to be quiet, not giving output. In OpenBSD 4.0, dhcpd was quiet anyway, and any sort of error messages had to be viewed in /var/log/messages. TOOGAM thinks the same was true for OpenBSD 4.1 as well. In OpenBSD 4.2, the -q parameter resulted in an error message, unlike OpenBSD 4.0.

Before going to another system and releasing its IP address in hopes that renewing works: Check on the server if dhcpd is running. (" ps -auxw | grep -i dhcpd ") If not, it is likely to give no output to stdio. Instead, cat /var/log/messages to see if there is a clue as to why it did not run. A single missing semi-colon in /etc/dhcpd.conf is enough to cause this. Also, if an interface gets a different IP address than expected, and therefore /etc/dhcpd.conf does not have an IP address for an interface it is listening to, then dhcpd will not work fully. I believe it will actually refuse to run at all in that case.
Test it

Running SSH into a machine might not work if the client does not have an IP address. If dhcpd is running, try getting an IP address from the client.

If this site's instructions are being followed and this is being done for the Host OS computer, then another computer should be able to get an IP address via DHCP and then ssh in via an IP address. Note, however, that access to the Internet won't work until some sort of forwarding/routing is enabled, including DNS.

(The following information may benefit by being merged with the above text...) WIDE notes: http://openports.se/net/wide-dhcp www.openbsd.org/cgi-bin/cvsweb/ports/net/wide-dhcp/pkg/MESSAGE?rev=HEAD;content-type=text%2Fx-cvsweb-markup
BPF requirement

This software may require Berkeley Packet Filter support. Fortunately, it does appear that this support may often be supported by default in modern popular operating systems. (More specifically, OpenBSD 5.0 does, and it looks like BPF support may have been part of the initial source code migrated from NetBSD. Whether it was/is actually enabled for other operating system versions and/or operating systems might be a differnet story.) To see if a kernel probably supports BPF, check whether any BPF devices exist.

ls -l /dev/bpf*

Upon installing this program in OpenBSD, the installation message says, “ensure that BPF support is compiled into the kernel.” OpenPorts.se page for WIDE=DHCPIPv6 says, “To use DHCP, your kernel must be rebuilt with” a line to enable the “Berkeley packet filter” support.

If BPF support is not enabled, it may need to be. OpenPorts.se page for WIDE=DHCPIPv6 gives an example line of “pseudo-device bpfilter 4 #Berkeley packet filter” for the kernel configuration file (/usr/src/sys/conf/GENERIC). A web page (probably about FreeBSD) suggests using “pseudo-device bpfilter N” in a kernel configuration file.

Then, if support was just recently compiled in, make sure that new kernel is being used, and then something like the following may be needed:

cd /dev
for x in 0 1 2 3 4 5 6 7 8 9 ; do . ./MAKEDEV bpf$x ; done
ls -l /dev/bpf*
Modify /etc/services

Chances are that /etc/services may reference TCP ports 67 and 68, but may name them bootps and bootpc. According to the OpenBSD package's installation message, this file needs to have entries that say dhcp.

cpytobak /etc/services
$VISUAL /etc/services

Add these lines (in the expected location, so that they may easily be seen if this file is manually checked at a later time):

dhcps 67/udp # dhcp server
dhcpc 68/udp # dhcp client