WPAD and DHCP Servers

[Robert Sneidar]

Hi Trevor. See http://www.comptechdoc.org/independent/networking/guide/netdhcp.html 
  for a basic treatment of the issue.

You use the global broadcast address for DHCP which is 255.255.255.255  
as the source and 0.0.0.0 as the destination. (I have seen some DHCP  
servers use the subnet broadcast address which would be 255.255.0.0  
for a class B subnet, but it proved to be problematic.)

DHCP is a broadcast protocol, given the fact that you don't actually  
have an address on the subnet yet. You would issue a DHCPREQUEST on  
destination port number 67 using 68 as the source port. Clients always  
use 67 and servers always use 68.

The server(s) reply with a DHCPOFFER. The client will accept the first  
lease offered (note there can be multiple DHCP servers on a segment,  
but it is usually a bad idea). The client will respond with a  
DHCPREQUEST but this time with the IP address of the server that  
offered as the source address. This allows the other servers if any to  
retract their offers and mark the address as unavailable so they do  
not offer it to another client. The server replies with a DHCPACK (or  
DHCPNAK if rejected). If the client cannot get a lease the TCP stack  
will shut down and cease to function.

Now comes lease renewal time. Halfway through the lease time granted  
by the server, the client is supposed to issue a renewal in the form  
of DHCPREQUEST with the IP address of the server that granted it (same  
as before). If it fails to get a response, it tries again in half the  
remaining lease time. At some point (I think 87.5% of lease time) the  
client is supposed to start from scratch, which can occur if the  
client or server was offline (or sleeping) during the lease renewal  
window, or in the case of a busy network.

I have experienced situations where the server was responding to so  
many requests, that many clients were getting to the reset stage and  
resetting their TCP stacks and starting the process over again. This  
occurred because because the lease time was set too short for that  
size network. Obviously this would have an adverse affect on protocols  
requiring a persistent connection.

I thought that having the server grant reserved leases using the  
hardware address to get the same IP address every time would solve  
this, but nay! The adapter will reset and start from scratch even if  
the address it ends up with is the same address it had before.

<sigh> DHCP seems like a good idea at first, and can be, but beware of  
this tendency to reset. NEVER use DHCP on servers, or any device that  
you ned to connect to remotely, such as managed switches, IP cameras,  
routers etc.

Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM

On Jun 27, 2008, at 5:10 PM, Trevor DeVore wrote:

> Hi,
>
> In my quest to come up with a library that plays nicely with proxy  
> servers in as many situations as possible I'm working on an  
> implementation of the WPAD protocol for Revolution. When looking for  
> the wpad.dat file you first ask for option 252 from a local DHCP  
> server and the server will return a string pointing to wpad.dat. If  
> that doesn't work then you move on to DNS and look for the wpad  
> subdomain using the host name as the starting point.
>
> I think I have the DNS portion figured out and I've coded an  
> implementation using 'the hostName' and hostNameToAddress() (not  
> tested yet).
>
> I'm a little lost when it comes to the DHCP however. I am assuming  
> that I should try to contact the DHCP server as defined in the  
> network settings. On my local network that is 192.168.1.1. What I'm  
> not sure about is how to send a request for option 252.
>
> Is there anybody out there who is familiar with WPAD, DHCP and how  
> to talk to a DHCP server an could share some insight?
>
> Thanks,
>
> -- 
> Trevor DeVore
> Blue Mango Learning Systems
> ScreenSteps: http://www.screensteps.com
> Developer Resources: http://revolution.bluemangolearning.com
>
> Email has been scanned for viruses by Altman Technologies' email  
> management service - www.altman.co.uk/emailsystems
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution