> I think setting the key should not cause reassociation if > there is an association. That seems sensible. I actually think that while it's not associated, it should periodically try to associcate with what's currently defined (e.g. ESSID, fixed AP mac, key settings etc). Currently, if I do the following with mac80211/b43: $ # turn AP off or move into an area where you can't receive the AP $ pccardctl insert $ ifconfig eth1 up $ iwconfig eth1 key s:11111 $ iwconfig eth1 essid MUMBLFUTZ $ # turn AP on or move with the laptop/device into the vincinity of an AP ... then I won't get an association at all. Other drivers that I used in production during the last 5 years didn't show that behavior (orinoco_cs, wlags_h1_cs, wlags_h2_cs, madwifi). They associated on their own. However, as mac80211 is currently implemented, it assumes a "stationary" WLAN setup and doesn't cope well with scenarios where devices move. If it would cope better with such situations, then it would also cope with the first problem I reported. Because if it would periodically re-scan and try to associate, a later submitted or changed WEP key would be taken into account and association would have succeeded. - 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
