> > > 4) Is the association expected to survive a up->down->up sequence? If > > > not, then we should be sending NULL SIOCGIWAP event whenever dev_close() > > > gets called. > > > > No, it's not, yes, we probably should send that event somewhere. Is it > > ok to send the event while not associated? > > Yeah, there's no ordering or pairing guarantee for SIOCGIWAP events > since there isn't an association transaction model with WEXT. Yeah, true. You can either stick it right into ieee80211_stop, make a new mlme-stop function that is called from there, or maybe do it when the AP's sta_info struct is removed? > > > 5) mac80211 requires the device to be down when changing modes. That's > > > fine; but requires a patch to wpa_supplicant to handle this. This would > > > cause failures when switching AP that were different modes from NM. > > > See: > > > > > > http://lists.shmoo.com/pipermail/hostap/2008-June/017894.html > > > > Don't understand. How can you switch to an IBSS AP? :) > > Sorry, when switching from BSS -> IBSS, like picking an IBSS from the > NetworkManager menu while you're connected to an AP. Or, creating a new > IBSS while connected. Ok, but that means you disconnect so you lose all configuration anyway. > > It's probably fairly easy to remove this restriction because they all > > use ieee80211_if_sta internally (sta, ibss, mesh) but since I don't care > > too much about IBSS and see mesh as being quite different, I have no > > motivation to try (and test) this. > > I think it's fine to leave it as-is. At least prism54 required the > interface to be !IFF_UP while changing modes, and I think madwifi has > required this too at some point. This can be handled in the supplicant, > Jouni and I have already worked out what should be done and I'm going to > update the linked patch. Sure. As far as I understand, even if mac80211 would change in the future the patch Jouni asked for would then not down the interface. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
