Adding DHCP options into bootpd.plist

I am the author of DHCP Option Code Utility (for Mac) which generates the encoded values you need to use in the bootpd.plist file. So I have some expertise in this area. 🙂

First, the example bootpd.plist file you list above has the DHCP options codes listed twice with identical values, the first copies seem to be in the correct place so you don't need the second copies (which you listed in bold text).

Secondly, PCs using PXE boot via DHCP need the DHCP option code 67 to be a null-terminated string rather than a normal string. I added the ability to generate null-terminated strings in version 1.1 of my utility along with some other teaks. You can download this version here http://jelockwood.blogspot.co.uk/2013/06/dhcp-server-on-os-x-server.html here is the encoded null-terminated value for DHCP option code 67.

<key>dhcp_option_67</key>

<data>

cHhlbGludXguMAA=

</data>

Thirdly, if the pxe boot file is in a sub-directory of your TFTP server file folder then you may need to include that in the file name value you use in DHCP option 67, e.g. instead of just pxelinux.0 it might need to be foldername/pxelinux.0 (null-terminated of course).

Fourthly, PXE seems to be a particularly stupid system, DHCP option code 66 is supposed to tell the PXE client the TCP/IP address of the TFTP server to boot from, however PXE also seems to want a 'next server' value which as far as I can tell means the same thing! Unfortunately the Mac bootpd server cannot do a 'next-server' command.

I have had some feedback implying they did managed to get PXE working with DHCP option 66 and 67 generated by my utility and others who say it failed. It could be that if your DHCP server is the same Mac as your TFTP i.e. PXE boot server then it will work.

I do know DeployStudio includes a PXE boot server for PCs so I think it should be possible to do.

Anyway, the first and most important thing is to use a null-terminated string.

I think the first thing to do is test to see if DHCP clients are getting these options codes. To do this you need to either use IPNetMonitorX (the trial version would be sufficient), or try the following in Terminal.app

Remember you must do this on a DHCP client machine, not on the DHCP server.

ipconfig getoption en0 66

ipconfig getoption en0 67

Obviously substitute the correct interface designation for your situation.

If the Mac DHCP client machine does get the correct values, then your DHCP server is set up correctly. Then I am afraid it might be one of two things.

1. For PXE booting the string in DHCP option 67 needs to be terminated by a NULL character, the latest/current version of my utility now has the ability to create such values.

2. While DHCP option 66 gives the IP address of the TFTP server to boot from, it seems the PXE protocol is 'weird' and needs the main DHCP server to also say 'here is the next server' and this is not done via DHCP option code and cannot be done as far as I can see using Apple's DHCP server. As a result it may only work if the Mac is the PXE boot server itself as well as being the DHCP and TFTP servers. This may actually be possible, DeployStudio for Mac can install DeployStudio PC to act as a PXE boot server (the Mac has a built-in TFTP server).

It could be 'next-server' is actually the same thing as DHCP option 66, just like 'router' is DHCP option 3 and 'domain_name_server' = DHCP option 6. (I am becoming more convinced of this.)

I did have at least one person say they got PXE working thanks to my utility but several others said they got stuck. As I don't use PXE I have not been able to reproduce or test this myself. As far as I am aware, DHCP option 66 should be defined as an IP address type value, and DHCP option 67 should be defined as a NULL terminated string value (both using my tool).

By the way, if your testing as above shows your DHCP server is not sending out these options let me know and I will more closely examine your configuration for you. It would be worth testing DHCP option 3 and 6 as well to make sure the command is working.

Let me know your results.

Ok, I have now had a chance to have a closer look at your orignally posted copy of your boot.plist.

First, I can see that the value for your DHCP option 67 is not a NULL terminated string but is just an 'ordinary' string. The correct value for a NULL terminated string of pxelinux.0 will be

<key>dhcp_option_67</key>

<data>

cHhlbGludXguMAA=

</data>

Second, it was not clear from your reply what result if any you got from trying

ipconfig getoption en1 3

(or your Ethernet interface equivalent). On a MacBook Air or MacBook Retina Display the en0 would be the WiFi, on a Mac Pro, iMac or Mac mini en0 would be your Ethernet. You need to use which ever interface is your network connection. For example on an older MacBook Pro en0 is Ethernet but I am actually using WiFi which is en1, again remember you are doing this on your client Mac not the server.

Network Utility can show you which is your active interface.

Other than that, it looks like you have the DHCP options in the right format and right place.

I can see you appear to have two network interfaces bonded together. I seem to vaguely recall that this might cause problems with Apple's DHCP server.

It looks like your DHCP server 'thinks' the name of the interface it should use is en1. However if en1 is only the name of an individual interface e.g. the built-in Ethernet, and actually en2 is the name of the combined i.e. bonded interface then it is looking at the wrong interface. This would therefore need correcting.

Obviously the simplest option would be to start of with just a single interface (not bonded) for initial testing.

Unfortunately I don't think the native bootpd process passes option 66. It does pass option 67 quite happily. See this thread. Perhaps isc-dhcp will do a better job.....

I got your bootpd.plist and the one listed by dLEVO confused. Yours shows it is set to advertise via bond0 his was set to en1. The same confusion also probably explained the NULL termination issue.

Having this time checked the right copy, I still could not see anything obviously wrong.

It did occur to me that any changes made by hand editing /etc/bootpd.plist will not be active until you stop and start the DHCP server again - to force it to re-read the updated file. My experience is that legitimate custom entries like this are not overwritten.

Also, while I don't believe it should make a difference since it is in the same block of the XML, I personally normally put DHCP options after the existing 'standard' entries, I can see you put yours at the beginning. So this would mean moving them after the net_mask and net_range entries.

I also use the same level of indentation spaces/tabs as the other lines, more to make it look tidier.

I have not used bonded interfaces much before, but I see that on your server your en0, en4, and bond0 all have the same MAC address. This is probably a result of having bonded them, but just to double check, if you break the bond, en0 and en4 should then have different MAC addresses. If they still have the same MAC then there is a problem. As I suggested before, it is probably a good idea to start of simple i.e. a single interface with DHCP get that working and then add bonding to the mix after.

Made the changes to the option 67 key, made it NULL terminated, thought I had selected when I was using your tool...

I'm using a Macbook Pro on wifi as my client, according to ifconfig, I'm using en1. If I type ipconfig getoption en1 3, this is what my output looks like:

$ ipconfig getoption en1 3

172.16.8.1

$

If I type ipconfig getoption en1 66 or 67, the output is as follows:

$ ipconfig getoption en1 66

$

I'll give a single interface a try, although I don't see where it would reference en1 in the plist, just bond0. Here is the output of ifconfig on the server:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384

options=3<RXCSUM,TXCSUM>

inet6 ::1 prefixlen 128

inet 127.0.0.1 netmask 0xff000000

inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

nd6 options=1<PERFORMNUD>

gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280

stf0: flags=0<> mtu 1280

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>

ether 68:5b:35:cd:12:b8

media: autoselect (1000baseT <full-duplex,energy-efficient-ethernet>)

status: active

en4: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>

ether 68:5b:35:cd:12:b8

media: autoselect (1000baseT <full-duplex,energy-efficient-ethernet>)

status: active

en1: flags=8823<UP,BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500

ether 28:cf:e9:03:f3:8b

nd6 options=1<PERFORMNUD>

media: autoselect (<unknown type>)

status: inactive

en3: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500

options=60<TSO4,TSO6>

ether 32:00:14:95:d5:60

media: autoselect <full-duplex>

status: inactive

fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078

lladdr 44:fb:42:ff:fe:49:5d:56

nd6 options=1<PERFORMNUD>

media: autoselect <full-duplex>

status: inactive

bond0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

options=b<RXCSUM,TXCSUM,VLAN_HWTAGGING>

ether 68:5b:35:cd:12:b8

inet6 fe80::6a5b:35ff:fecd:12b8%bond0 prefixlen 64 scopeid 0x9

inet 172.16.10.14 netmask 0xfffffc00 broadcast 172.16.11.255

nd6 options=1<PERFORMNUD>

media: autoselect (1000baseT <full-duplex,energy-efficient-ethernet>)

status: active

bond interfaces: en4 en0

p2p0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 2304

ether 0a:cf:e9:03:f3:8b

media: autoselect

status: inactive

bridge0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500

options=63<RXCSUM,TXCSUM,TSO4,TSO6>

ether 6a:5b:35:dc:99:00

Configuration:

id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0

maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200

root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0

ipfilter disabled flags 0x2

member: en3 flags=3<LEARNING,DISCOVER>

ifmaxaddr 0 port 7 priority 0 path cost 0

media: <unknown type>

status: inactive

Well, looks like something is amiss on the server, when I execute the commands above on my Mac client, I get nothing returned. To make sure the command was working correctly, I tried getting option 54, which returned the address of the DHCP server.

To see what options were actually being returned, I ran dhcptest.exe on a Windows client and got the following output:

Sending packet:

op=BOOTREQUEST chaddr=32:D0:8F:D8:FF:3F hops=0 xid=A97FEFEF secs=0 flags=8000

ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file=

1 options:

53 (DHCP Message Type): discover

Received packet from 172.16.10.14:67:

op=BOOTREPLY chaddr=32:D0:8F:D8:FF:3F hops=0 xid=A97FEFEF secs=0 flags=8000

ciaddr=0.0.0.0 yiaddr=172.16.8.214 siaddr=172.16.10.14 giaddr=0.0.0.0 sname=**

mbledore.domain.ad file=

3 options:

53 (DHCP Message Type): offer

54 (Server Identifier): 172.16.10.14

51 (IP Address Lease Time): 3564 (59 minutes and 24 secs)

Hey John,

Been reading many of your posts and they all seem quite helpful, but I'm also stuck trying to configure options 66 & 67.

I'm running Server 3.1.2 on Mavericks, your utility to generate the options seems to work, but I'm not sure where to place them in the file, tried a few different locations without success. Here is my current bootpd.plist:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>NetBoot</key>

<dict>

<key>startTime</key>

<string>2014-06-30 18:29:49 +0000</string>

</dict>

<key>Subnets</key>

<array>

<dict>

<key>allocate</key>

<true/>

<key>dhcp_domain_name</key>

<string>domain.ad</string>

<key>dhcp_domain_name_server</key>

<array>

<string>172.16.10.10</string>

<string>172.16.10.7</string>

<string>8.8.8.8</string>

</array>

<key>dhcp_option_66</key>

<data>

rBAKEw==

</data>

<key>dhcp_option_67</key>

<data>

cHhlbGludXguMAA=

</data>

<key>dhcp_domain_search</key>

<array>

<string>domain.ad</string>

</array>

<key>dhcp_router</key>

<string>172.16.8.1</string>

<key>lease_max</key>

<integer>3600</integer>

<key>name</key>

<string>172.16.8/22 Ethernet</string>

<key>net_address</key>

<string>172.16.8.0</string>

<key>net_mask</key>

<string>255.255.252.0</string>

<key>net_range</key>

<array>

<string>172.16.8.10</string>

<string>172.16.11.253</string>

</array>

<key>selected_port_name</key>

<string>bond0</string>

<key>uuid</key>

<string>0F3374EB-FDDA-4DCD-A8F8-E5CDFC661A99</string>

</dict>

</array>

<key>allow</key>

<array/>

<key>bootp_enabled</key>

<false/>

<key>deny</key>

<array/>

<key>detect_other_dhcp_server</key>

<false/>

<key>dhcp_enabled</key>

<array>

<string>bond0</string>

</array>

<key>netboot_enabled</key>

<array>

<string>bond0</string>

</array>

<key>old_netboot_enabled</key>

<false/>

<key>relay_enabled</key>

<false/>

<key>relay_ip_list</key>

<array/>

<key>timeServiceStarted</key>

<string>2014-07-02 15:16:23 +0000</string>

</dict>

</plist>

I have a Fog server handling my Windows imaging on 172.16.10.19, using pxelinux.0 (all tested through a TFTP client), but when I boot a Dell into PXE, it finds an IP address but the output for the TFTP server looks like this:

TFTP.

Then it just exits, before it should show the IP address of the TFTP server.

I do have the option of using DHCP on a Windows Server VM, but I'd rather have my Mac Mini do it.

Made the corrections to the file and I restarted the server... I use the Server.app DHCP On -- Off switch to restart the server, I assume that would do the same thing as a command-line equivalent?

If it did restart properly, it still doesn't work :/ Guess I'll have to try unbonding the interfaces and seeing if that works, won't be able to do it this week as I have some more pressing tasks, but will give it a try next week.