On Monday 12 January 2009 19:34:37 Werner Almesberger wrote: > Hmm, or at least "vague" :) > > > But as far as I > > understand the semantics, SIWESSID is supposed to associate to the > > service (except in a few cornercases). > > So IMO it should fail, because without a transmitter, we can't handshake a > > connection. > > My understanding is that SIWESSID is allowed to return successfully > without establishing an association. The MAC keeps on trying on its > own.
Yes, that's the problem with wext. Nobody knows for sure. :) > > Yeah, as I said. Current mainline drivers don't mess with state at all. > > Yes, that's what I used as my baseline so far. I.e., that rfkill is > not allowed to do damage that goes beyond what happens anyway when > you have a complete loss of signal. > > I also noticed that the - otherwise very detailed - documentation of > rfkill leaves this aspect completely open to interpretation. I think that's due to the fact that only softmac devices implement rfkill for now. In this case the actual driver keeps hardly any state. It's all handled by the upper layer, which is mac80211 in most cases. And as mac80211 and rfkill don't know about each other, the state is simply kept dangling and the supplicant and part of mac80211's detection mechanisms will clean up the mess after a timeout. It's actually planned to integrate rfkill into mac80211, so softmac drivers don't have to care about rfkill at all anymore. But nobody implemented that, yet. But, exactly the same questions will raise up then. Drop mac80211 state or not... Currently it's just dangling, so... > Perhaps we should resume this on linux-wireless, since I guess that's > where all the rfkill folks hang out. Yes please do this, if you want. -- Greetings, Michael. _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
