Hi Jouni,
On Thursday, December 1, 2016 8:51:16 PM CET Jouni Malinen wrote:
> On Mon, Nov 28, 2016 at 04:38:37PM +0100, Benjamin Berg wrote:
> > I have been working a bit on allowing channels which require DFS to be
> > used
> > for mesh mode. There are still a number of rough edges, but the following
> > patches add very limitted DFS support.
> >
> > What currently works is that wpa_supplicant will start the CAC when
> > required and will use the channel if it is available. In general it will
> > also correctly switch the channel if radar is detected (during CAC or
> > operation).
> I'm a bit concerned about enabling channels requiring DFS for mesh based
> only on the existing radar detection and DFS functionality that has been
> certified in AP mode. While radar detection itself would hopefully work
> fine, I'd want to get somewhat better understanding on potential
> implication this could have or alternatively, use a new driver
> capability advertisement for mesh-DFS that would be enabled explicitly
> for drivers that have been tested in this combination.
I believe this is already handled by the interface combinations - drivers can
announce that they support radar with certain WiFi modes with DFS. I don't see
that we need another flag for this.
>
> How does the channel switch on radar detection during operation work
> between the multiple devices?
Basically, other devices hearing a CSA will adopt the CSA into their beacons/
probe request and perform the same switch. In this way, the CSA gets flooded
through the mesh/IBSS and all devices should (hopefully) switch at the same
time).
> Will all STAs in the mesh BSS move to the
> same channel?
If the CSA adoption is succesful, yes. However, there is no gurantee, it is a
"best effort" process.
One possible approach would be to scan whether other stations already moved to
the previously agreed next channel, to follow those.
> Who decides which channel to use?
The standard doesn't specify that. (For IBSS mode, there is something like a
DFS master, but that appraoch seems far from practical).
We could have an (external) function which decides the channel. But it would
really be integration/vendor-specific.
> And will all the STAs
> stop transmission immediately on radar detection and meet the FCC
> requirements for total aggregate TX time after this for any following
> frames needed for coordination to the channel change? That limit is
> pretty small if it were to be interpreted as a total aggregate over all
> STAs in the mesh..
Hm, as far as I remember, the standard only requires the "master" to not
exceed a specific total transmission time. And ETSI as well as DFS say that for
IBSS/Mesh mode, the devices should be tested as if they were masters. I agree
that it is a question of interpretation, but I'd assume that the limit is
interpreted per AP, not aggregate ...
>
> Does something prevent a non-radar-detect-capable STA from joining an
> already operating mesh on a DFS channel?
In Linux, regdb should avoid it. Since the master rules apply for IBSS/mesh
mode, a device can only join once it performed a CAC (regardless of other
stations already sending there). And it must be radar-capable.
Cheers,
SimonAttachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
