In message <20031220144721.2C79F16FAC@mail.nitros9.org>, "Alan DeKok" writes:
>"Steven M. Bellovin" <smb@research.att.com> wrote:
>> >... dhclient isn't doing that if it can not reach the DHCP server?
>> 
>> Utterly certain -- I set the lease time to two weeks...
>
>  In low signal conditions, you're probably losing association with
>the AP.  i.e. The link layer goes down.  This is functionally similar
>to pulling a wireless card out of the PCMCIA slot on your laptop.
>
>  If you're using wireless authentication methods (EAP-TLS, TTLS,
>etc), then after losing association, you can't get back onto the
>network until you re-associate and re-authenticate.
>
>  If you're not using wireless authentication, then you still have to
>re-associate, and you'll get your network back once that happens.
>
>  I'm not sure how possible/useful it would be to mark the loss of
>association as a "temporary" network failure.  There's always a chance
>that when you re-associate, you'll get a new IP.
>

Hmm....  It's not an authentication issue -- I don't run EAP in my 
house -- but I see your point.  But you raise an interesting 
architectural point: how to manage non-static connectivity.

Windows does a pretty good job of that these days -- if a link layer 
comes up or down (inserting or removing a wireless card, connecting or 
disconnecting an Ethernet cable, the laptop waking up after 
suspending, etc.) it restarts its dhcp client.  I'd love to be able to 
do something similar on NetBSD, including caching authentication 
credentials if possible and necessary.  Right now, I restart dhclient 
from /etc/apm/resume, but that doesn't handle the other cases.  I 
wasn't even aware of the situation you mentioned.

		--Steve Bellovin, http://www.research.att.com/~smb