WLAN: towards a solution for the roaming freeze

Andy Green andy at openmoko.com
Fri Jan 23 11:34:49 CET 2009

Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> If wpa_supplicant's automatic up and down action when it loses
|> association does that and hard resets everything on the module and
|> stack, it might avoid us having to do time consuming and intricate
|> cartography on the completely dark firmware landscape.
| Yes, but you don't always get a clear indication of trouble. E.g.,
| the system may be 100% convinced we got a good association, yet no
| traffic flows. Or just enough traffic to fool the heuristics of
| your trouble detector (again, with the help of frequency leakage).
| In any case, some cartography is unavoidable as long as the
| firmware isn't living up to its promise of shielding us from all
| the intricacies of wireless networking. If not of the firmware
| itself then of its behaviour ...

Well it can be avoided OK by not doing it, I am just wondering what it
leads to if the firmware is broken for some things and we don't have a
way to update it.  There's no point altruistically researching Atheros
firmware bugs if it won't pay off for us?

It sounds like this is fairly uncommon situation, in the case where we
claim a good association but nothing works, I guess the user will hit on
NetworkManager or whatever icon and try to reconnect.  It's what I would
do anyway.

In that case it will be good for us and the user if the impact of that
takes down the stack completely and resets the module to unblock any
firmware trashing that is happening in there.  It has the advantage it
should clear any kind of quirk in there, even ones we don't know about yet.

This is why I think it would be good to tie module in and out or unbind
with ifup and ifdown type of action regardless of what else we're hoping

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the devel mailing list