On 24 January 2014 10:52, Luca Coelho <luca@xxxxxxxxx> wrote:
> On Fri, 2014-01-24 at 09:40 +0100, Johannes Berg wrote:
>> On Fri, 2014-01-24 at 09:41 +0200, Luca Coelho wrote:
>>
>> > Yeah, I agree that updating the IEs in mac80211 is not a good idea.
>> > That's why I would prefer to have the notifications to the user space
>> > ("your interface must switch channel") and wait for the userspace to
>> > request a channel switch (with all the necessary information).
>>
>> Even in the sentence "your interface must switch channel" you're
>> conflating multiple things though. Consider a managed+AP interface being
>> concurrent, with the managed one receiving CSA from its BSS.
>>
>> 1) maybe it's a radar channel, and the AP detected radar, then we must
>> switch
>> (to make authorities happy); but in this case we should have
>> detected radar
>> as well on the AP we're running...
>
> Fine, the AP would have detected the radar. Then it gets the "must
> switch" notification triggered by the managed interface and can sync the
> count, so both switch at the same time (which must be the case anyway).
What if the AP interface receives 'radar detected' before managed
interfaces gets CSA? You'll need to consider both cases (either AP
wants to switch first, or STA wants it first).
(z) I wonder if we could have nl80211 channel_switch also work with
STA? This way we could have
single-request-for-multi-interface-channel-switch work for
GO-follow-STA too, as the STA interface would simply send out "I got a
CSA: params.." and wait for either a channel_switch or disconnect
after a timeout.
The timeout itself would have to be conservative, i.e. possibly longer
than beacon_interval x csa count so that userspace has time to make a
decision (to prevent disconnects when csa count is small and/or
userspace lags a bit due to I/O, etc). This (delaying STA chswitch,
i.e. going beyond the bcnint x count threshold) should be safe since
you don't really need to channel switch STA so fast (if you lag a few
beacons nobody cares). Perhaps mac80211 could even use connection loss
work for the timeout itself. All that needs to be taken care of is to
lock tx queues on STA.
This obviously means you get eventually disconnected with STA
interface if you get a CSA without wpa_s running (i.e. `iw connect`.
But then again.. I don't think it makes much sense to run your
wireless stack _without_ wpa_s. Maybe current STA CSA behaviour could
be left for single-interface cases, but I'm not really sure there
would be much use for it?
The same would have to be applied for IBSS and mesh -- they must not
switch implicitly in-kernel upon receiving CSA but notify userspace
about it and let userspace make the decision.
This also means "switch or die" policy is moved to userspace where it
probably should've been from the start.
>> The same cases exist if, like you suggested, we'd make such a
>> notification when one AP interface starts to switch. I'm still mostly
>> against that though.
>
> I think we're in a deadlock of I'm pro and you're against. :)
>
>
>> "[Y]our interface must switch channel" is therefore not very well
>> defined, and I'd hate to see a client interface CSA-started notification
>> interpreted as such;
>
> We don't send the "must switch" notification to the interfaces that
> *triggered* the channel switch. Either if it was a
> client-interface-started CSA or if it was a remotely triggered CSA (ie.
> the AP/GO our managed/client is connected to). We send the notification
> to the *other* interfaces that are on the same channel.
See (z).
>
>
>> > you can see that there's at least one sub-case where other
>> > interfaces don't have to switch.
>
> The notification is also just sent if it *must* switch (ie. when there's
> no extra context available). In this case, even if the "other
> interfaces don't have to switch", they must switch or die.
Actually you could want to migrate your AP along with STA even if you
can operate on two channels. E.g. you might want to maximize
performance and such, no?
> Let's say hostapd is managing two APs. It decides that AP1 needs to
> switch channel. At this point it doesn't necessarily know that AP2 must
> also switch because there are no extra channel contexts available to
> keep them in separate channels. mac80211 knows and indicates that so
> that hostapd decides to switch AP2 as well. With the
> single-CSA-request-for-mutliple-interfaces proposal, it must switch all
> of them at once even if it *would be* possible to keep them in separate
> channels, because there's no way of know that beforehand.
You could try to rely on "if (err == -EBUSY)
ch_switch_all_the_things()". EBUSY at this point can either mean
"iface comb impossible due to iftype/ifnum failure" or "num_diff_chans
!= available_num_chans". The former shouldn't be true since, well, you
already got iftype/ifnum combo running, so you're only left with
channel count. Or am I missing something?
>> The question also is how to handle it if
>> wpa_s doesn't respond (e.g. old wpa_s version that has no idea what's
>> going on) - which interface should "lose"?
>
> If it doesn't respond, the AP/GO will get disconnected. That's where
> the "switch or *die*" comes in. If we're using an old wpa_s, this
> wouldn't work anyway. With my proposal and a *new* wpa_s, we could do
> what I suggested above.
>
> How would the single-CSA-request-for-multiple-interfaces proposal help
> in this case?
See (z).
Michał
--
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
