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

Help needed defining DHCP option fields in 10.5 Server

According to the Unix man page for bootpd in Mac OS X 10.5 Server, the Apple DHCP server (actually called bootpd) now uses a configuration file called bootpd.plist which like other plist files is actually an XML formatted file.

Furthermore according to the same man page bootpd now (at long last) supports defining additional optional DHCP fields. One of the most common requirements needing these additional DHCP option fields is if you have a VoIP phone system. You can view this man page by typing *man bootpd* in the Terminal in both Mac OS X 10.5 Server and Client.

I would like to define several additional DHCP option fields to support our (Mitel) VoIP system but unfortunately I am getting errors from the DHCP server when I try this.

According to the Unix man page one should define additional properties using a name like

dhcp optionoptionnumber

e.g. dhcp option128

Based on other fields in the bootpd.plist file this to me suggests one should add a line like so

<key>dhcp option128</key>

and then again based on other entries in the standard bootpd.plist file a second line like so

<string>192.168.1.10</string>

making a total of two lines like so

<key>dhcp option128</key>
<string>192.168.1.10</string>

However this produces errors in the log like this

Dec 3 15:16:49 xserve1 bootpd[[67218]]: subnets: Failed to convert 'option_128': Failed to convert from string to opaque

The Unix man page suggests bootpd should be able to automatically convert the value inside the string section to whatever is needed to be sent across the network but obviously it is failing.

The only full example in the Unix man page looks like this

<string>dhcp option128</string>
<data>
AAqV1Tzo
</data>

but I think this is at least partly wrong since the first line should be using <key>. If I do try using <data> for the second line (in my own example) then the error does go away but without knowing how to convert a TCP/IP address to the right data value the result will be wrong.

Help!!

I want to be able to define five DHCP option fields, two of which will contain a TCP/IP address, one an ASCII string, and the other two simple integer numbers.

PowerBook G4, Mac OS X (10.5.1)

Posted on Dec 3, 2007 9:07 AM

Reply
45 replies

Mar 7, 2008 5:58 AM in response to John Lockwood

It looks like the problem is that for any extra DHCP option fields you define, you must use the data format and not a string or integer format.

So

<key>dhcp option128</key>
<data>
AAqV1Tzo
</data>

would be a hypothetically valid example.

According to the previously mentioned Unix man page, the Apple bootpd server is supposed to be able to automatically translate from string or integer formats to "the binary, network order numeric value".

In the case of ordinary DHCP fields (e.g. dhcp ldapurl) this does work but it does not work for DHCP option fields. I believe (although the man page does not make it clear) that the reason for this is that the fields it does work for are 'well known fields' and their format is therefore known in advance and the Apple bootpd server therefore has been specifically written to translate to the known required format. Whereas for a DHCP option field which by definition is optional and up to the user, it obviously cannot know in advance what the format is supposed to be.

So if this is the case, as things stand the only way we would be able to successfully define DHCP option fields using the Apple bootpd server would be if we could code the information to the "the binary, network order numeric value" format.

I have no idea what the algorithm is to translate to this format. It does not appear to be decimal or even hexadecimal, it might be something like BASE64 encoding (as used in encoding email attachments). I need to do this for three types of information.

A text string,
a TCP/IP address,
and an integer value.

e.g.
"Mitel IP Phone"
10.1.2.3
6

If anyone knows what the algorithm is then we could either manually encode the data, or write a little script to do the conversion, we could then use the correct data values.

However I would also point out that Microsoft manage in their DHCP server do let you define DHCP option fields in a human friendly manner, as does the standard Linux bootpd and dhcdp. How ironic that Apple cannot do this.

Mar 12, 2008 2:42 PM in response to John Lockwood

I am about to embark on this path as well. Our organization has a shiny new Mitel 3300 and we are likely setting the same options codes as you.
Currently, we're using the DHCP server built into our Vicomsoft router which will soon be repurposed. It's settings are as follows:
option 128 - type:IP - 172.16.16.2
option 129 - type:IP - 172.16.16.2
option 130 - type:ASCII - MITEL IP PHONE
option 132 - type:Long - 2
option 132 - type:Long - 6

The only step I've taken so far on our Leopard server is to look at the bootpd.plist file with the Property List Editor application. If I have any success, I will post here soon.
Has anyone else made any progress?
Regards,
Lyle

Mar 13, 2008 5:57 PM in response to Lyle Millander

Lyle Millander wrote:
I am about to embark on this path as well. Our organization has a shiny new Mitel 3300 and we are likely setting the same options codes as you.
Currently, we're using the DHCP server built into our Vicomsoft router which will soon be repurposed. It's settings are as follows:
option 128 - type:IP - 172.16.16.2
option 129 - type:IP - 172.16.16.2
option 130 - type:ASCII - MITEL IP PHONE
option 132 - type:Long - 2
option 132 - type:Long - 6

The only step I've taken so far on our Leopard server is to look at the bootpd.plist file with the Property List Editor application. If I have any success, I will post here soon.
Has anyone else made any progress?
Regards,
Lyle


Yes, I have a Mitel 3300 as well and therefore do want to use the same options. Currently I have to manually configure each new phone. 😟

The problem is that Apple's Mac OS X 10.5 DHCP server doesn't seem to work for DHCP option fields unless you use the data format. I tried String and Integer and it barfed over them.

Everybody and his dog seems able to do DHCP servers better than Apple. 😟

I appreciate the offer of you posting (hopefully) successful results and how to do it.

Mar 14, 2008 4:52 AM in response to rkovelman

rkovelman wrote:
So basically you want to have 1 gateway / router that does different VLans? Is that correct? When I did VOIP I used a different DHCP server for that.


When a VoIP phone boots, it has (if not using a static configuration) no knowledge of what VLAN it is supposed to use or what the address of the VoIP server is. It would typically use DHCP to learn this. The DHCP server would reply with the VLAN it should use, and the IP address of the VoIP server (which will also be on the other VLAN). The VoIP phone then switches to the other VLAN contacts the VoIP server gets its own DHCP client IP address for that VLAN and becomes active.

The default VLAN is typically the 'ordinary' computer VLAN.

So in reality, the (in this case Mac OS X) DHCP server is only serving the default computer VLAN, the VoIP DHCP server would serve the VoIP VLAN.

Note: It would be possible to configure the Mac DHCP server to serve two VLANs by using two Ethernet connections, each of which is configured to use a different VLAN. However as the Apple DHCP server cannot even manage to do one network properly this would not be a lot of help!

Mar 17, 2008 7:56 AM in response to Lyle Millander

Lyle Millander wrote:
I am about to embark on this path as well. Our organization has a shiny new Mitel 3300 and we are likely setting the same options codes as you.
Currently, we're using the DHCP server built into our Vicomsoft router which will soon be repurposed. It's settings are as follows:
option 128 - type:IP - 172.16.16.2
option 129 - type:IP - 172.16.16.2
option 130 - type:ASCII - MITEL IP PHONE
option 132 - type:Long - 2
option 132 - type:Long - 6

The only step I've taken so far on our Leopard server is to look at the bootpd.plist file with the Property List Editor application. If I have any success, I will post here soon.
Has anyone else made any progress?
Regards,
Lyle



I have been communicating with Apple Developer support about this issue and they confirm that the problem is that for DHCP option fields, it cannot workout itself what format they are supposed to be, which is why only the "data" type works. They have written a small command line utility for me to test which takes an input value, a specified type, and converts it to the corresponding data value.

I have tested this and did find one bug but have still been able to generate the DHCP options I need to support Mitel VoIP phones.

Based on your above information here is the equivalent for your setup.

<key>dhcp option128</key>
<data>
rBAQAg==
</data>
<key>dhcp option129</key>
<data>
rBAQAg==
</data>
<key>dhcp option130</key>
<data>
TUlURUwgSVAgUEhPTkU=
</data>
<key>dhcp option132</key>
<data>
AAAAAg==
</data>
<key>dhcp option133</key>
<data>
AAAABg==
</data>

Mar 17, 2008 10:39 AM in response to Lyle Millander

Lyle Millander wrote:
That's great news John. Thanks for posting that. It was apparent I wasn't going to be successful and you just saved me a bunch of time.
Did your contact indicate that this utility would be made publicly available once its golden?

Regards,
Lyle Millander


At this stage it is not clear what the final solution will be. Personally, I think the best (from a customer point of view) solution would be for "Server Admin" to be modified to add the ability to define DHCP option fields, and for it to itself do the conversion.

The alternative approach would be for this utility (when bug fixed) to be included and the Unix man page to be updated to refer to it.

I am awaiting a further email from them after having emailed them my results and suggestions as to a final solution.

Apr 1, 2008 9:16 AM in response to John Lockwood

Thanks again, John!

I entered the data into the bootpd.plist file. I haven't started DHCP yet, as I have to somehow import all our static IP maps - that's next.
Interestingly, when I opened the file with Property List Editor, the entered data looked a bit different:
dhcp option128 ... Data ... <ac101002>
dhcp option129 ... Data ... <ac101002>
dhcp option130 ... Data ... <4D495445 4C204950 2050484F 4E45>
dhcp option132 ... Data ... <00000002>
dhcp option133 ... Data ... <00000006>

128 & 129... AC=172, 10=16, 10=16, 02=2 | there's my IP
130... HEX ASCII for "MITEL IP PHONE" | obvious
132 & 133... obvious

So, using Property List Editor and a hex converter like: http://www.vortex.prodigynet.co.uk/misc/ascii_conv.html

You could get by until Apple has a better solution.

Apr 2, 2008 3:10 AM in response to Lyle Millander

Doh!

Well spotted. I use exactly the same site for hex/ascii conversion.

All though in retrospect, the idea of using Property List Editor to edit this plist file makes sense, it was not until we already had a valid dhcp_option entry defined that we would have been able to see that it could show them as simple hex values.

I am not sure using Property List Editor would however be a suitable solution for everyone as it is not a standard installed item (it comes with the Developer tools).

I don't know why Apple didn't simply use hex for data values in any case.

Apr 16, 2008 3:13 PM in response to John Lockwood

Ok im in the same boat here, and reading through this thread and a few RFC's i think i have a pretty good handle on the problem.

I tried adding:

<key>dhcp option150</key>
<string>192.168.2.20</string>

And this should have worked

However we found out that due to a bug it cant translate the string variable into something it can use. So we know we need to use

<key>dhcp option150</key>
<data>XXXXXX</data>

Except we don’t know what type of data the xserve is looking for in place of XXXXXX.

My guess is Network Byte Order, however i don’t know how to convert an IP into it.

so John Lockwood, how are you doing the conversion from 172.26.26.2 into rBAQAg== ? what is that?

Help needed defining DHCP option fields in 10.5 Server

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