Open nxf58150 opened 4 months ago
Hi @nxf58150! We appreciate you submitting your first issue for our open-source project. 🌟
Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙
Thanks @nxf58150 , I have slightly formatted and reworded a few sentences in the description.
Few things we had discussed in the Wi-Fi telco:
wifi_mgmt
vs. storing in WPA supplicant itself, this can be a proper upstream feature. We don't want to introduce state/context
to stateless wifi_mgmt
layer.NET_EVENT_WIFI_NEIGHBOR_REP_COMPLETE
can be implemented using the monitor control interface, for this we need to implement RRM-NEIGHBOR-REP-COMPLETE
event in supplicant, this way there would only be a single mechanism i.e., monitor control sockets.Hi @krish2718,
Recently, we found one issue of 11r roaming that 11r roaming can't be completed within 60s zperf UDP throughput test. The root cause is that the 11r roaming is triggered in net_mgmt task, which is with very low priority(14). When running UDP throughput test, the net_mgmt task didn't have much chance to run. Same issue could be found when doing 11k and 11v roaming tests. The priority task of net_mgmt is much lower than other tasks on Zephyr, it is possible that roaming can't be triggered and link lost happens eventually. Therefore, we plan to change our 11k/v/r roaming implementation.
We plan to create new task(name it "supp_mgmt" temporally) and handle roaming. The priority will be same as zperf task. New files supp_mgmt.c and supp_mgmt.h will be added to glue layer.
Could you please add your comments on this?
Thanks you!
If it's just a matter of thread priority
, when supplicant is enabled we can just bump the priority of network management thread, will that work?
We plan to create new task(name it "supp_mgmt" temporally) and handle roaming. The priority will be same as zperf task. New files supp_mgmt.c and supp_mgmt.h will be added to glue layer.
If at all we need a separate thread, can't we just add it to supp_event.c
itself? and let supplicant_send_wifi_mgmt_event
use port to that thread?
Hi @krish2718,
If increasing priority of net_mgmt task is ok for you, then I will change the priority to the same value of supplicant task. This might be the simplest way to resolve the issue and at the same time, keep 11k/v/r roaming plan unchanged. Thank you for your advice. I will try it on my side.
Introduction
Wi-Fi STA needs to roam to a better AP when RSSI of currently associated AP goes below a certain threshold. IEEE 802.11 defined three set of standard 11k, 11v and 11r for this roaming support, commonly known as 802.11 rkv, mainly for Voice Enterprise certification.
Proposed change
Once signal change is reported by the driver, roaming will be triggered in wpa_supplicant based on configured roaming method. Wi-Fi mgmt or glue layer will send different commands to wpa_supplicant through monitor control interface and wpa_supplicant will handle re-association process.
Roaming methods
Roaming starts after EVENT_SIGNAL_CHANGE is received in wpa_supplicant.
11k roaming
WPA supplicant has limited support for 11k, so, need to trigger the intermediate steps manually.
Send commands to wpa_supplicant to send Neighbor report request. Save results of Neighbor report in wifi mgmt and trigger limited scan. Then wpa_supplicant will handle reassociation process after receive scan results.
11v/r roaming
Send commands to wpa_supplicant to trigger 11v or 11r roaming. The wpa_supplicant will handle the rest of the work, including send corresponding frames and trigger scan.
If more than one roaming method is supported, roaming method will be selected based on following priority: 11r > 11k > 11v.