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@xxxxxxxxxxxxxxxxx> 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
