Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

DHCP option 66

I would love to just post in this thread:
http://discussions.apple.com/thread.jspa?threadID=2347065
But Apple likes to lock old threads and force you to start over...

The indication in that thread is people did get this to work, but there is no final note of exactly how. So far we are finding it does not function properly. We're trying to set up a Fog server, but using the Mac server for DHCP. Unfortunately it fails to actually forward the client to the Fog server as needed. Here is what we have done:

on the Mac server (10.6.4) edit the /etc/bootpd.plist
below the array for dhcp domainsearch and above the dhcp_router key, we insert the following:

<key>dhcp option66</key>
<data>
krp+CQ==
</data>
<key>dhcp option67</key>
<data>
cHhlbGludXguMA==
</data>

These values are obtained using the DHCP Option Code Utility posted in the above thread with these inputs:
Option Code Number: 66
Option Code Type: IP
Option Code Value: 146.186.126.9

Option Code Number: 67
Option Code Type: String
Option Code Value: pxelinux.0

When those didn't work, because the info in the noted thread was not clear, we also tried:
Option Code Number: 66
Option Code Type: String
Option Code Value: 146.186.126.9

Which gave us:
<key>dhcp option66</key>
<data>
MTQ2LjE4Ni4xMjYuOQ==
</data>

This also did not work. In every case the TFTP times out indicating option 66 is not defined or is not being followed correctly. It's a shame that unlike Microsoft, Apple has not included these common option controls in their server interface. We're hoping someone who has actually gotten this to work will see this and be able to clear up what Apple needs for input to make it actually work right.

Thanks for any help!

Intel Xserve, Mac OS X (10.6.4)

Posted on Jul 22, 2010 8:18 AM

Reply
2 replies

Jul 23, 2010 8:07 AM in response to Ebonweaver

Hi, I am the author of the DHCP Option Code Utility and therefore the unofficial worldwide expert on Apple's DHCP Server 😉

If you go to http://www.sustworks.com/site/prodipmxoverview.html you can download a copy of IPNetMonitorX which includes a feature to test DHCP option codes. For example, you could test option 66 on a different make of DHCP Server (one that works) to see what exactly it returns, and then do the same test against Apple's DHCP Server and see if it is returning exactly the same result. Obviously if it returns a different result there is a problem.

Note: IPNetmonitorX shows all DHCP option code results as decimal numbers (you need verbose logging turned on), you may therefore need to translate these to hex or ASCII values. One decimal number equals one hex number or one ASCII character.

I can tell you that using DHCP Option Code Utility to generate the values, Apple's DHCP server works fine for many users needing to do this to support VoIP phone systems which also need to advertise a TFTP server.

I have looked at your message and as far as I can see, your entry for Option67 is what I would believe to be correct. Obviously this field is not an Integer, nor is it an IP address, so using the String option is the only logical choice. For Option66, like your post, two choices spring to mind, the first being to use the IP address choice and the second the string choice. Again your examples are what I would use with my first choice being the IP address one.

However there is one thing I can mention that may (or may not) help. An IP address for humans is written as 146.186.126.9 that is four decimal integers between 0 and 255 each separated by a full stop, if we break this down we have the following decimal integers

146
186
126
9

in hexadecimal the above translates to

92
BA
7E
9

Now the way Apple's DHCP Server actually stores IP addresses (ignoring the encoding you see) is actually as four hexadecimal bytes so if you use my utility to encode

92 BA 7E 09

as hexadecimal, you will find it results in the identical krp+CQ== result. Now apart from giving you some background which may help if/when you use IPNetMonitorX to test DHCP server option codes, what this also allows you to consider is that it maybe that some systems want these bytes in a different order. This relates to 'little endian' vs. 'big endian' see http://www.cs.umass.edu/~verts/cs32/endian.html

I am somewhat doubtful of this, as all the VoIP systems I have dealt with use the same order equivalent to 146 186 126 9

If your able to use IPNetMonitorX to query FOG's own DHCP server and give me the result, I can see what difference it is doing.

Note: You should only have one DHCP server on a network at a time, so you should do this test on a standalone network or when you will not interfere with your live network.

Note: You need to stop and start the Apple DHCP server in Server Admin to get it to re-read /etc/bootpd.plist and use your new settings. You should therefore stop the DHCP server while editing the file.

UPDATE - NEWSFLASH

Just retested my own Mac OS X 10.6.4 DHCP Server which has four DHCP option codes defined which were previously working. When I tried adding a copy of your option66, even with supposedly my DHCP Server 'stopped' it kept overwriting the changes I made. It maybe your server is also almost immediately overwriting and losing your option codes. Try doing it in single user mode or even booting from another disk and of course double check your bootpd.plist still lists your option codes.

Jul 24, 2010 8:07 PM in response to John Lockwood

Thanks for the great reply John!

Unfortunately what you're indicating is that I did in fact try options that should work, and yet they do not. I also did not see the behavior you saw with the changes to the bootpd.plist being overwritten, they took just fine each time I tried a variation and went back in, and I was stopping before edit and starting after edit. These option codes may be working for Voip folks, but they seem to fail with PXE boot. As someone in that one referenced thread indicated they did get PXE to work, with a Fog system to boot (no pun intended), I am hopeful there is a solution for this, I just don't know what it might be. Hopefully someone who has gotten this to work will see this and be able to shed light on the magic key.

In the mean time, I'll see if I can arrange a test with IPNetMonitorX to see if we can capture some meaningful info about what Apple is doing different with the code.

DHCP option 66

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.