[PATCH 2/2] tests: Add a mesh DFS test

[Peter Oh]

On 04/02/2018 07:14 AM, Jouni Malinen wrote:
> On Wed, May 10, 2017 at 06:18:27AM +0900, Masashi Honma wrote:
>> On 2017/05/10 02:40, Jouni Malinen wrote:
>>> On Mon, Apr 10, 2017 at 11:55:47AM +0900, Masashi Honma wrote:
>>>> diff --git a/tests/hwsim/test_wpas_mesh.py b/tests/hwsim/test_wpas_mesh.py
>>> This fails for me with "Test exception: Remote peer did not connect.".
>>> Both devices complete CAC successfully, but apparently fail to send
>>> peering frames
>>>
>>> nl80211: Frame command failed: ret=-16 (Device or resource busy) (freq=5260 wait=0)
>>> Mesh MPM: failed to send peering frame
>>>
>>>
>>> Does this need some kernel changes to allow mesh to start operating on a
>>> DFS channel?
>>>
>> This patch could pass all the test in test_wpas_mesh.py with wpa_supplicant and
>> wireless-testing at Apr 10. I will re-try with latest code.
> I haven't seen any updated on this and now that I tested this with the
> current kernel, I'm seeing a failure as well (though, a different one):
>
> nl80211: mesh join (ifindex=3)
>    * freq=5260
>    * vht_enabled=0
>    * ht_enabled=1
>    * sec_channel_offset=0
>    * channel_type=1
>    * Mesh ID (SSID) - hexdump_ascii(len=14):
>   6d 65 73 68 2d 6f 70 65 6e         wpas-mesh-open
>    * flags=00000001
> nl80211: mesh join failed: ret=-22 (Invalid argument)
>
>
> I had left this patch set in my queue, but I'm dropping it now due to
> the identified issues here and no obvious resolution for them. If you
> have an updated version that works with the current Linux kernel, please
> send an updated set.
If anyone interested, then I could send patchset for mesh DFS enablement 
for review which works on non-dfs channels, dfs channels, with and 
without encryption (none and SAE).
radar detection, channel switch, and link association on new channels 
are verified.
Only left stuff is in the case when multiple mesh points detect radar at 
the same time and they select different channels. To cover the case I 
think we need a private patch for it, because current 802.11s specs does 
not address the case how to handle.

I also remember Jouni's concerns about enabling DFS channels on mesh a 
long time back (Dec.1.2016) and I have some comments on them.

* Jouni, Dec/1/2016
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,
 > yes. it should work, because radar detection is not affected by 
interface types.

  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.
 > in my personal opinion, I don't see the needs of extra driver cap 
advertisement for interface specific such as mesh and current kernel 
config for driver wise option (XXX_DFS_CERTIFIED) seems enough.

How does the channel switch on radar detection during operation work 
between the multiple devices?
 > There are possibilities that multiple mesh points detect radar at the 
same channel and each of them decides to move to different channels 
based on current implementation (src/ap/dfs::dfs_get_valid_channel).

Will all STAs in the mesh BSS move to the same channel?
 > currently no.

Who decides which channel to use?
 > since CSA for mesh also rely on wpa_supplicant, wpa_supplicant 
channel selection select the channel to move 
(src/ap/dfs::dfs_get_valid_channel based on current implementation).

And will all the STAs stop transmission immediately on radar detection
 > yes. CSA action frame will be broadcasted right after 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..
 > I've seen some codes covers it including mesh, but I don't remember 
where the codes reside. I guess it was at mac80211.

Does something prevent a non-radar-detect-capable STA from joining an 
already operating mesh on a DFS channel?
 > there are 2 parameters we can utilize which are "country" parameters 
in conf and NL80211_ATTR_HANDLE_DFS event. mac80211 requires user space 
app to inform mac80211 with NL80211_ATTR_HANDLE_DFS for STA's dfs 
channel capability.

Thanks,
Peter