On Wed, 2014-02-05 at 15:37 +0100, Michal Kazior wrote:
> If the decision must be made at the beginning and you want mac80211 to
> start STA CSA then GO-follow-STA is impossible.
>
> What could work here is single-command-multi-interface channel switch
> IF you make STA CSA a userspace thing.
>
> If you want to keep STA CSA not a userspace thing you cannot make any
> decision at the start in cfg80211 and you must move the decision to
> the driver itself (or firmware, actually). In that case cfg80211
> remains highly reactive and you cannot guarantee interface combination
> state consistency at all times because driver may be incapable of
> notifying cfg80211 in a sane way about interface state changes (e.g.
> due to firmware design/ HW limitation/ cfg80211 locking issues/
> synchronization).
In the case of full-MAC drivers we pretty much have to assume that they
will correctly enforce their own interface combinations in the firmware
anyway, we can't even check in connect() today, so that doesn't seem
like a big issue.
I don't see how this all makes it impossible though, it seems you could
still do:
1) receive CSA from AP on STA interface
2) reserve a 'temporary' channel context that doesn't count towards the
limits,
since it'll be switched
3) notify cfg80211/userspace of the pending switch
4) when the time comes to do the switch, do a final capability check,
and
disconnect from the AP instead if it fails
If you have an GO-follows-STA scenario you'd have userspace react:
3a) notify cfg80211/userspace of the pending switch
3b) userspace starts (matching) CSA for the GO interface
3c) mac80211 matches that up with the STA interface switch and its
temporary
channel context [and this is the only tricky part]
4) when the time comes to do the switch, hand all the involved
interfaces to
cfg80211 for the final capability check, which should now not fail
unless
userspace specified only one of two GO interfaces or so
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
