[RFC 0/6] Using DFS channels in 802.11s mesh mode

[Benjamin Berg]

On Thu, 2016-12-01 at 20:51 +0200, 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.
> 
> How does the channel switch on radar detection during operation work
> between the multiple devices? Will all STAs in the mesh BSS move to
> the
> same channel? Who decides which channel to use? 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..

To a large extend this should be handled through the mesh channel
switch parameters element (8.4.2.105) which includes the precedence
field. This gives a synchronization mechanism to ensure the mesh
switches to the same channel in the end. It also means that the kernel
may be switching to a channel other than what wpa_supplicant thinks.

I have not yet verified whether this is correctly implemented in
mac80211. I am not even sure right now whether the mesh channel switch
parameters are even set correctly (in particular the reason code to
mark the channel as unusable on the receiving side).

Does something prevent a non-radar-detect-capable STA from joining an
> already operating mesh on a DFS channel?

Not completely sure right now, but I do not see how such a STA would be
permitted to beacon.

Benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20161202/52a79b4d/attachment.sig>