On Mon, Jun 25, 2012 at 7:05 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > Hi all, > > Some of us have discussed this before, but I wanted to get some wider > dissemination ... > > 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. > 5) do remain-on-channel from mac80211, but this doesn't address P2P GO > synchronisation requirements > what are the unfulfilled requirements here? > 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). 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. i think the "tx sync" (method 1) is good for sta mode, but it's less suitable for ap mode. 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). 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
