On Tue, Jun 26, 2012 at 1:41 PM, Johannes Berg
[off-list ref] wrote:

On Tue, 2012-06-26 at 13:09 +0300, Eliad Peller wrote:

quoted

quoted

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).

quoted

quoted

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.

quoted

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 :)

quoted

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.