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.