V2.10.0.0 released 17/9/2024. All versions update for Windows 32-Bit, Windows 64-Bit and Raspberry. This release includes the following:
The download is available after a donation is made.
Changes how the DHCP Server interprets the requested address submitted from a client.
[Settings] IgnoreRequestedAddress=1 ; Default: 0 (don't ignore)
If IgnoreRequestedAddress is set to 0 (default): The DHCP server will take the requested address from an unknown client into account when selecting an address to offer, matching the requested address as long as it is free and inside the IP pool.
If IgnoreRequestedAddress is set to 1: The DHCP server will ignore unknown clients suggestion on IP address. Leading to the DHCP server not taking the client request for a specific IP address in account when selection an address to offer the client.
This behavior might not be fully confirmative with the DHCP specification and is not recommended in general usage. But might be useful in special cases.
This feature was an added in V2.10.0.0.
V2.9.4.1 released 18/8/2024. This release includes a native Visual Studio 2022 compilation for Windows 64-bit (dhcpsrv64.exe) and an updated version to a common code base for Windows 32-bit and Raspberry.
The download is available after a donation is made.
External scripts are a great way to enhance the HTTP server with specific features. This is supported in the Raspberry Pi Version V2.9.4.0 only, for now.
The external script can be actually any executable, but the most obvious is to run a bash script. Here is an example:
#!/bin/bash echo "<!DOCTYPE html><html><head>" echo "</head><body>" echo "<h2>Hello Script</h2>" echo "</body></html>"
Place this file into your wwwroot folder name it say “script01″ and make it an executable with the chmod command from the command line:
cd /usr/local/etc/dhcpsrv/wwwroot chmod +x script01
It is assumed that the HTTP Server function is enabled and reachable by an url such as http://raspberry. To execute script01 and see the resulting page enter http://raspberry/script01 into the address line of your browser and you will see the Hello Script page. If that is not the case then please check the HTTP server configuration.
In case you don’t want to return HTML code from your script but for example some JSON structure then this can be done as well. This a bash script that returns a JSON structure:
#!/bin/bash
DATA="{\"valid\":true}"
# write to stdout the HTTP response
DATESTRING=$(date "+%a, %d %b %Y %H:%M:%S %Z")
printf "HTTP/1.1 200 OK\r\n"
printf "Date: %s\r\n" "$DATESTRING"
printf "Last-Modified: %s\r\n" "$DATESTRING"
printf "Server: %s\r\n" "dhcpsrv"
printf "Content-Type: %s\r\n" "application/json"
printf "Content-Length: %s\r\n" "${#DATA}"
printf "\r\n"
printf "%s" "$DATA"
As you can see the big difference is that in case of something else than a <!DOCTYPE html>, the full header needs to be included into the output of the bash script. Let’s paste the above into a bash script02 file and make that executable as well with chmod, then your browser will display the JSON output when directed to the url http://raspberry/script02.
The examples so far were HTTP GET use cases. Now let’s take a look at POST requests. POST requests differ from GET requests in extra data supplied from the client app running in the browser. This extra data is usually a list of key/value pairs as they are coming from an HTML form. The DHCP server integrated HTTP function writes that extra data into a temporary file and that filename is supplied as a parameter to the external script. Here is an example on how to deal with that:
#!/bin/bash
saveIFS=$IFS
IFS='=&'
declare -A post
if [ -f "$1" ]; then
# construct the associative array for POST_STRING
POST_STRING="$(<"$1")"
parm=($POST_STRING)
for ((i=0; i<${#parm[@]}; i+=2))
do
post[${parm[i]}]=${parm[i+1]}
done
fi
IFS=$saveIFS
# do something with the post data e.g. ${post["firstname"]}
printf "HTTP/1.1 301 Moved Permanently\r\n"
printf "Date: %s\r\n" "$DATESTRING"
printf "Last-Modified: %s\r\n" "$DATESTRING"
printf "Server: %s\r\n" "dhcpsrv"
printf "Location: %s\r\n" "post.html"
printf "\r\n"
We see two important things here:
We save the above script as “script03″ in the wwwroot folder and call that script from a post request such as in the following example HTML post.html:
<!DOCTYPE html> <html> <head> </head> <body> <form method="post" id="form1"> <label for="firstname">First name:</label> <input id="id_firstname" type="text" name="firstname" p/><br /> <label for="lastname">Last name:</label> <input id="id_lastname" type="text" name="lastname" p/><br /> </form> <button type="submit" form="form1" value="Submit" formaction="script03">Submit</button> </body> </html>
This HTML code presents a form with two entry fields “First name” and “Last name”. Those will show up in the script03 as ${post[“firstname”]} and ${post[“lastname”]} and can be used to perform whatever that script needs to do.
QUERY data is supported as well, as they are supplied as part of the URL such as “http://raspberry/script04?key1=value1&key2=value2″. An enhanced version of script03 (called script04) can make use of the query data as follows:
#!/bin/bash
saveIFS=$IFS
IFS='=&'
declare -A post
declare -A query
# construct the associative array for QUERY_STRING
parm=($QUERY_STRING)
for ((i=0; i<${#parm[@]}; i+=2))
do
query[${parm[i]}]=${parm[i+1]}
done
if [ -f "$1" ]; then
# construct the associative array for POST_STRING
POST_STRING="$(<"$1")"
parm=($POST_STRING)
for ((i=0; i<${#parm[@]}; i+=2))
do
post[${parm[i]}]=${parm[i+1]}
done
fi
IFS=$saveIFS
# do something with the post data e.g. ${post["firstname"]} or ${query["key1"]}
printf "HTTP/1.1 301 Moved Permanently\r\n"
printf "Date: %s\r\n" "$DATESTRING"
printf "Last-Modified: %s\r\n" "$DATESTRING"
printf "Server: %s\r\n" "dhcpsrv"
printf "Location: %s\r\n" "post.html"
printf "\r\n"
The scripts executed this way run with the privilege of the dhcpsrv executable. Usually root privileges in case of systemctl based installation as described here. Handle with care!
Yes, POST requests are supported since V2.9.4.0 on Raspberry Pi version only for now. It works in a CGI like manner and is described in detail here.
V2.9.4.0 released 11/8/2024. This is a Raspberry Version update only for now. New in V2.9.4.0: enhanced HTTP server for Raspberry version to allow external scripts to be called in GET and POST requests.
The download is available after a donation is made.
V2.9.3.1 released 07/08/2023. New in V2.9.3.1: Raspberry Pi OS Version is released. Please see details on how to install and run here.
The download is available after a donation is made and you will find the deb install package for Raspberry Pi OS automatically in your download area.
V2.9.3.0 released 03/12/2023. New in V2.9.3.0: enhanced syntax in IPPOOL to add ranges like 192.168.20.1,5-10. Fixed bug in DHCP Wizard (new V2.6.0.1).
The download is available after a donation is made.
Specifies the time and date format used in balloon messages. The default is %b %d, %H:%M.
[Settings] BalloonTimeFormat= ; Default: %b %d, %H:%M
This feature was an added in V2.9.2.0.
The format supports the following (strftime style) sepcifications:
| %a | Abbreviated weekday name |
| %A | Full weekday name |
| %b | Abbreviated month name |
| %B | Full month name |
| %c | Date and time representation appropriate for locale |
| %d | Day of month as decimal number (01 – 31) |
| %H | Hour in 24-hour format (00 – 23) |
| %I | Hour in 12-hour format (01 – 12) |
| %j | Day of year as decimal number (001 – 366) |
| %m | Month as decimal number (01 – 12) |
| %M | Minute as decimal number (00 – 59) |
| %p | Current locale’s A.M./P.M. indicator for 12-hour clock |
| %S | Second as decimal number (00 – 59) |
| %U | Week of year as decimal number, with Sunday as first day of week (00 – 53) |
| %w | Weekday as decimal number (0 – 6; Sunday is 0) |
| %W | Week of year as decimal number, with Monday as first day of week (00 – 53) |
| %x | Date representation for current locale |
| %X | Time representation for current locale |
| %y | Year without century, as decimal number (00 – 99) |
| %Y | Year with century, as decimal number |
| %z, %Z | Time-zone name or abbreviation; no characters if time zone is unknown |
| %% | Percent sign |
Specify an empty BalloonTimeFormat=, in case no timestamp shall be shown in the balloon message.
V2.9.2.0 released 03/01/2022. New in V2.9.2.0: balloon message shows timestamp of message and the http function now correctly handles utf8 in the URL.
The download is available after a donation is made.
V2.9.1.0 released 01/26/2022. New in V2.9.1.0: speed improvement on DHCP responses and better sync between HTTP and DHCP to support large INI file configurations.
The download is available after a donation is made.
V2.9.0.2 released 07/03/2021. New in V2.9.0.2: fixed error with respect to TFTP dynamic port ranges.
The download is available after a donation is made.
V2.9 released 08/31/2020. New in V2.9: Web-Server has a configuration for URL alias and the new feature SyncServer has been introduced to better support redundancy configurations. See also the FAQ for this.
The download is available after a donation is made.
Specifies the other DHCP server to load data from. This is a new feature in V2.9 and allows to setup redundant configurations for DNS. The idea is when you setup the split scope redundancy, as described in the FAQ, then you need to handle local DNS requests. See the FAQ for more information.
[Settings] SyncServer=other-server:80 ; load data from other-server
In order for this to work you need to configure the HTTP function on the other server. IP addresses or names are allowed optionally followed by a colon and the port number of the server.
Split scope means that you simply run two DHCP servers each with a different IP range. A client asking for an IP address by broadcasting a DHCPDISCOVER message gets two answers. This adds network traffic but is otherwise not creating any trouble. The client will choose one of the answers (mostly the first it got). Once an IP address is assigned then the client will extend the lease by sending the DHCP message by unicast anyway and is therefore only talking to the chosen DHCP server. The client will reinitiate the complete process in case that server is down and does not reply to requests. The beauty of split scope redundancy is, that it only relies on standard DHCP protocol mechanisms. The client will simply get a new IP address from the other DHCP server and will be happy to talk to that server from now on. Another big benefit is that since the two DHCP servers never sync up, they don‘t need to be the same software or software version.
Configuration of server 1:
[Settings] IPPOOL_1=10.0.0.2-200 IPBIND_1=10.0.0.1 AssociateBindsToPools=1 Trace=1 [GENERAL] LEASETIME=86400 NODETYPE=8 SUBNETMASK=255.255.254.0
Configuration of server 2:
[Settings] IPPOOL_1=10.0.1.2-200 IPBIND_1=10.0.1.1 AssociateBindsToPools=1 Trace=1 [GENERAL] LEASETIME=86400 NODETYPE=8 SUBNETMASK=255.255.254.0
Please note that I have chosen a subnet mask of 255.255.254.0 which allows me to have twice as many IP addresses. The two servers are running on two different computers with the IP addresses 10.0.0.1 and 10.0.1.1, respectively. Each serve different IP ranges: 10.0.0.2-200 and 10.0.1.2-200.
The clients can talk to each other and to both servers with no problem, because they are all on the same subnet 10.0.0.1/23 but get IP addresses assigned depending on which server was chosen.
The only thing that needs to be taken care of is to set DNS_0 and ROUTER_0 dependent on your network infrastructure.
In case DHCP server acts as DNS server as well, then one problem exists. A DNS request reaching server 0 can not be fulfilled with data stored at server 1, and vice versa. Therefore, since V2.9 the SyncServer feature has been introduced. Here is the same example as above with the SyncServer feature enabled:
Configuration of server 1:
[Settings] IPPOOL_1=10.0.0.2-200 IPBIND_1=10.0.0.1 AssociateBindsToPools=1 Trace=1 SyncServer=10.0.1.1:80 [GENERAL] LEASETIME=86400 NODETYPE=8 SUBNETMASK=255.255.254.0 [HTTP-SETTINGS] EnableHTTP=1
Configuration of server 2:
[Settings] IPPOOL_1=10.0.1.2-200 IPBIND_1=10.0.1.1 AssociateBindsToPools=1 Trace=1 SyncServer=10.0.0.1:80 [GENERAL] LEASETIME=86400 NODETYPE=8 SUBNETMASK=255.255.254.0 [HTTP-SETTINGS] EnableHTTP=1
Please note that enabling the HTTP function is essential for this to work, because the sync mechanism simply utilizes the same communication as the status web page.
V2.8 released 05/01/2020. New in V2.8: Web-Server Status page is updating live and allows to monitor assigned leases. The old dhcpstatus.xml page is still available, in case browser support is an issue. TFTP allows zero size files. HTTP connection times out after 5 seconds of inactivity.
The download is available after a donation is made.
Specifies the size of the windows UDP receive buffer in KBytes. The default is 64, which should be enough to allow 256 clients to request an IP address at the same time. It should only be necessary to change this in very rare cases.
[Settings] ReceiveWindow=8 ; Default: 64 [KBytes]
This feature was an added in V2.7.
V2.7 released 11/16/2019. New in V2.7: Besides bug fixes, there are the following changes: further speed improvement in answering DHCP requests, new setting ReceiveWindow and all file paths can be specified relative to the INI file location.
The download is available after a donation is made.
V2.6.2 released 3/23/2019. New in V2.6.2: Besides bug fixes, there are the following changes: INI file handling got a big speed improvement, especially in case of many clients requesting an IP address at the same time.
The download is available after a donation is made.
Specifies the maximum size of the trace file (dhcptrc.txt) See also Trace. Once the trace file reached the specified limit in size, it is copied to dhcptrc.bak and a new trace file is created.
[Settings] TraceFileMaxSize=256000 ; Default: 128000
This feature was an added in V2.6.0.
When ReadOnly is set to 1, then no changes to the INI file will be made by the DHCP server. All newly recognized clients will get an IP address assigned but the respective client entry is not created. Which has the effect that the same IP address will be used next time for another client! This might be useful for test labs, that test one device after the other and explicitly want to assign the same IP address to each one.
[Settings] ReadOnly=1 ; Default: 0
This feature was an added in V2.6.0.
All newly created clients will get an entry in the client section Index=n where n is the number of the IPBIND_n. If the same client tries to acquire a new IP address but from a different IPBIND_k interface then the software will recognize that n != k meaning the client section is created from a different IPBIND. In that situation and when DeleteClientsFromWrongIndex is 1, then DHCP server will delete the client entry and create a new one. Please keep in mind that this will work only, when the client section includes the Index=n entry which is only the case after the client has been acquiring a new lease.
[Settings] DeleteClientsFromWrongIndex=1 ; Default: 0
This feature was an added in V2.6.0.
AlwaysUseDefaultIPAddress controls the behavior of the DNS function.
[DNS-Settings] AlwaysUseDefaultIPAddress=1 ; Default: 0
When this is set, then the DNS will always return the DEFAULTIPADDR, when it is set, regardless of the status of the requester and regardless of the existence of the requested name/IP.
V2.6.0 released 10/27/2017. New in V2.6.0: Among a few bug fixes the following new features are added: TraceFileMaxSize is now configurable, the INI file can be made ReadOnly by a setting, the maximum number of IPBIND/IPPOOL increased to 30, client can easily be black-listed by setting the IPADDR to 0.0.0.0, added feature AlwaysUseDefaultIPAddress to the DNS-Settings. The biggest change is the added setting DeleteClientsFromWrongIndex, which fixes a bug when a client moves from one subnet to another.
The download is available after a donation is made.
V2.5.2 released 07/17/2016. New in V2.5.2: Fixed bug in http server to handle paths and filenames with ‘+’correctly and added directory listing. Download here.
V2.5.1 released 09/17/2015. New in V2.5.1: Fixed bug in UseClientID not being observed correctly. Download here.
Controls the behavior of the DHCP Server when offering an IP address to the client. In case of ReserveByOffer=1, the client section is written to the INI file with a lease time of 1 second when answering with a DHCPOFFER message. In case of 0, no INI file entry is made at the time of offering an IP address. Only the actual assignment (reaction to DHCPREQUEST) of the IP address creates a client section. Of course, the lease time is updated upon assignment to the requested lease time.
[Settings] ReserveByOffer=0 ; Default: 1
This was an undocumented feature until V2.5.0.
V2.5.0 released 09/11/2015. New in V2.5.0: Fixed bug recognizing client id and added two more features to the IPSCOPE language: it is now possible to check for client ids and for any option in hexadecimal formation (OPTIONHEX_nnn). Also a new setting ReserveByOffer has been introduced in V2.5.0. Download here.
V2.4.4 released 02/15/2015. New in V2.4.4: Fixed bug in integrated http server with respect to filename with blanks. Url decoding is now supported and allows %20 for blanks in file names. Download here.
V2.4.3 released 01/07/2015. New in V2.4.3: [SERVERS] section now supports the use of relative paths and can hold a display name to show a more meaningful status on the web page.
You can use the IPSCOPE feature, in order to exclude one or more clients from getting an IP address assigned. Assuming you want to exclude just one client with a given MAC address (e.g. 08:00:00:01:03:A1). Here is an example:
[Settings] IPPOOL_1=10.30.99.2-30 IPBIND_1=10.30.99.1 IPSCOPE_1=if(chaddr == "08:00:00:01:03:A1", null, "validdevice"); AssociateBindsToPools=1 Trace=1 DeleteOnRelease=0 ExpiredLeaseTimeout=3600 [GENERAL] LEASETIME=86400 NODETYPE=8 SUBNETMASK=255.255.255.0 DNS_0=10.30.99.1 ROUTER_0=10.30.99.1
This will consider all clients but 08:00:00:01:03:A1 to be a “validdevice”. 08:00:00:01:03:A1 is not.
The term validdevice can be used to configure specifics in the scope section for the devices named by IPSCOPE_1. You can follow up on that by reading the IPSCOPE feature description. There is no need to go into details of that now for excluding certain devices from IP address assignment.
If you want to exclude even more devices then just extent the IPSCOPE setting accordingly:
[Settings] ... IPSCOPE_1=if(chaddr == "08:00:00:01:03:A1" || chaddr == "08:00:00:01:03:A2", null, "validdevice"); ...
Now also 08:00:00:01:03:A2 will not get an IP address anymore.
Please be aware that this feature works only, if the client(s) don’t already have a client section in the INI file. Only new clients (unknown to the DHCP server) will be selected based on the IPSCOPE definition.
The other way to define which client get an IP address assigned is a white-list approach. Here is an example on how to do that based on the IgnoreUnkownClients setting:
[Settings] IPPOOL_1=10.30.99.2-30 IPBIND_1=10.30.99.1 AssociateBindsToPools=1 Trace=1 DeleteOnRelease=0 ExpiredLeaseTimeout=3600 IgnoreUnknownClients=1 [GENERAL] LEASETIME=86400 NODETYPE=8 SUBNETMASK=255.255.255.0 DNS_0=10.30.99.1 ROUTER_0=10.30.99.1 ; white-list of clients that get an IP address assigned: [10-11-12-13-14-15] [10-11-12-13-14-16] [10-11-12-13-14-17] [10-11-12-13-14-18]
Please note that only the four clients listed based on their mac addresses will be served by the DHCP server. The client section does not need to include anything. Simply add more client mac addresses to the list to serve them as well.
The key to this approach is, besides the fact that you need to know the clients beforehand, is to set IgnoreUnkownClients=1. You can add clients to the INI file anytime. And, you can even use wildcards, as described here.
The following example adds all clients 10-11-12-13-14-00 up to 10-11-12-13-14-FF to the (white) list of clients:
... [10-11-12-13-14-??] ...
Launched the new Web presence for www.dhcpserver.de based on WordPress. Makes it easier for me to update and I hope it also makes it easier to read and to navigate. Let me know and drop me an e-mail about it.
The INI file looks like this:
[General] SUBNETMASK=255.255.255.0 LEASETIME=32000000 ; approx. 1 year ROUTER_1=192.168.10.1 DNS_1=192.168.10.1 [Settings] IPBIND_1=192.168.10.1 IgnoreUnknownClients=1 [00-E0-00-1C-AB-68] ; Client 2 IPADDR=192.168.10.50 [00-E0-00-1C-AB-67] ; Client 1 IPADDR=192.168.10.11
Please note the line IgnoreUnknownClients=1. This option prevents the DHCP Server from sending answers to clients that are not configured in the INI file.
The INI file looks like this:
[General] SUBNETMASK=255.255.255.0 ROUTER_1=192.168.10.1 DNS_1=192.168.10.1 [Settings] AssociateBindsToPools=1 IPBIND_1=192.168.10.1 IPBIND_2=192.168.11.1 IPPOOL_1=192.168.10.2-49 IPPOOL_2=192.168.11.2-49
This manages the IP addresses 192.168.10.2 until 192.168.10.49 for Ethernet 1 and 192.168.11.2 until 192.168.11.49 for Ethernet 2. Please note the line AssociateBindsToPools=1. This option associates the IP Pools with the corresponding IP Binds. Without that option the DHCP Server would view all IPPOOL_x as one big IP pool independent of the subnet.
The INI file looks like this:
[General] SUBNETMASK=255.255.255.0 ROUTER_1=192.168.10.1 DNS_1=192.168.10.1 [Settings] IPBIND_1=192.168.10.1 IPPOOL_1=192.168.10.2-49
This manages the IP addresses 192.168.10.2 until 192.168.10.49. The DHCP Server binds only to one NIC with the IP address 192.168.10.1. The other NIC (Ethernet 2) is not touched by the DHCP Server. This is very useful if Ethernet 2 is your company LAN and you don’t want to interfere with it.
This is a very simple example and the INI file looks like this:
[General] SUBNETMASK=255.255.255.0 ROUTER_1=192.168.10.1 DNS_1=192.168.10.1 [Settings] IPPOOL_1=192.168.10.2-49
This manages the IP addresses 192.168.10.2 until 192.168.10.49. But be aware that all clients connected to the subnet 192.168.10.X get IP addresses assigned. Please make sure that you don’t get in conflict with other DHCP Servers.
Define the content types along with the respective file extensions for the HTTP server.
[content-type] .htm=text/html ; Default: -
The http server knows the content-type definitions for .htm, .html, .css, .xsl, .jpg, .png, .gif, .ico, .xml and .txt. Additional file extensions and their respective content types can be specified in the [content-type] section.
Specifying the HTTP log file.
[HTTP-Settings] Logfile=c:\httplog.txt ; Default: -
The http server logs all activities in this file.
Specifying the root for the HTTP server.
[HTTP-Settings] Root=c:\httproot\ ; Default: -
Only files located in or under the given Root path are served by the http server. A Web browser request asking for a file x automatically translates to a file access to c:\httproot\x.
EnableHTTP enables the integrated HTTP Protocol server functionality of the DHCP Server.
[HTTP-Settings] EnableHTTP=1 ; Default: 0
Specifying a default file for error messages (404).
[HTTP-Settings] DefaultFile=showerr.html ; Default: -
The DefaultFile allows to specify a file whose content is returned instead of a 404 file not found message. This is a new feature in V2.3.3. In case the URL refers to a not existing file, then this file is fetched. If DefaultFile is not specified then the regular 404 file not found return occurs.
Setting the TFTP Transfer window.
[TFTP-Settings] TransferWindow=1 ; Default: 4
The tftp-setting TransferWindow sets the maximum number of tftp data packets that are sent before an acknowledge is received. TFTP protocol standard behavior is achieved by setting TransferWindow=1. The default of 4 should increase TFTP performance by about 50%. In case of problems try to set to 1.
Specifying the root for the TFTP server.
[TFTP-Settings] Root=c:\tftproot\ ; Default: -
Only files located in or under the given Root path are served by the tftp server. A tftp client request asking for a file x automatically translates to a file access to c:\tftproot\x.
Allowing the TFTP server to write files.
[TFTP-Settings] WritePermission=1 ; Default: 0
If not set or set to 0 WritePermission is not granted. Tftp clients can not write files in this case.
The PortRange setting defines the ports the TFTP server will use for sending and receiving data.
[TFTP-Settings] PortRange=51000-51100 ; Default: AUTO
The default is AUTO and specifies that the port numbers are allocated automatically on demand as they are made available by windows sockets (winsock). This can be a problem with firewalls, because the port numbers can not be explicitly opened in the firewall if they are unknown at configuration time. Therefore it is possible to specify a range of ports like PortRange=51000-51100. This tells the TFTP function to select port numbers out of the given range for sending and receiving data. Please make sure that the specified port numbers are not confilicting with other network services running on the server.
Controlling the TFTP blksize.
[TFTP-Settings] MaxBlockSize=1024 ; Default: - (whatever the client asks for)
The tftp protocol allows to negotiate the blksize. This is the number of bytes transfered between client and server in each packet. It has been shown that if the client asks for a blksize that is bigger than the MTU, that the tftp communication does not work. Therefore it is since V2.2.3 possible to limit the blksize on the server side. MaxBlockSize should be set to a value between 512 and the MTU.
Enabling the TFTP function.
[TFTP-Settings] EnableTFTP=1 ; Default: 0
EnableTFTP enables the integrated Trivial File Transfer Protocol (TFTP) server functionality of the DHCP Server.
The DEFAULTIPADDR setting is a very simple but effective security feature.
[DNS-Settings] DEFAULTIPADDR=192.168.17.18 ; Default: -
If DEFAULTIPADDR is not set then the DNS server serves everybody as expected with resolved names. If it is set, then requesters with an unknown IP address get always the default ip address as an answer to all name resolution requests. The intention of this feature is to forward all unknown clients to a predefined default address (e.g. a web server with registration facility). Since V1.9.3, this can be also defined on a per client basis. Please see AllowDNSQuery for details.
Please note that the PC running the DHCP server always resolves DNS requests regardless of the DEFAULTIPADDR setting.
Forwarding DNS requests.
[DNS-Settings] FORWARD=192.168.2.1 ; Default: -
The FORWARD setting defines the IP address of one external DNS server that gets all the requests that the integrated DNS server can not answer. This feature is fairly rudimentary and works only with UDP.
EnableDNS enables the integrated Domain Name Service (DNS) functionality of the DHCP Server.
[DNS-Settings] EnableDNS=1 ; Default: 0
Configure a VENDORCLASS.
[Settings] VENDORCLASS=MSFT 5.0 ; Default: -
If a VENDORCLASS is specified as an entry in the [Settings] section, then only clients with the same vendor class defined in their DHCP request get an IP address assigned.
Enabling the Trace.
[Settings] Trace=1 ; Default: 0 TraceFile=c:\temp\dhcptrc.txt
You can switch the trace on by putting a Trace=1 entry into the [Settings] section. The trace file is called dhcptrc.txt and is written into the same folder as the dhcpsrv.exe and the dhcpsrv.ini files. I recommend to switch the trace on, if you encounter any problems and attach the trace file to the e-mail that you are sending to me to report it. If you want the trace to have a different name (and/or directory) then use TraceFile for that. Example:
[Settings] Trace=1 ; 1= enable, 0=disable TraceFile=c:\temp\dhcptrc.txt ; this is where the trace goes
If the TraceFile setting in not set then the default is dhcptrc.txt in the dhcpsrv.exe directory. TraceFile is a new feature in V1.5.2. Since V2.7 you may also use a relative path to specifiy the trace file name. Relative paths are interpreted relative to the INI file location.
Customizing the tray icon.
[Settings] TRAYICON=someicon.ico ; Default: default icon
Since V2.1 it is possible to change the tray icon of the dhcp server. The default tray icon is still avaible as a default. You can either choose “None”, “Default” or a filename.
TRAYICON=Default ; use the built in default icon. TRAYICON=None ; use no icon at all.
To set the tray icon to NONE is not recommended because the process can only be stopped using task manager if there is no tray icon.
TRAYICON=filname.ico loads the given icon file as the try icon.
All this is of course only effective if dhcpsrv.exe is started as an application (not as a service). The intended purposes to choose the tray icon is to bo able to distinguish the processes in the tray in case you are running dhcpsrv.exe multiple times.
Limit the DHCP Server to one instance.
[Settings] SingleInstanceApp=1 ; Default: 0
Since V2.2.3 it is possible to limit the DHCP Server to one instance if run in application mode. If SingleInstanceApp is not configured or set to 0 then the server can be started multiple times. If set to 1 then the second instance will only show a dialog inidicating that it’s a second instance and will terminate after confirming the dialog box.
Customizing the service name.
[Settings] SERVICENAME=DHCP Server ; Default: DHCP Server SERVICEDISPLAYNAME=DHCP Server ; Default: DHCP Server
Since V1.9 the DHCP server supports customizing the service name entries. This is useful when the service is to be installed several times (different INI file needed) or in combination with an already existing DHCP server with the same service name.
Configure the sname field.
[Settings] ServerName=Name of server ; Default: Windows computer name
Since V2.4 it is possible to define the content of the sname (server name) field in the DHCP reply packets. The default is the computer name as it is configured in Windows (return value of Win32 API GetComputerName).
Disabling balloon messages.
[Settings] ShowBalloonMessages=1 ; Default: 1
Since V1.7 the DHCP server shows balloon messages in the tray if run in application mode. This can be disabled by setting ShowBalloonMessages=0.
Enabling advanced features of the relay agent.
[Settings] RelayAgentAdvanced=1 ; Default: 1
Since V2.1.3 this setting allows to alter the behavior of the relay agent. With RelayAgentAdvanced=0, the relay agent runs in a compatible mode and can be used in conjunction with other DHCP servers such as Windows 2003 Server. With the default setting of RelayAgentAdvanced=1, the relay agent adds option 82 to all requests. This allows the DHCP Server to distinguish between the link selection information and the address of the relay agent.
Changing the port number for certain services in the DHCP server.
[Settings] PORT_53=53 ; Default: 53 (DNS) PORT_67=67 ; Default: 67 (DHCP) PORT_68=68 ; Default: 68 (DHCP) PORT_69=69 ; Default: 69 (TFTP) PORT_80=80 ; Default: 80 (HTTP)
These options are new in V1.6.5 and allows to customize the IP ports the DHCP Server is supposed to use. Default is 67 or 68 respectively. Port 53 is the default port for the DNS Server. Port 69 is the default port of the TFTP Server. Port 80 is the default port of the HTTP Server (available since V2.0). If no relay agent function is in use, then this setting has no effect.
[Settings] PacketValidation=0 ; Default: 1
PacketValidation allows to switch off the packet validation routine that filters malformed DHCP requests. Added in V2.2. This setting exists only to bypass a too aggressive validation that falsly identifies correct requests as malformed.
[Settings] PADDING=0 ; Default: 0
PADDING is new in V1.8 and enables to add PAD bytes (0) after each DHCP option, if the next option would otherwise be stored at a non WORD aligned offset. Some older BOOTP clients require this.
In order to enable padding please set PADDING=1 in the [Settings] section.
[Settings] OverwriteBroadcastFlag=0 ; Default: broadcast-flag as set by the client request
OverwriteBroadcastFlag is new in V1.9.1. It allows to overwrite the broadcast flag set by the client. (See also EnableSendRawUnicast setting). The default behavior if this setting is not present or commented out, is to act according to the DHCP specification. If OverwriteBroadcastFlag is present then the behavior is to always broadcast the response (= 0) or to always try to unicast the response first (= 1). If unicast fails, then the DHCP Server defaults to broadcast.
[Settings] ObeyParamReqList=0 ; Default: 0
ObeyParamReqList is new in V2.4.1. If set to 1, then the DHCP responses will only include options that the client requested in his option 55.
The DHCP Server automatically recognizes changes in the IP configuration in Windows. This is done based on the Windows API NotifyAddrChange. This API tells the DHCP Server when an IP configuration is changing. The DHCP Server acts on this by internally shutting down and restarting itself. Upon restart, the new configuration is used. In order to not shutdown and restart unneccessarily the DHCP Server uses a timeout mechanism to delay the shutdown after NotifyAddrChange events.
[Settings] NotifyTimeout=5000 ; Default: 1000 (milliseconds)
The default of this timeout is 1 second (1000 millisends). Some network cards are very slow and require a longer delay before they are actually ready to run. Set the NotifyTimeout value to a larger timeout period to compensate for this.
[Settings] NAKMessage="Info text for DHCPNAK" ; Default: -
Since V2.2.1 NAKMessage allows to specify an info text that is added to DHCPNAK replies as option 56. This info text is visible in some DHCP clients. It is very rarely used and should usually be omitted. Default behavior if NAKMessage is not specified is to not add option 56 in the reply.
[Settings] MINPACKETLENGTH=300 ; Default: 300
This option is new in V1.6 and allows to specify a minimum packet length that the DHCP server is supposed to respond with. Default is 300 bytes. Some clients were not happy with a too short response. The remainder of the packet is filled with 0.
[Settings] IPSCOPE_0=string-expression ; Default: - … IPSCOPE_9=string-expression
IPSCOPE_n defines based on the client request if this scope matches or not. Continue reading
[Settings] IPRELAY_0=192.168.2.1 ; Default: - … IPRELAY_9=192.168.10.1
IPRELAY_x is the definition of the DHCP Server address where the relay agent sends all requests coming in from IPBIND_x. Please see the description in the INI file overview about relay agents to learn more. IPRELAY_x is supported since V2.0.
From version 1.5 on the auto configuration is supported:
[Settings] IPPOOL_0=123.45.56.78-90 IPPOOL_1=123.45.57.0-254 IPPOOL_2=AUTO
The above enables three IP pools for DHCP clients. Unknown clients are automatically configured by adding the appropriate client sections to the INI file. IP pools of size 1 (e.g. 123.45.56.78-78) are allowed and are very useful if you want to assign the same IP address to all clients.
The new feature in V1.8 is: AUTO. If AUTO instead of a numerical IP-Pool configuration is used then the IP Pool is automatically chosen to cover the complete IP Range based on the IPBIND_x IP address and the network mask. This works best together with a name based IPBIND_x configuration.
From V1.9 on the IPPOOL_x numerical IP-Pool definition is enhanced with a comma syntax. This allows to define IP pools such as:
[Settings] IPPOOL_0=123.45.56.78-90,92,94
This adds 123.45.56.92 and 123.45.56.94 to the IPPOOL_0.
Since V2.3.1 it is also possible to define a class A/B network by using IPPOOL_1=10.45.3.1-10.45.5.254. This defines, in accordance with the subnet mask, all IP addresses from 10.45.3.1 through 10.45.5.254 as the IP pool.
[Settings] InstallAsService=2 ; Default: -
This is used internally by the DHCP Server to remember the checkbox “Don’t ask this question again” on startup of the software.
[Settings] IgnoreUnknownClients=1 ; Default: 0
Setting this to 1 tells the DHCP server not to answer to requests from clients that are not configured in the client sections. DHCP requests from unknown clients are declined, if IgnoreUnknownClients is set to 0 (default).
HBA provides a basic load balancing concept according to RFC3074. HBA stands for hash bucket allocation and defines whether the DHCP Server is responsible for a client or not. The HBA consists of 32 hex values separated by a single blank. Every hex number represents eight bits, one bit per hash bucket. The DHCP server calculates a hash value for every client that asks for an IP address. The hash value is between 0 and 255. If the correspondig HBA bit for that hash value is 1, then the client is serviced. If it is 0 then the client is not serviced. Please assume the following example:
[Settings] HBA=FF FF FF FF FF FF 00 00 FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
This restricts the DHCP Server to service clients whose hash value is 0 through 47 or 64 through 127. The server servicing the rest of the clients should have the exact opposite HBA. The HBA logic kicks in only for clients that are unknown (not yet in the INI file) to the DHCP Server. Clients who are already known are serviced regardless of the HBA.
ExpiredLeaseTimeout defines a time value in seconds.
[Settings] ExpiredLeaseTimeout=4294967 ; Approx. 49 days
The mechanism that checks expired leases is triggered by this. Regardless of when the next lease expires, the mechanism is scheduled at least in the time interval specified by ExpiredLeaseTimeout. This is useful when the INI file entries get changed manually and the DHCP server may not be aware of already expired leases. By this, the INI file gets cleaned up cyclically.
The EnableSendRawUnicast setting is new in V1.9.1.
[Settings] EnableSendRawUnicast=0 ; Default : 0
The DHCP protocol allows the client to specify a broadcast flag. If this flag is not set, then the DHCP server is asked to unicast the response. Unfortunatly, there is no standard mechanism based on the winsock programming interface that would allow the DHCP server to send unicasts solely based on mac address addressing scheme. In V1.9.1 the usage of the winpcap library got implemented. In situations where a unicast is required without having an IP address of the client at hand, the wpcap.dll function pcap_sendpacket is used. The EnableSendRawUnicast setting enables this functionality. Please set to 1 only if there are really problems with clients in that situation. Clients actually should be also fine with receiving responses as broadcast, which is the default behavior if EnableSendRawUnicast is not set or the wpcap dll is not installed. This has been tested with winpcap Version V4.1.1. Please also see the description of the OverwriteBroadcastFlag setting for even more advanced options to set.
The Database setting allows to split the dhcpsrv.ini file into two parts. (Available since V1.7)
[Settings] Database=d:\database.ini ; Default : -
Part 1 is for everything in the [Settings] section. This stays in the dhcpsrv.ini file. All the rest [General], [General_x] or client section goes into the Database.ini file. This allows a clean distinction between real settings and configuration for the DHCP server and the IP assignment database in which the client configurations are managed.
New in V1.9.2: If no [General] or [General_x] section is found in the Database.ini file, then the dhcpsrv.ini config file is used for that instead.
If no Database setting is defined, then the DHCP server assumes that the database is part of the dhcpsrv.ini file.
The file name can be specified with relative paths since V2.7. In that case, the path is interpreted relative to the INI file.
Setting ClearClientsOnStartup=1 basically removes all clients from the INI file every time the DHCP Server is started.
[Settings] ClearClientsOnStartup=1 ; Default : 0
This is not recommended in general usage but might be useful in special cases.
Associate the IP pools with the respective IP binds.
[Settings] AssociateBindsToPools=1 ; Default : 0
If the DHCP Server is configured to use more than one NIC with a separate subnet each (see Example 3 in the overview) then this entry associates the IPPOOL_x with the IPBIND_x. The two entries with the same number “x” belong together. Clients on subnet IPBIND_x get IP addresses assigned only from the pool defined by IPPOOL_x.
The default behavior (AssociateBindsToPools=0) is to view all IPPOOL_x as one big pool of IP addresses which can be assigned to any client regardless of the subnet IPBIND_x.
Binding to certain IP addresses (or NIC cards).
[Settings] IPBIND_0=123.45.56.78 ; Default: - IPBIND_1="Local Area Connection" ; name of connection IPBIND_2=192.168.2.1 … IPBIND_9=192.168.10.2
This restricts the DHCP server to bind only to certain LAN connections. All other IP addresses are ignored. This is very important if you want to restrict the DHCP server to particular cards in your computer. You have already two IP addresses, as soon as the computer is on the internet using a dial up connection.
The DHCP server will bind to all IP addresses if no IPBIND_x is found. IPBIND_0 to IPBIND_9 are supported.
Starting with V1.8 the value of an IPBIND_x entry can also be specified as a LAN connection name. These are the names Windows is using to specifiy network connections. In case a name based IPBIND_x is configured, then subnet mask, ip address and all other windows configured data such as DNS server addresses etc. are obtained automatically and don’t need to be explicitly specified in the ini file anymore. See also the AUTO feature in IPPOOL_x.
[Settings] UseClientID=1 ; Default: 0
If UseClientID is set to 1, then clients can be recognized based on their Option 61 specification “client-identifier”. Option 61 allows several client id formats. Two of them are supported by the DHCP Server: type=0 and type=1. Type 1 is treated as the mac address of the client and just uses the mac address given by option 61 instead of the chaddr field of the DHCP packet.
Type 0 is treated as an ascii string. The client section is created with the client identifier instead of the mac address. Also the manual specification of client sections need to be based on the client-idendifier, if UseClientID is set to 1. This option is new in V1.7.
Sometimes there is confusion about IgnoreUnknownClients. There are two settings that control the behavior of the DHCP server with respect to unknown clients: ConfigureUnknownClients and IgnoreUnknownClients. ConfigureUnknownClients controls whether an unknown client gets an entry automatically generated in the INI file based on IPPOOLs and so on. What makes a client a known client is any kind of client section in the INI file. This can be a client section with wildcards. This client section does not need to contain any IPADDR entry. The IPADDR entry is generated automatically. IgnoreUnknownClients controls how the DHCP server behaves in cases in which no client section is generated by the DHCP server. Sent a NAK to the requesting client or simple ignore the request. Example:
[00-40-8C-??-??-??] ; support only clients with mac address starting with 00-40-8C AutoConfig=1 [Settings] ConfigureUnknownClients=0 IgnoreUnknownClients=1
This tells the DHCP server to configure only clients with mac address 00-40-8C-??-??-?? and do not respond to any requests from other kind of clients.
Yes. It automatically uses all NIC’s that it finds and listens for incoming DHCP requests. Windows 2000 (and later OSs) has a little bit of a different behavior than previous Windows operating systems. It doesn’t tell you the IP address of an adapter until it is physically connected. The DHCP server since V1.3 supports that as well by implicitly stopping and starting itself whenever a change in the IP configuration occurs.
You can also restrict the DHCP Server to certain cards by using the IPBIND_x entries in the [Settings] section or server “virtualization”.
Yes. The DHCP server implements the DHCP protocol. And since V1.8 also the BOOTP style requests are supported.
DHCP Server for Windows is not open source and therefore the source code is not available for free.
No. The DHCP server reads the dhcpsrv.ini every time again, when a client requests an IP address.
This is probably the question that I hate the most. Here is what I always do to find out what’s going on: Setup the IP network by hand. In other words: don’t use the DHCP Server, at all. Configure all the necessary things in the network settings of your client machine and don’t set “Obtain an IP address from a DHCP server”. If you have done this and your network still isn’t working there is something very basic wrong, already. There is no hope that the DHCP server is going to help you to solve this problem. Continue reading
AllowDNSQuery goes along with the built-in DNS functionality. A client who performs DNS queries that is not known to the DHCP Server (not in the ini file) can get a default IP address returned regardless of the name it wants to resolve. This is a security feature that limits the DNS function to known clients. Since V1.9.3 AllowDNSQuery defines this behavior on a per client basis. If AllowDNSQuery is set to 1 then the client can resolve names to IP addresses with DNS queries. If AllowDNSQuery is set to 0 then whatever is configured as DEFAULTIPADDR is returned for every name.
Please assume the following INI file:
[General] ... AllowDNSQuery=0 ... [DNS-Settings] EnableDNS=1 DEFAULTIPADDR=192.168.0.1 [00-00-00-00-00-01] IPADDR=192.168.0.10 Hostname=Computer_1 [00-00-00-00-00-02] IPADDR=192.168.0.11 Hostname=Computer_2 AllowDNSQuery=1
In this example, only Computer_2 will be able to resolve DNS queries to the real IP addresses. Computer_1 will observe that regardless of the name he wants to resolve, he will always get 192.168.0.1 in return.
The influence of AllowDNSQuery to the behavior is such that, whenever DEFAULTIPADDR is set, the DEFAULTIPADDR is returned when the requester is unknown (not listed in the INI file) or AllowDNSQuery is 0.
| Case | DEFAULTIPADDR | AllowDNSQuery | Requester | RESULT |
|---|---|---|---|---|
| 1 | SET | 1 | known | resolve IP |
| 2 | SET | 1 | unknown | DEFAULTIPADDR |
| 3 | SET | 0 | known | DEFAULTIPADDR |
| 4 | SET | 0 | unknown | DEFAULTIPADDR |
| 5 | NOT SET | 1 | known | resolve IP |
| 6 | NOT SET | 1 | unknown | resolve IP |
| 7 | NOT SET | 0 | known | resolve IP |
| 8 | NOT SET | 0 | unknown | resolve IP |
It should work with every operating system (not only windows), since the DHCP server implements a standard protocol. Please tell me about the operating systems that you are using and whether it works or not. I will update the list. Continue reading
The reservation of IP addresses usually serves the purpose of excluding IP addresses or address ranges from the IP pool. Mostly, because those IP addresses are already known to be used somewhere in the network and are not to be reused or controlled by DHCP. There are two ways on how to reserve IP addresses. Continue reading
The integrated DNS function resolves names to IP addresses and vice versa based on the same data repository as the DHCP server itself. All information is stored in the INI file. All clients that have been added to the INI file, automatically or manually, can be resolved. Continue reading
Usually, a DHCP option is either an IP address or subnetmask or a string. You can specify all kind of options and option data using the custom option feature of the DHCP server. Continue reading
In the trace file (dhcptrc.txt) you will see the follwing trace entries:
[11/07/2012 07:07:07] DHCP Server is terminating (ignore error messages that follow) [11/07/2012 07:07:07] recvfrom returns with error 10038
This happens every time you terminate the DHCP server. The reason is of technical nature and is by design. There is nothing to worry about, because it is intended behavior.
The reason for it lies in the fact that the DHCP Server software uses blocking sockets as a communication resource. The DHCP Server basically is blocked in a socket call and waits for a request from a client. When you terminate the DHCP Server application, then the blocking socket function call is de-blocked by closing the socket. This then leads to the error message 10038.
First, please check that the HTTP Server is enabled.
[HTTP-Settings] EnableHTTP=1 Root="c:\httproot\" ; the server side pathname to the files served through the http protocol
If the HTTP Server is not enabled, then the “Open Status” entry in the context menu is grayed. The status info is provided as a web page and therefore requires the HTTP Server to be enabled.
If it still does not work, then make sure that the port number 80 is not already used by another HTTP Server running on your computer. You can move the integrated HTTP Server to another port number with the following setting:
[SETTINGS] ... PORT_80=50555 ...
Now, the url to access the status web page is http://127.0.0.1:50555.
Remote booting of a device usually works in the following steps. Continue reading
The IPPOOL_x setting allows to configure an IP pool like 192.10.1.2-254. This is a class C network with a subnet mask of 255.255.255.0. To define a class B network simply configure the IP pool such as 192.10.2.1-192.10.5.254 with a subnet mask 255.255.0.0. Thats all. DHCP server versions prior to V2.3.1 require a bit more effort.
Yes. Set UseClientID=1 and all client sections will be named after the option 61 supplied name of the client. See UseClientID setting for details.
[Settings] ConfigureUnknownClients=1 ; Default: 1
ConfigureUnknownClients is available since V1.7. Setting this to 1 tells the DHCP server to automatically configure unknown clients. Since this is the default, there is no change to previous versions. If ConfigureUnknownClients is set to 0, then a client is assigned an IP address only if the client is already specified in the INI file. Note: Important difference to IgnoreUnknownClients. IgnoreUnknownClients only controls how the DHCP Server behaves when no IP address is assigned (declining request or keep quiet). What makes a client a “known client” is an existing entry in the INI file such as:
[00-01-02-03-04-05] ; mac address AutoConfig=1
or
[00-01-02-03-04-??] ; mac address with wildcards AutoConfig=1
or
[client-identifier] ; client identifier (option 61) AutoConfig=1
DHCP Server runs on all Win32 based Windows Version. Continue reading
The DeleteOnRelease setting is new in V1.9.
[Settings] DeleteOnRelease=0 ; Default: 1
It defines whether a client entry in the databse is deleted upon DHCPRELEASE, or not. The default behavior is to automatically delete the entry in the database. The effect is that when the same client comes back after some time and asks for an IP address, no information about it’s previous IP address is available. Even if the old IP address is available, it would most likely not being chosen. With DeleteOnRelease set to 0, the entry only gets an expired lease timestamp and can therefore be reactivated at a later time.
In addition to this the DeleteOnRelease setting also controls the bahvior for expired leases. When DeleteOnRelease is set then expired leases are also automatically deleted from the INI file same as DHCPRELEASE from client. This is new in V1.9.3 and is based on a timeout mechansim. The timeout is set to the time when the next client lease expires. This is updated every time a DHCP action is happening.
AddStandardEntries is a new setting in V2.3.4.
[Settings] AddStandardEntries=1 ; Default: 1
It allows to control the behaviour of the DHCP Server with respect to DNS_x, WINS_x and ROUTER_x entries in the replies from the server to the client. The default behaviour (AddStandardEntries=1) is to automatically add the standard values from the Windows configuration to the reply message. This is convenient, because it makes it unneccessary to repeat all the DNS_x, WINS_x and ROUTER_x settings that were already made in Windows IP configuration. If the server should not take the standard values from Windows, then set AddStandardEntries=0.
Since version 2.0 of the DHCP Server the $(section\name) syntax can be used in the INI file. This helps to keep the INI file simple and prevents repeating information such as IP addresses in many places. Here is an example of a typical INI file:
[Settings] IPBIND_1=192.168.17.2 IPPOOL_1=192.168.17.2-50 AssociateBindsToPools=1 [DNS-Settings] EnableDNS=1 [General] SUBNETMASK=255.255.255.0 DNS_1=192.168.17.2
A clean and simple INI file with one IP pool and DNS enabled. If the IPBIND_1 interface ever changes, then one would need to change the IP address 192.168.17.2 in three places. No big deal but can be avoided with the following INI file utilizing the $(section\name) syntax:
[Settings] IPBIND_1=192.168.17.2 IPPOOL_1=$(Settings\IPBIND_1)-50 AssociateBindsToPools=1 [DNS-Settings] EnableDNS=1 [General] SUBNETMASK=255.255.255.0 DNS_1=$(IPBIND_1)
If the interface ever changes then only IPBIND_1 needs to be edited. $(IPBIND_1) is equivalent to $(Settings\IPBIND_1). Settings is sort of the default section. $(section\name) can be used for everything in the INI file. It can even be used for INI file entries that the DHCP Server doesn’t even know. Here is an example showing the usage for directories:
[Settings] BaseDir="d:\dhcpsrv" ; dhcpsrv.exe resides here IPBIND_1=192.168.17.2 IPPOOL_1=$(Settings\IPBIND_1)-50 AssociateBindsToPools=1 Trace=1 TraceFile="$(BaseDir)\dhcptrc.txt" ; trace file [DNS-Settings] EnableDNS=1 [General] SUBNETMASK=255.255.255.0 DNS_1=$(IPBIND_1) [TFTP-Settings] EnableTFTP=1 Root="$(BaseDir)\wwwroot" ; use wwwroot for http and tftp [HTTP-Settings] EnableHTTP=1 Root="$(BaseDir)\wwwroot" ; use wwwroot for http and tftp
This way the base dírectory of DHCP Server can be changed easily in one single place and the trace file and all the other entries that refer to files are always correct.
A client section can be specified based on wildcards (since V1.7). Please use this with care. Recommendation is to not use client-id based specifications (UseClientID=0) and also to make sure that no interference with IPOOLs is possible, because the DHCP Server is not able to check this. This is how it works:
A client section can be defined based on wildcards like this:
[00-01-02-03-04-??] IPADDR=192.168.17.%m5
What happens is that if a client that matches the above wildcard asks for an IP address, that the IP address assigned is automatically composed by using mac address byte 5 (%m5). The resulting mac address for client [00-01-02-03-04-6A] will be 192.168.17.106. (6A hex is 106 dec).
Mac address byte 0 through 5 are accessed accordingly with %m0 through %m5. The wildcard match algorithm searches in the following order and takes the first matching entry:
[00-01-02-03-04-6A] [00-01-02-03-04-??] [00-01-02-03-??-??] [00-01-02-??-??-??] [00-01-??-??-??-??] [00-??-??-??-??-??] [??-??-??-??-??-??]
In addition to the %m0 through %m5, since V2.3.1 there are further macros available. These are %ip0 through %ip3. They allow to access the IP address of the IPBIND_n address used by the current DHCP request. If IPBIND_1 is defined as IPBIND_1=192.168.5.1, then the macros are extended to: %ip0=192, %ip1=168, %ip2=5 and %ip3=1.
The DHCP server supports custom options in addition to the above options. This allows to specify all possible DHCP options in client and general sections. (New in V1.7)
The syntax for custom options is:
[00-01-02-03-04-6A] OPTION_nn="whatever text" ; text OPTION_nn=02:03:04:05 ; hex bytes OPTION_nn=192.168.2.1 ; IP address OPTION_nn= 01 "whatever text" ; combination of hex byte and text
nn is the option number (decimal) such as OPTION_66 for TFTP server IP address. Leading zeros, such as OPTION_060, will cause problems in earlier versions. Version 2.7 and newer support leading zeros.
Please note that all the examples above have a trailing comment in each line. This is necessary and is not optional. The comment even if it is only the semi-colon (;) is needed.
OPTION_nn=”whatever text” ;
If there is no comment symbol at the end then the OPTION_nn setting will not be recognized correctly and is treated as malformed and therefore ignored.
The custom option syntax understands hex bytes as two digit values, IP addresses as a group of four decimal numbers separated by ‘.’, and “text”. As separators are allowed: blanks and colons (:). Two special syntax features make it easier to deal with custom options (available since V2.4). The first is the auto-len prefix for everything inside of parentheses (). You can group all data (hex bytes, IP addresses and text) as you whish and put parentheses around them. The resulting encoding will automatically prefix the data with a length field. An example can be seen in the FAQ.
The second new feature in V2.4 is related to IP address encodings. Sometimes it is necessary to encode, e.g. in OPTION_121, a network ID in a compact form. Example:
OPTION_121= 10.10.30.0/24 10.10.20.254 ; encodes to 18 0A 0A 1E 0A 0A 14 FE
This defines a classless static route for all addresses in the 10.10.30.0/24 network to be routed via 10.10.20.254. The encoding for this is an 8 byte octect sequence as shown above, where the first 4 octects are a compact CIDR syntax. Compact CIDR syntax means, that 10.10.30.0/24 only consists of the relevant octets for the network id. The relevant octets in this case are 3, because /24 makes the 4th octet of 10.10.30.0 irrelevant.
WPAD=http://server.domain/config.pac
Location of a proxy server (Web Proxy Auto Detection) used by Internet browsers to automatically detect proxy settings.
WINS_0=123.4.56.78 … WINS_9=192.168.2.1
This entry sets the IP address of the WINS servers. You can setup up the 10 WINS servers using the entries WINS_0 to WINS_9.
SUBNETMASK=255.255.255.0
The subnet mask is usually common to all clients and should be placed in the general section. This has to be the same as the subnet mask of the server machine that is setup in your network settings.
Specifying the Router / Gateway
ROUTER_0=123.4.56.78 … ROUTER_9=192.168.2.1
This entry sets the IP address of the router or standard gateway. You can setup up to 10 routers by using the entries ROUTER_0 to ROUTER_9.
NODETYPE=8 ; Default: 8
Default: 8, which means hybrid. I’ve never used something else than 8.
IP address of the “next server”.
NEXTSERVER=123.45.6.7
This is typically used to specify a TFTP server in the BOOTP protocol.
“ClientPC” is send to the client as the hostname entry in the DHCP options.
NAME=ClientPC
This is supposed to be the name of the client machine. This entry doesn’t work with Windows clients, because they do not change the computer name.
Lease time in seconds (decimal value).
LEASETIME=3600 ; 1 hour Default: infinite
E.g. 86400 is the lease time for 1 day. Default is an infinite lease. The actual lease period for the clients IP address is the minimum of the configured LEASETIME and the lease duration the client is asking for.
LeaseEnd is specified as number of seconds since midnight (00:00:00), January 1, 1970 and defines the time at which this particular IP address expires.
LeaseEnd=1198953446
This entry is automatically created by the DHCP Server.
Lease times are important when a client requests an IP address and all addresses in the IP pool are already assigned to other clients. In that case the client whose lease time (LeaseEnd) has expired least recently is deleted from the INI file and the available IP address is used for the request.
Specifying the IP Address.
IPADDR=192.168.10.11
This is the IP address that has to be assigned to the client. This is the most important entry in the client section. Since V2.6.0 you can set the IPADDR=0.0.0.0 to black list a client to prevent the client device to get an IP address assigned.
This entry should define the domain name that is send to the client machine. This is in most cases the name of the domain or workgroup that your server machine is in.
DOMAINNAME=mydomain
This entry sets the IP address of the DNS server. You can setup up to 10 DNS servers.
DNS_0=123.4.56.78 … DNS_9=192.168.2.1
Defining the BOOTFILE.
BOOTFILE=bootimage.bin
A string that typically defines the boot file which is fetched from a TFTP server by the client.
This entry marks a client section as being created by the DHCP Server (auto configuration). Don’t touch it.
AutoConfig=12/29/2007_18:37:26
V2.4.2 released 08/17/2014. New in V2.4.2: Option strings supported up to a longer length of 1024, now. Treating 255.255.255.255 in yiaddr as if no IP address is given in DHCPDISCOVER requests.
V2.4.1 released 12/27/2013. New in V2.4.1: Fixed minor bugs. Added setting ObeyParamReqList to restrict responses to the requested options. Handle client id option 61 less restrictive and assume ascii text representation by default. Package validation now checks for longer mac addresses than 16 bytes. Detection of IP configuration changes delays restart of server until currently running tftp transmission is finished.
V2.4 released 02/24/2013. New in V2.4: Fixed bugs in handling relative root paths in http and tftp function. Fixed bugs with comments in the INI file not being recognized as such in all places. Fixed bug in wizard not putting VENDORCLASS in the right section. Fixed bugs with respect to multiple scopes and relay agent when subnet mask of local network is different from the served network behind the relay agent. New extension in custom option definition to allow compact CIDR syntax and grouped sub-options with auto len tagging. Added SERVERNAME setting to define the sname field content. Redefined the virtual web pages which are created on the fly for the status page as not-cached. https://lookup-phone-prefix.ca
V2.3.5.1 released 11/28/2012. New in V2.3.5.1: Fixed bug in Web server interface not showing the current clients after the latest update.
V2.3.5 released 11/26/2012. New in V2.3.5: Fixed bug in DHCP Wizard handling sub-options and added a preview to the generated INI file. Fixed bug in DHCP Server that prevented IP scopes to work, when a database file is configured. Fixed bug in resolving INI file variables in database file. Added inistring to the string-expression syntax of IPSCOPE syntax.
V2.3.4 released 10/20/2012. New in V2.3.4: Fixed bug with respect to mulitple IPs per NIC. Added setting AddStandardEntires. The IPSCOPE syntax now has a new simple-bool-expression keyword: isKnownClient.
V2.3.3 released 10/14/2012. New in V2.3.3: Added setting [HTTP-Settings] DefaultFile. Fixed bugs in handling relay agent requests, IPSCOPE handling and increased robustness when client id (option 61) includes non printable characters. Added support to report more than one record in DNS requests.
V2.3.2 released 7/21/2012. New in V2.3.2: Added setting ClearClientsOnStartup. Fixed bug in class A/B style handling.
V2.3.1 released 2/19/2012. New in V2.3.1: Fixed bugs in tftp retransmission, allow timeout option also in write requests of tftp. Allow to enter class A/B style IP address pool definitions. Computer name (host name) option extended to 255 characters. Fixed bug in IPSCOPE_n evaluation. Fixed bug that shows static entries as expired in the status web page. Support configfirewall / removefirewall command line options. Add support for %ip0 through %ip3 macros in wildcard client sections. Wizard now allows to switch on / off the Trace setting.
V2.3 released 11/21/2011. New in V2.3: Support of multiple scopes with scope selection syntax (IPSCOPE_n). Fixed bug in http server: allows mulitple reads of the same file, now.
V2.2.3 released 11/10/2011. New in V2.2.3: Fixed bug in http server with respect to large file downloads with wget. Removed a few unnecessary traces. Added interpretation of option 55 and 77 in the capture page of the web server, Added MaxBlockSize to tftp-settings to limit the maximum number of bytes in one UDP packet. Added the setting SingleInstanceApp to have only one instance of the DHCP Server when running in application mode.
V2.2.2 released 10/31/2011. New in V2.2.2: Fixed bug with multiple TFTP options and with DHCPDECLINE handling on duplicate address allocation.
V2.2.1 released 09/27/2011. New in V2.2.1: Added NAKMessage setting for info text with DHCPNAK message. Fixed bug related to extended characters in hostname. Number Search
V2.2 released 08/14/2011. New in V2.2: Improved robustness against malformed DHCP requests. If the verification identifies requests falsly as malformed, then it can be switched of with the new PacketValidation setting. Added package capture view as Web Server page for advanced diagnostics. Please notice the capture link. It brings you to a list of the last 16 DHCP packages transmitted.
V2.1.4 released 07/31/2011. New in V2.1.4: Improved the DNS forwarding to be more responsive.
V2.1.3 released 06/05/2011. New in V2.1.3: Improved the relay agent functionality to work with other DHCP servers. Added RelayAgentAdvanced setting.
V2.1.2 released 05/21/2011. New in V2.1.2: Fixed bug in handling custom options on first offer. Fixed bug in relay agent functionality. Improved TFTP speed.
V2.1.1 released 03/01/2011. New in V2.1.1: Fixed bug in http module to eliminate illegal text in xml file.
V2.1 released 02/09/2011. New in V2.1: Service installation and firewall exceptions now supported including administrator elevation. Changed user interface dialog in wizard and dhcpsrv for that. Added configurable icon, fixed bug in non keep-alive http communication.
V2.0.2 released 01/31/2011. Fixed bug in handling HTTP 1.0 request (needed to successfully run apache benchmark program).
V2.0.1 released 01/27/2011. Fixed bug that caused a crash when no IPBIND settings are found.
V2.0 released 01/26/2011. New in V2.0: Added HTTP Server with diagnostic page for current server status along with a menu item to open web browser. Added $(section\name) syntax in INI file. Added configration wizard for first time setup of INI file. Addded relay agent functionality in conjunction with the support of multiple scopes. Fixed bugs in expired lease handling when DeleteOnRelease=0 and in error handling for service installation. Fixed bugs related to filenames with spaces.
V1.9.4 released 12/08/2010. New in V1.9.4: Fixed bugs in the expired lease handling and allowing comments after TraceFile. Added ExpiredLeaseTimeout setting.
V1.9.3 released 10/30/2010. New in V1.9.3: Basic load balancing support (HBA), AllowDNSQuery setting to further enhance the DNS security mechanism, automatically deleting clients after lease is expired and notifications on DHCPDECLINE messages to indicate IP address conflicts. Fixed a bug in TFTP module.
V1.9.2 released 10/16/2010. New in V1.9.2: Hostname is updated on every request to have an updated record after name changes on the client side. [General] and [General_x] section can now also be put into the config file. Database file is checked first and if no info found then config file is used. Fixed bugs in TFTP module.
V1.9.1 released 08/14/2010. New in V1.9.1: Fixed bugs in packet retransmission of TFTP and in DHCPRELEASE handling. Added TransferWindow speed improvement for TFTP. Added EnableSendRawUnicast and OverwriteBroadcastFlag for special handling of unicast responses.
V1.9 released 06/26/2010. New in V1.9: Integrated tftp server, option for keeping clients in the database even after DHCPRELEASE, enhanced IPPOOL_x syntax and configurable service name. Bug fixed with memory leaks in the DNS request handling. Smaller corrections.
V1.8.1 released 04/09/2010. New in V1.8.1: Bug fix with service installation (error 0x41d).
V1.8 released 03/01/2010. New in V1.8: Binding by adapter name (instead of IP address), support for multiple instances, improved BOOTP support, integrated DNS server and some smaller improvements and error corrections.
V1.7 released 03/22/2009. New in V1.7: Customized Options, support of client-identifier (option 61), command line options, support of DHCPINFORM message and a couple of smaller improvements. Such as balloon messages in application mode and more settings to control the behavior of the DHCP server.
V1.6.5 released 02/22/2009. Following fixes: DNS_X and WINS_x now support range from 0-9. Relay agent support now works as expected. Target address of response packet algorithm reworked. DHCP server ports are configurable (PORT_67 and PORT_68). DHCP server assigns IP address only in same subnet as NIC. https://lookup-phone-prefix.com
V1.6.4 released 01/01/2008. Minor bug fixes plus support of the AssociateBindsToPools option which allows to have IP Pools dedicated to a particular subnet. Updated Web Site with new design.
V1.6.1 released 12/22/2007. Supports fully dynamic IP Pools including correct handling of the lease time and reuse of expired leases.
V1.5.3 released 3/21/2004. Minor bug fix concerning reaction on bad packets.
V1.5.2 released 4/18/2003. Minor bug fixes plus the support of TraceFile and LEASETIME options.
V1.5 released 4/17/2003. Supports IP pools for auto configuration. A feature that has been asked for about a million times.
V1.4 released 9/4/2000. Supports binding to particular NIC cards and a silent mode for unknown clients.
V1.3.0.1 released 2/24/2000. The new Windows 2000 functions are loaded dynamically. It turned out that the DLL’s are not available or do not contain the new functions on Windows NT 4.
V1.3 released 2/12/2000. V1.3 comes with two major enhancements: It runs as a Windows NT/2000 service and it supports Windows 2000 plug and play.
V1.2 released at 10/3/1999. I’m proud to announce that the version 1.2 has a bug fix that allows the support of Windows 98 clients. It turned out that Windows 98 clients didn’t work https://phonefindservice.info , at all. This was related to a wrong port number that the DHCP server was using.It also has an option to print a trace of the activity of the server.
V1.1 released at 9/25/1999. This version fixes a bug that occures on Windows 95 and 98. The DHCP server was not able to terminate correctly. It alway kept running, even if the tray icon was already gone. There are no other changes to the code.
V1.0 release at 08/14/1999. This is the very first version that I put on the Web. It was running in my configuration (Windows NT 4.0 SP3 as server and client machine) and I was just curious whether somebody else is interested in that or not.
I’ve started in early summer of 1999 to investigate the Web to find a DHCP server that would allow me to just hook my notebook onto my tiny home network (a crossed cable!) without reconfiguring it every time. I could find only very large programs that had a DHCP server as one of many parts in it. Or I could find unix sources that were not that easy to port to windows. Since, I’m a curios guy, I started do develop it myself. It turned out to be quite easy and it was running within three days, or so.