Subject: [dhcwg] Question about DHCP renew

From: Vijay Nain <[email-masked]>
Date: Thu, 20 Nov 2003 13:36:03 -0800

Hi,

My question is specific to the DHCP state machine as defined in RFC 2131.
If you feel this is the wrong place to post this question, please accept 
my apologies, and ignore this mail.

I'm working on an 802.11 project, and notice that Win2000 wireless 
clients do the DHCPDISCOVER (i.e. pretty much start the state machine 
from scratch), when the radio link is kept down for a period of over 10 
seconds and then brought up again. The clients had earlier obtained an 
IP address correctly, and had IP connectivity to the world. The lease 
expiration time (or half of it) was significantly in the future in all 
these cases.

 From the state machine in the RFC, only a lease refresh timeout should 
cause the clients to do a renew; it does not look like anything else 
could force the DHCP client out of the 'bound' state.

However, as I mentioned above,  whenever I bounce the radio link on the 
access point long enough, it looks like the DHCP client starts from scratch.

Can anyone comment as to whether this is standard DHCP behaviour (of 
restarting the SM) when the link has been observed to be 'restarted' 
with a considerable interval in between)?

Thanks in advance,
Vijay

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Nov 2003 15:50:28 -0600

On Nov 20, 2003, at 3:36 PM, Vijay Nain wrote:
> However, as I mentioned above,  whenever I bounce the radio link on 
> the access point long enough, it looks like the DHCP client starts 
> from scratch.

This client is broken.   It should probably do a DHCPREQUEST in 
INIT-REBOOT to solicit information that the lease has changed, but 
going to the INIT state is not correct here.

There's some work going on on a document that addresses these issues - 
draft-ietf-dhc-dna-ipv4-04.txt.

---

From: "Kevin A. Noll" <[email-masked]>
Date: Sun, 23 Nov 2003 19:24:06 -0500

Hmmmm....

Is this client *really* broken? I didn't think the client was 
*required* to come back in INIT-REBOOT state.

In any case, this behavior is not unusual. The WLAN drivers
that I have run into frequently treat a loss of carrier the
same as a loss of link in a wired network (e.g. someone pulled
the cable).

In this case the OS (especially Win 2K) may choose to drop all 
the configuration associated with the NIC and when it regains 
the carrier (i.e. link) it starts over as if the NIC had just
been brought up from scratch.

I don't *think* (please correct me if I'm wrong), but I don't 
think DHCP specifies in that kind of detail what should happen 
on link loss/acquisition.

I do agree that it would probably be best if it started in 
INIT-REBOOT, but I don't think it's required (again, correct me
if I'm wrong).

I read draft-ietf-dhc-dna-ipv4-04.txt for the first time just
before sending this message. Based on Mr. Aboba's recommendedations
INIT-REBOOT would be the correct behavior. However, I don't think
the current RFC's actually require this behavior.

--kan--

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Ted
Lemon
Sent: Sunday, 23 November, 2003 4:50 PM
To: Vijay Nain
Cc: [email-masked]
Subject: Re: [dhcwg] Question about DHCP renew

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Nov 2003 19:03:13 -0600

> *required* to come back in INIT-REBOOT state.

No, it's not required to come back into INIT-REBOOT state, but 
according to the spec it's not really supposed to change states at all 
in this case.   If we had accounted for network link state transitions 
in RFC2131, I think the right accounting would have been to return to 
INIT-REBOOT, not INIT, and there seems to be general agreement that 
this is so.   Broken means "not working."   I would say that in this 
case, the client is not working, in the sense that a link state 
transition kills off existing connections, so yes, it is broken.