Windows leases through a PC reset

[Eric Kollmann]

Try 2

I've been doing a lot of research on DHCP for a research paper, so
this is where most of my info is coming from.  This specific issue you
are asking about isn't something that I looked at a lot.

It is really going to depend on your OS and what all goes down.  Some
OS's (or could be driver specific, haven't looked closely at this, but
I assume it is OS) when the link status on the NIC changes it will do
a INIT again, doing a DHCP DISCOVER and DHCP REQUEST.

As has been noted in a few of the other posts, some OS's will request
the same IP they had before (DHCP Option 50), where others will do
DISCOVER/REQUEST asking for any available address.  Windows machines
as a whole seem to all do a request for their previous IP address,
other OS's milage will vary.

If the lease is about to expire (50% of the lease time or less), the
OS should continue to use that IP even though it can't get an OFFER
from the DHCP server, should, most OS's as I recall did, not sure if
there were any that didn't, would have to go back and look.

If the lease has expired (and the machine is still up and running),
now it becomes a little more interesting in that some will continue to
use an expired lease without any care that it is expired (windows 95
for example and some linux distro's - they only care when they
reboot), where others will do what they are supposed to by RFC (2131
section 4.4.5 among others).

If the machine reboots and no DHCP server is available each OS does
its own thing here too.  If the lease it had was still good, some will
continue to use it (could cause issues if they are no longer on the
same network, which I think was also mentioned in another post).

Windows (old 9x) tries 3 or so times, waits 5 mins, tries again 3 or
so times, waits 5 mins, etc, etc.  NT/2000 and I believe XP do the
same basic thing.

Some of the linux distro's I tried/tested had the same basic behavior,
trying a few times, waiting a little bit, trying a few more,
continuing on until the end of time, but others would try a set number
of times, if they didn't get a response they never seemed to try
again.  Where this could get you in trouble is if they have rebooted
while the Server is down, tried their X number of times, given up and
then the DHCP Server or WAN link comes back up.  Pretty much have to
reboot or restart the network stack to get it to query again.

Anyway, all of the above just to say, it really depends on the OS.
Most modern OS's seem to continue to retry and not to sit on leases
they no longer own, but that isn't always the case.

On 5/8/07, SCOTT BURGIN <SBURGIN at salliemae.com> wrote:
> to be clear ( I don't think my original post was after I read it myself ) - the situation is one where the DHCP
> server is up and operational at a corporate headquarters - a remote PC off the corporate WAN is cut off from the headquarters (say a WAN outage has occurred).  What happens what that PC reboots and can't "see" the DHCP server ?
>
> I find Simon's observation that it may check other things (i.e. a ping of its last known default gateway) interesting.
> In the case described above, the PC would in fact be able to ping its default gateway it last had (say a local layer 3 switch), but not be able to talk to the DHCP server.  We're going to test this situation - was curious what others may have seen in this situation...
>
> >>> Simon Hobson <dhcp1 at thehobsons.co.uk> 5/8/2007 2:24 PM >>>
> Glenn Satchell wrote:
>
> >  >Basic question - RFC aside - does anyone have real world knowledge
> >(personally
> >conducted testing preferred) of whether a Windows machine will
> >continue to use a
> >valid ISC provided lease through a power down/power up sequence when the DHCP
> >server(s) are unreachable ?  Does the version of the Windows OS change the
> >result ?
>
>
>
> >I just tried this on my test network. Client is Win XP Home SP2. This
> >should be very easy to re-create on a test network with a single dhcp
> >server and however many clients you want to try.
> >
> >These are the snooped packets from the PC as it booted. Note the last
> >two are from the correct IP address.
> >
> >OLD-BROADCAST -> BROADCAST    DHCP/BOOTP DHCPREQUEST
> >OLD-BROADCAST -> BROADCAST    DHCP/BOOTP DHCPREQUEST
> >OLD-BROADCAST -> BROADCAST    DHCP/BOOTP DHCPREQUEST
> >dhcp-14-249.uniq.com.au -> BROADCAST    DHCP/BOOTP DHCPINFORM
> >dhcp-14-249.uniq.com.au -> BROADCAST    DHCP/BOOTP DHCPINFORM
> >
> >Running ipconfig /all on the PC after booting shows all the settings
> >are still intact. Note that it is possible to configure dhcp to supply
> >options that will cause Windows to release the lease when shutdown, but
> >this is not the default behaviour in any release.
>
>
> I've seen this before on the network at my last job - DHCP was down
> for some reason and we didn't notice until the Mac users couldn't do
> certain things.
>
> I also suspect that the clients do more than just "can't reach a DHCP
> server, carry on with last address" - I think they may well check to
> see if the default router is the same (or something similar) to see
> if they are actually still on the same network, and failing that then
> they'll self-assign a link-local address. I think there's an RFC for
> this.
>
>
>
> As an aside a Windows PC is VERY sticky with it's address. Even if
> you release the address, it will still include it as the requested
> address in a future discover. It will even request the last static
> assignment when you change from static to dynamic.
>
> I discovered this when diagnosing a problem at a customers site. They
> have a large campus with multiple buildings all linked by gigabit
> ethernet. We had the network management set up a VLAN from the
> customers office to the reception desk in one of the other buildings
> - and the PC would NOT work, and I couldn't figure out why.
>
> My PowerBook got an address straight away which made me even more
> puzzled. Eventually by packet sniffing I figured that their DHCP
> server (Windows) wasn't authoritative and so never NACKed the request
> for a bad address (picked up from the previous network the PC was on)
> that the PC kept asking for, so the PC just never stopped requesting
> it ! In the end I statically configured the PC with a valid address
> for the network, then switched it back to dynamic - hey presto, that
> address now given by DHCP.
>
>
> This E-Mail has been scanned for viruses.
>
>
>
>