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

Message ID 1491792947-29720-2-git-send-email-masashi.honma@gmail.com
State Changes Requested
Headers show

Commit Message

Masashi Honma April 10, 2017, 2:55 a.m.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
 tests/hwsim/test_wpas_mesh.py | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

Comments

Jouni Malinen May 9, 2017, 5:40 p.m. | #1
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?
Masashi Honma May 9, 2017, 9:18 p.m. | #2
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.

Masashi Honma.
Jouni Malinen April 2, 2018, 2:14 p.m. | #3
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.
Peter Oh April 4, 2018, 7:57 p.m. | #4
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
Masashi Honma April 5, 2018, 5:03 a.m. | #5
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@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
Peter Oh April 5, 2018, 7:48 p.m. | #6
On 04/04/2018 10:03 PM, Masashi Honma wrote:
> Thanks Peter.
>
> I would prefer watching your patch on this list !
>
  will send by next week for review. it needs to be rebased since it's 
quite aged.

Patch

diff --git a/tests/hwsim/test_wpas_mesh.py b/tests/hwsim/test_wpas_mesh.py
index 469fe01..4f03e25 100644
--- a/tests/hwsim/test_wpas_mesh.py
+++ b/tests/hwsim/test_wpas_mesh.py
@@ -18,6 +18,8 @@  from utils import HwsimSkip, alloc_fail, fail_test, wait_fail_trigger
 from tshark import run_tshark
 from test_ap_ht import set_world_reg
 from hwsim_utils import set_group_map
+from test_dfs import wait_dfs_event
+from test_p2p_channel import set_country
 
 def check_mesh_support(dev, secure=False):
     if "MESH" not in dev.get_capability("modes"):
@@ -1036,6 +1038,47 @@  def _test_mesh_open_vht_160(dev, apdev):
     dev[0].dump_monitor()
     dev[1].dump_monitor()
 
+def test_wpas_mesh_open_dfs(dev, apdev):
+    """wpa_supplicant open MESH network with DFS"""
+    try:
+        _test_wpas_mesh_open_dfs(dev, apdev)
+    finally:
+        for i in range(0, 2):
+            dev[i].mesh_group_remove()
+            check_mesh_group_removed(dev[i])
+            dev[i].flush_scan_cache()
+            dev[i].dump_monitor()
+        set_country("00")
+
+def _test_wpas_mesh_open_dfs(dev, apdev):
+    set_country("US")
+    for i in range(0, 2):
+        dev[i].request("SET country US")
+        check_mesh_support(dev[i])
+        add_open_mesh_network(dev[i], freq="5260", basic_rates="60 120 240",
+                              disable_ht40=True)
+
+        ev = wait_dfs_event(dev[i], "DFS-CAC-START", 5)
+        if "DFS-CAC-START" not in ev:
+            # For now, assume DFS is not supported by all kernel builds.
+            raise HwsimSkip("CAC did not start - assume not supported")
+
+        ev = wait_dfs_event(dev[i], "DFS-CAC-COMPLETED", 70)
+        if "success=1" not in ev:
+            raise Exception("CAC failed")
+        if "freq=5260" not in ev:
+            raise Exception("Unexpected DFS freq result")
+
+        # Check for mesh joined
+        check_mesh_group_added(dev[i])
+
+    # Check for peer connected
+    for i in range(0, 2):
+        check_mesh_peer_connected(dev[i])
+
+    # Test connectivity 0->1 and 1->0
+    hwsim_utils.test_connectivity(dev[0], dev[1])
+
 def test_wpas_mesh_password_mismatch(dev, apdev):
     """Mesh network and one device with mismatching password"""
     check_mesh_support(dev[0], secure=True)