Every so often I get sequences like this:
Sep 17 12:22:07 tippex wlan0: No ProbeResp from current AP 00:18:39:c0:5f:50 - assume out of range
Sep 17 10:25:31 tippex avahi-daemon[5117]: Withdrawing address record for 192.168.1.3 on wlan0.
Sep 17 10:25:31 tippex avahi-daemon[5117]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 192.168.1.3.
Sep 17 10:25:31 tippex avahi-daemon[5117]: Interface wlan0.IPv4 no longer relevant for mDNS.
Sep 17 12:25:32 tippex wlan0: Initial auth_alg=0
Sep 17 12:25:32 tippex wlan0: authenticate with AP 00:18:39:c0:5f:50
Sep 17 12:25:32 tippex wlan0: RX authentication from 00:18:39:c0:5f:50 (alg=0 transaction=2 status=0)
Sep 17 12:25:32 tippex wlan0: authenticated
Sep 17 12:25:32 tippex wlan0: associate with AP 00:18:39:c0:5f:50
Sep 17 12:25:32 tippex wlan0: Initial auth_alg=0
Sep 17 12:25:32 tippex wlan0: authenticate with AP 00:18:39:c0:5f:50
Sep 17 12:25:32 tippex wlan0: RX authentication from 00:18:39:c0:5f:50 (alg=0 transaction=2 status=0)
Sep 17 12:25:32 tippex wlan0: authenticated
Sep 17 12:25:32 tippex wlan0: associate with AP 00:18:39:c0:5f:50
Sep 17 12:25:32 tippex wlan0: RX AssocResp from 00:18:39:c0:5f:50 (capab=0x431 status=0 aid=1)
Sep 17 12:25:32 tippex wlan0: associated
Sep 17 12:25:32 tippex wlan0: switched to short barker preamble (BSSID=00:18:39:c0:5f:50)
Sep 17 12:25:32 tippex wlan0: association frame received from 00:18:39:c0:5f:50, but not in associate state - ignored
Sep 17 10:25:33 tippex avahi-daemon[5117]: Withdrawing address record for fe80::20e:2eff:fe66:d32f on wlan0.
Even though the AP _is_ there (and other devices can talk to it ok),
the only fix is to rmmod / modprobe the driver. This is usually enough
to get the device up and running again and it can send/receive IP packets.
However, already established tcp sessions tend to never get back to life,
so your long lasting ssh sessions die.
As I have a fixed IP address for the client, I see no reason why the tcp must
die just because the link level device is temporarily gone. IMO, it should
hang there waiting for a route to send it's packets, and a suitable route
_is_ provided when I modprobe/dhcpc the client.
Am I missing something?
/Anders
On Thu, 2008-09-18 at 16:19 +0200, Anders Eriksson wrote:
> Sep 17 12:22:07 tippex wlan0: No ProbeResp from current AP 00:18:39:c0:5f:50 - assume out of range
> Am I missing something?
For one, telling us which driver you're using.
johannes
[email protected] said:
> Oh and that works just fine for me, I do it all the time. ssh can take a long
> time to recover though, for some reason, so I tend to kill it (I do
> everything in screen anyway).
Hmmm, alright, I'll try to sit one out and see what happens.
How do I best trigger an out of range condition? Power cycle the AP?
/Anders
PS I assume the IP stack signals the tcp queue that there is an operational
and suitable link out of the machine when the driver is happy again, right?
Howcome I needs to rmmod/modprobe it?
On Thu, 2008-09-18 at 16:19 +0200, Anders Eriksson wrote:
> As I have a fixed IP address for the client, I see no reason why the tcp must
> die just because the link level device is temporarily gone. IMO, it should
> hang there waiting for a route to send it's packets, and a suitable route
> _is_ provided when I modprobe/dhcpc the client.
Oh and that works just fine for me, I do it all the time. ssh can take a
long time to recover though, for some reason, so I tend to kill it (I do
everything in screen anyway).
johannes
On Thu, 2008-09-18 at 21:16 +0200, Anders Eriksson wrote:
> [email protected] said:
> > Oh and that works just fine for me, I do it all the time. ssh can take a long
> > time to recover though, for some reason, so I tend to kill it (I do
> > everything in screen anyway).
>
> Hmmm, alright, I'll try to sit one out and see what happens.
>
> How do I best trigger an out of range condition? Power cycle the AP?
Not really. That would kill the AP's NAT table too which is probably a
bad idea. Though it might work. Take off the antenna ;)
> PS I assume the IP stack signals the tcp queue that there is an operational
> and suitable link out of the machine when the driver is happy again, right?
I'd guess so.
> Howcome I needs to rmmod/modprobe it?
No idea. I just tried rmmod/modprobe with an open ssh connection without
problems. Even wpa_supplicant picked up the new wlan0 device
automatically.
Oh if you get iw you can remove the AP STA... That would do it :)
johannes
[email protected] said:
> For one, telling us which driver you're using.
> johannes
On both rt2500pci and iwl3945 on an old PII-200 and an HP nc6400 laptop,
respectively. As it is on two drivers I figured it was driver unrelated.
2.6.26.3