Re: [PATCHv5 0/8] Add DFS master ability

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

[-- Attachment #1: Type: text/plain, Size: 3426 bytes --]

Hello Johannes,

thank you very much for the review!

On Wed, Jan 02, 2013 at 02:53:43PM +0100, Johannes Berg wrote:
> 
> > I'm sending this as patch to keep the versioning, although it can be
> > considered as RFC, I would be suprised if all single channel/single
> > interface aspects were considered correctly. :)
> 
> :)
> 
> I think we need a bit more "design review" first.

Good idea. :D

> 
> To me, the open questions are:
>  * Should switching to a DFS channel be allowed at all? How so, if radar
>    can't be tested before? You just stop the AP instead but userspace
>    can do that just as well.

The idea was to allow counting down the TBTT/count field of the CSA IE within
the driver - this can't be done properly by userspace.

Also, the transmission must be stopped on the new channel, so the idea was
to do this in kernel space right after the counting is finished. The idea
was to skip the additional enable_tx call which was originally proposed,
but it seems to create more troubles than it saves.

So maybe we should go back to enable_tx to re-enable the AP after a
switch into a DFS channel (with block-tx on).

Unlike Victors proposal, I'd suggest to skip enable_tx when starting the
AP the first time - just doing cac/radar_detect and start_ap should be enough.

>  * What happens with multiple virtual interfaces? You allow a single
>    channel context only which makes sense, but that doesn't disallow
>    things like having a client + AP, and then the client switching away
>    because the P2P GO it was connected to randomly decided to switch.
>    This would break radar detection. (1) What should happen in this
>    case?

Actually I thought I had succesfully disabled multiple interfaces in general
when DFS channels are used. Maybe I missed something?

For now, I'd prefer having only a single interface when doing DFS.

>  * To avoid that problem, could restrict to a single virtual interface.
>    However, that's unlikely to be sufficient -- you'd want to still be
>    able to implement multi-BSSID APs which then switch together etc.

Agreed. In the first step, we could allow multi-BSSID APs. When one hostapd
instance controls these APs, it should have enough information to coordinate
the CSAs on all APs. 

>  * That raises another interesting question -- should multiple BSSIDs on
>    the same channel really *all* call the driver's ap_channel_switch()
>    callback? That seems ... strange!

Hmm, the channel should only be switched once, that's right.

What about:
 * set CSA IEs in the beacons of all APs
 * call ap_channel_switch once for all APs on the phy
 * report switched channel back for all APs
 * remove CSA IEs

>  * Do we need any software channel switch handling?

Don't know what you specifically mean.

A more interesting case will be CSAs for IBSS (later), as the beacons are
handled by the drivers/mac80211 only.
> 
> Generally the biggest issue is around multi-channel channel switch
> behaviour I think. Any good ideas?

For the MultiSSID-APs I think it's possible as roughly described above.
However mixed cases like AP+Client or AP+IBSS will be more interesting,
and I don't have any good idea for this yet...

> 
> johannes
> 
> (1) Actually today it would either break the AP (channel contexts NOT
> supported by the driver) or disconnect the client (otherwise)
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]