This series is based on the remaining patches from Peter Oh's previous series
and is build on top of my previous series
"v4: Fix and unify wpa_supplicant AP/mesh frequency setup".
Masashi Honma previously reported memory leaks when running the
esh_secure_ocv_mix_legacy test. I was not able to reproduce this, with my
patch series.
My additional patches contain the following changes:
(1) Issue:
MESH_GROUP_STARTED gets send before DFS-CAC finishes
Suggested fix:
Send MESH_GROUP_STARTED in mesh join completion callback, which happens
after CAC, if CAC is necessary. Additional, this patch implements a TODO,
which always leaves the mesh on deinit. In order for this to work, some
additional cleanup bool flags are added.
(2) Issue:
Unsuccessfull channel switch -> hostapd calls deinit and init without
wpa_supplicant taking notice
Suggested fix:
add init/deinit callbacks and use them in wpa_supplicant mesh code
(3) Add simple DFS test for wpa_supplicant
(4) Issue:
mesh_oom test fails at allocation failure after 11 allocations
TESTING: fail allocation at wpa_supplicant_mesh_init
backtrace[0] = testing_fail_alloc
backtrace[1] = os_malloc
backtrace[2] = os_realloc
backtrace[3] = phy_info_band
backtrace[4] = phy_info_handler
backtrace[5] = send_and_recv
backtrace[6] = send_and_recv_msgs
backtrace[7] = nl80211_get_hw_feature_data
backtrace[8] = hostapd_get_hw_feature_data
backtrace[9] = hostapd_get_hw_features
backtrace[10] = setup_interface2
backtrace[11] = setup_interface
backtrace[12] = hostapd_setup_interface
backtrace[13] = wpa_supplicant_mesh_init
backtrace[14] = wpa_supplicant_join_mesh
backtrace[15] = wpa_supplicant_associate
If hostapd_get_hw_features fails, ifmsh->freq is not set (0), which leads
to a call to hostapd_set_freq_params with this zero frequency.
Afterwards, mesh join fails, because freq 0 should be joined.
Suggested fix:
Only change the freq params, if we know the old frequency.
(5) factor out mesh frequency setup
(6) Issue:
After mesh DFS channel switch with the target channel only usable but not
available, no CSA is send, an some devices will end on different randomly
choosen channels. Therefore the mesh network became unconnected.
Suggested fix:
Use a deterministic channel calculated from the sha256 hash of the mesh id
in order to get a connected network in most of the cases.
A better solution would need coordination mechanisms in the mesh network.
Markus Theil (6):
mesh: fixes for mesh init/deinit
mesh: fix DFS deinit/init
tests: DFS test for wpa_supplicant mesh
mesh: fix mesh_oom test
mesh: move mesh freq setting to own function
mesh: use deterministic channel on channel switch
Peter Oh (6):
mesh: use setup completion callback to complete mesh join
mesh: update ssid->frequency as pri/sec channel switch
mesh: Allow DFS channels to be selected if dfs is enabled
mesh: do not set offchanok on DFS channels in non-ETSI
mesh: fix channel switch error during CAC
mesh: inform kernel driver DFS handler in userspace
src/ap/dfs.c | 22 +++-
src/ap/hostapd.c | 28 +++++-
src/ap/hostapd.h | 6 ++
src/drivers/driver.h | 1 +
src/drivers/driver_nl80211.c | 26 +++++
tests/hwsim/test_wpas_mesh.py | 56 ++++++++++-
wpa_supplicant/mesh.c | 173 ++++++++++++++++++++++++++++----
wpa_supplicant/mesh.h | 6 +-
wpa_supplicant/wpa_supplicant.c | 33 +++---
9 files changed, 309 insertions(+), 42 deletions(-)
--
2.27.0
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
