| Message ID | 1491792947-29720-2-git-send-email-masashi.honma@gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
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?
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.
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.
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
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
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.
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)
Signed-off-by: Masashi Honma <masashi.honma@gmail.com> --- tests/hwsim/test_wpas_mesh.py | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+)