Comment 9 for bug 439723

That's right. I've also tried ath9k drivers from wireless-testing up to 2009-09-23. There hasn't been anything newer for ath9k that I'm aware of.

Possibly there are two bugs at work in this bug report. The NetworkManager background scanning issue also had an extremely bad effect on the ath9k stability, and that certainly was still occurring in early jaunty. I don't recall if you guys patched it or not; I patched my own build of NM to turn off background scanning.

The reason I still wound up turning off NetworkManager in my current setup is because, whenever the ath9k driver said "no probe response" it would tell NM that it was disconnecting. NM would then pass this on to Dbus and all of my other apps (like pidgin) would disconnect. But this app disconnect was unnecessary - the ath9k driver would successfully reassociate within a few seconds. I was tired of pidgin always logging out and logging in again, when it would otherwise just ride out the outage and continue as if nothing had happened once the driver reassociated. (There's a reason the TCP RFCs say hosts MUST NOT drop a connection in response to particular lower level error events. This completely invalidates TCP's timeout mechanisms, and that's just Wrong.) That's a separate issue, I just don't know if it's an NM bug (should NM wait before reporting the network is unavailable) or an app bug (should DBus/NM-aware apps treat the "network down" event as just advisory, and not act on it immediately). I guess I can file a new bug to discuss that.