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
