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

[Masashi Honma]

Thanks Peter.

I would prefer watching your patch on this list !

Regards,

Masashi Honma.

On Thu, Apr 5, 2018 at 4:57 AM, Peter Oh <peter.oh at bowerswilkins.com> wrote:
>
>
> 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