Subject: Re: default route going away...
To: Alan DeKok <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 12/20/2003 10:23:05
In message <20031220144721.2C79F16FAC@mail.nitros9.org>, "Alan DeKok" writes:
>"Steven M. Bellovin" <email@example.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