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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
