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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
