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. > > 5) do remain-on-channel from mac80211, but this doesn't address P2P GO > > synchronisation requirements > > > what are the unfulfilled requirements here? It would be a more special ROC because the driver would be expected to only start it when the P2P GO is available. This isn't the case for any other ROC, and my gut feeling is that requiring that in this special ROC would "pollute" the ROC API and a lot of people would forget about it etc. > > 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. > 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. > i think the "tx sync" (method 1) is good for sta mode, but it's less > suitable for ap mode. Totally agree. > 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? johannes -- 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
