Censornet - internet filtering on your terms

Problem with WPAD, Windows 2003 DHCP and Mac OSX clients

July 29, 2011 • Customer Services       

Synopsis

Article

The problem is due to an incompatibility between Microsoft DHCP and OSX' WPAD implementation.

The WPAD protocol first tries settings supplied in DHCP - option 252 - and then falls back to trying to resolve through DNS if that fails (i.e. the default of http://wpad/wpad.dat.)

Trouble is, when Microsoft's DHCP implementation (and possibly other implementations that interpret the RFC the same) supplies a string in a DHCP option, it null-terminates it. The DHCP RFC says that this "should" not be done (i.e. it's permitted but not recommended.) However, the RFC also says that clients that receive options "should" cater for the possibility of the string being null-terminated.

So what ends up happening is that neither Windows Server or OS X plays ball - Windows passes OS X a null terminated string and OSX interprets it literally, appending a double-escaped null character to the URL (%25 in a URL normalises to the "%" character, and %00 is the null character. So %2500 = %%00 which gets interpreted as null.

The solution is to add a ? to the end of the 252 wpad string in dhcp so it looks like: http://wpad/wpad.dat?

This article was paraphrased from a thread found here http://forums.macrumors.com/showthread.php?t=991781 and thanks go to Dustin Fisher at St John's Grammar School, SA, Australia for finding and submitting it.

Related articles