On Tue, Jun 26, 2012 at 1:41 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2012-06-26 at 13:09 +0300, Eliad Peller wrote: > >> > With multi-channel, one problem that we get is managing the channel >> > timing for authentication/association. We'll have bound the channel >> > context (once we have that) before we even send a frame of course, but >> > setting up the timing as to when to use the channel is very hard, in >> > particular for connections to P2P GOs that might potentially be asleep. >> > >> the other scenario we should have in mind here is the AP side - making >> sure we'll be able to auth/assoc a new station. > > Yes, we should keep that in mind, but I have a feeling that we should > treat it separately. It's quite different as mac80211 is doing a lot > less -- for example, mac80211 is managing retries, comeback timeouts, > etc. in the managed case. > i guess it makes sense. i just don't like it being managed in multiple places (userspace for ap, kernel for sta). >> > I haven't been able to come up with any other ways, and here we really >> > don't have much of a choice -- #1 is the only thing that seems sane to >> > me. Thoughts? >> >> our current approach is making the kernel part as simple as possible, >> and let userspace handle the channel management. >> before authentication (or after getting auth request in the ap case) >> the supplicant requests the kernel to "give priority" to a specific >> vif. it's up to the low-level driver to decide on the right way to do >> it (internally we implement it with ROC on the specified vif). > > I'm pretty much happy with that for the AP case, but given how much > mac80211 really manages for auth/assoc I don't think it makes sense in > the managed case. > i think that's true for open networks, but for encrypted ones the EAPOLs are not handled by mac80211, which pretty much complicates the flow. >> the con here is that this might result in the channel being reserved >> for a pretty long time (retransmits, etc.), but that's why we refer it >> as setting "priority" rather than actual channel reservation. if the >> fw has to do other things (e.g. beacon on each beacon interval) it >> will do it, even though we asked it to ROC on a different channel. > > That seems highly implementation-dependent :-) > The point with that though is that I think it shouldn't be necessary to > have a firmware implementation that does this. > well, i'm not really sure whether our fw is doing it, but that was the plan :) >> also, when waiting for EAPOLs after association you might have to >> reserve the channel for a pretty long time anyway (since you still >> can't enter ps, and some APs don't send the first EAPOL immediately). > > Yeah, but you might only want to wait a little bit and then stop doing > ROC and actually enter PS mode if the AP is really slow, etc. That can > pretty much be managed from the STA state though since once you're > associated you're past the bit where mac80211 is doing a lot? > you can't enter ps while you are not authorized (it's probably not forbidden by the spec, but i'm pretty sure some APs won't like it). managing it from the STA state doesn't make much sense to me (why add another management point?), and if you're going to handle it from userspace, well... just do it from the beginning :) Eliad. -- 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
