On Mon, 2009-07-13 at 21:14 +0200, Johannes Berg wrote: > On Mon, 2009-07-13 at 15:10 -0400, Dan Williams wrote: > > On Mon, 2009-07-13 at 19:54 +0200, Johannes Berg wrote: > > > On Mon, 2009-07-13 at 13:53 -0400, Dan Williams wrote: > > > > > > > Mainly because there's no way to tell WEXT drivers to "stop whatever > > > > you're doing and just be idle"... > > > > > > > > The supplicant clears out the keys on TERM anyway, and in some cases > > > > (iwlagn) the driver will keep trying to reassociate internally > > > > > > Seems unlikely, ITYM ipw? > > > > Nope. I saw this behavior with iwlagn (both 3945 and 4965) when I was > > doing all that hidden stuff back in April with 2.6.27 kernels. Might be > > different in very recent kernels? > > That doesn't sound right, to the best of my knowledge the _driver_ has > no chance to try to associate, and mac80211 didn't. For some reason it did. I can't figure out why it would keep doing so, but the supplicant was dead, and the driver would try to reassociate every time the AP kicked it off wtih "AP denied association (code=13)" becuase the supplicant already cleared the keys and IEs but not the SSID. All because we can't tell WEXT to just stop doing anything and sit there. Dan -- 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
