On Tue, Jun 26, 2012 at 2:18 PM, Eliad Peller <eliad@xxxxxxxxxx> wrote: > 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 also think managing this in multiple places can get messy. I slightly prefer Eliad's approach with userspace giving the ROCs, since it sees the bigger picture. But all userspace changes are reflected in the STA flags in kernel, so we can do STA + AP from kernel mode as well. Can you give a bit more info on the Tx-sync approach, for the uninitiated? I'm also thinking that maybe we could somehow treat the sleeping-GO as a special case (maybe with some special code and a HW flag). Right now I'm not sure the wl12xx FW even supports it. Arik -- 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
