Configure DHCP Options 66 and 67

Your report of this in Mac OS X Hints shows encoding the Option 67 filename as data, but leaving Option 66 as the IP address string, i.e. not encoded in any way. Does this work? I've read a lot of threads about this issue and they all seem to indicate that all additional Options need to be encoded as data, but is Apple's bootpd actually capable of delivering such IP address strings correctly? If so, does that work just for 66 or any additional Options that supply IP addresses?

Anyone confirm whether or not IP address Options work as a string?

UKenGB wrote:

Your report of this in Mac OS X Hints shows encoding the Option 67 filename as data, but leaving Option 66 as the IP address string, i.e. not encoded in any way. Does this work? I've read a lot of threads about this issue and they all seem to indicate that all additional Options need to be encoded as data, but is Apple's bootpd actually capable of delivering such IP address strings correctly? If so, does that work just for 66 or any additional Options that supply IP addresses?

Anyone confirm whether or not IP address Options work as a string?

My own experience is that if Apple's man page for bootpd lists a specifically named version of a DHCP option e.g. dhcp_ldap_url aka. option 95, and dhcp_network_time_protocol_servers aka. option 42 then you can for the named versions use a non-data format. For others like option 66 which is not listed by Apple as a named version then my experience is you need to use the data format. The man page implies it should be able to auto convert values e.g. an IP address but while I have not re-tested this in more modern versions of OS X back when Apple originally added support for DHCP option codes in response to my request this did not work. This is why I wrote my DHCP Option Code utility to do the hard work for converting all formats to the correctly encoded data value.

Hi John, yes I've been following your progress through the miasma of OSX Server's bootpd implementation. Well done for writing your encoding utility, most useful. However, I read an entry on Mac OS X Hints by edxley (a participant in this thread) and he explains encoding 67, but just uses a string entry for 66 and since this is specifically to instruct others, it seemed unlikely it was just guesswork and so the implication was that in fact 66 did work as a string. I hoped/wondered if he could explain.

What I want to be able to do is see exactly what the server responds with. I'm trialling IPNetMonitorX (which you also recommend), but it's just not seeing the ACK which the server IS sending (according to the server logs). IPNMX simply waits a bit then places a big red X in the Ack column and the packet it 'prints' only contains what was entered to create the test. Have you come across why IPNMX can't see the ACK response? Any ideas?

I have made some changes to the DHCPing test tool and now have a very useful OSX command line tool to query a DHCP server and return all the additional fields I want to see. With this, I can report that edxley is partially wrong. Option 66 DOES need to be encoded. If it is entered simply as a string, NOTHING is supplied by the OSX DHCP server.

John Lockwood is basically correct that any option entered in bootpd.plist and which has a name as defined in the man page, can be entered as a string (or possibly array), but if you need to enter it using the option number, you have to encode it (with John's very excellent utility)...

EXCEPT

Option 60. This does not have it's own definition for bootpd.plist and needs to be entered as the dhcp_option_60 etc, but it CAN be entered simply as a string. Somewhat bizarre I agree, but it seems Apple's developers figured they knew it was a string and so deal with it correctly. Why they couldn't do that with the rest of the options I don't know, just lazy I guess. In fact why don't Apple simply use ISC's dhcpd which is a far more capable server and handles all this without having to jump through hoops to encode the options.

Anyway, use John's tool to encode as <data> ALL options entered by number, EXCEPT 60 which can be a string.

UKenGB wrote:

Why they couldn't do that with the rest of the options I don't know, just lazy I guess. In fact why don't Apple simply use ISC's dhcpd which is a far more capable server and handles all this without having to jump through hoops to encode the options.

Anyway, use John's tool to encode as <data> ALL options entered by number, EXCEPT 60 which can be a string.

Apple have used bootpd since they started and this dates way back to when Apple used NetInfo i.e. pre-OpenDirectory. Apple have heavily customised their implementation of bootpd to add support for NetBoot and NetInfo and so on. I agree it would be highly desirable that they switched to a far more modern DHCP server such as dhcpd. Something I have been repeatedly and so far unsuccessfully nagging Apple over is the fact they still don't provide an IPv6 DHCP server. While there is no IPv6 version of bootpd there is an IPv6 version of dhcpd.

On a similar front Apple's VPN server is equally antiquated and equally customised. Again it does not support IPv6 and worse still it only supports basic PPTP and L2TP both of which these days are considered extremely weak from a security point of view. Even more frustratingly Apple's own VPN server cannot be used to implement VPN on Demand on iOS and Mac clients. Apple have after my nagging upgraded their VPN client to the latest and greatest IKEv2 level including support for certificates but their VPN server is (mostly) a heavily customised version of Racoon v1. There is a branch of Racoon i.e. v2 which adds IPSec support (with certificates) and also supports IKEv2. I have been trying to encourage Apple to switch to either Racoon2 or StrongSwan5.

My guess is that Apple are stubbornly avoiding switching to more modern versions of both DHCP and VPN server software to avoid having to re-do the likely customisations they will need to do again. However I feel in the case of VPN the security concerns make this necessary, something I would feel proven by the fact they have done this on the client side. (iOS8 added IKEv2, and El Capitan also added IKEv2.)

I agree John. I think Apple are falling further and further behind. 😟

But we do have very good Facebook and Twitter integration so that's something to be grateful for. 😁

That last is pure sarcasm in case anyone's not sure.