On 30/01/2024 04:19, David Lin wrote:
From: Rafael Beims <rafael@xxxxxxxx>
Sent: Friday, January 19, 2024 1:09 AM
To: David Lin <yu-hao.lin@xxxxxxx>; linux-wireless@xxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx; briannorris@xxxxxxxxxxxx;
kvalo@xxxxxxxxxx; francesco@xxxxxxxxxx; Pete Hsieh
<tsung-hsien.hsieh@xxxxxxx>
Subject: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to support host mlme
Caution: This is an external email. Please take care when clicking links or
opening attachments. When in doubt, report the message using the 'Report
this email' button
On 22/12/2023 00:21, David Lin wrote:
This series add host based MLME support to the mwifiex driver, this
enables WPA3 support in both client and AP mode.
To enable WPA3, a firmware with corresponding V2 Key API support is
required.
The feature is currently only enabled on NXP IW416 (SD8978), and it
was internally validated by the NXP QA team. Other NXP Wi-Fi chips
supported in current mwifiex are not affected by this change.
v8:
- Separate 6/12 from patch v7.
As it's a bug fix not part of host MLME feature.
- Rearrnage MLME feature into 2 patches:
a. Add host based MLME support for STA mode.
b. Add host based MLME support for AP mode.
v7:
- Fix regression: Downlink throughput degraded by 70% in AP mode.
- Fix issue: On STAUT, kernel Oops occurs when there is no association
response from AP.
- Fix issue: On STAUT, if AP leaves abruptly and deauth is missing,
STA can't connect to AP anymore.
- Fix regression: STA can't connect to AP when host_mlme is disabled
(impact all chips).
- Address reviewer comments.
v6:
- Correct mailing sequence.
v5:
- Add host base MLME support to enable WPA3 functionalities for both
STA and AP mode.
- This feature (WPA3) required a firmware with corresponding Key API
V2
support.
- QA validation and regression have been covered for IW416.
- This feature (WPA3) is currently enabled and verified only for IW416.
- Changelogs since patch V4:
a. Add WPA3 support for AP mode.
b. Bug fix: In WPA3 STA mode, deice gets disconnected from AP
when group rekey occurs.
c. Bug fix: STAUT doesn't send WMM IE in association request when
associate to a WMM-AP.
v4:
- Refine code segment per review comment.
- Add API to check firmware encryption key command version when
host_mlme is enabled.
v3:
- Cleanup commit message.
v2:
- Fix checkpatch error (pwe[1] -> pwe[0]).
- Move module parameter 'host_mlme' to mwifiex_sdio_device
structure.
Default only enable for IW416.
- Disable advertising NL80211_FEATURE_SAE if host_mlme is not
enabled.
David Lin (2):
wifi: mwifiex: add host mlme for client mode
wifi: mwifiex: add host mlme for AP mode
.../net/wireless/marvell/mwifiex/cfg80211.c | 394
+++++++++++++++++-
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 27 ++
drivers/net/wireless/marvell/mwifiex/decl.h | 22 +
drivers/net/wireless/marvell/mwifiex/fw.h | 54 +++
drivers/net/wireless/marvell/mwifiex/init.c | 6 +
drivers/net/wireless/marvell/mwifiex/ioctl.h | 5 +
drivers/net/wireless/marvell/mwifiex/join.c | 66 ++-
drivers/net/wireless/marvell/mwifiex/main.c | 54 +++
drivers/net/wireless/marvell/mwifiex/main.h | 17 +
drivers/net/wireless/marvell/mwifiex/scan.c | 6 +
drivers/net/wireless/marvell/mwifiex/sdio.c | 13 +
drivers/net/wireless/marvell/mwifiex/sdio.h | 2 +
.../wireless/marvell/mwifiex/sta_cmdresp.c | 2 +
.../net/wireless/marvell/mwifiex/sta_event.c | 36 +-
.../net/wireless/marvell/mwifiex/sta_ioctl.c | 3 +-
drivers/net/wireless/marvell/mwifiex/sta_tx.c | 9 +-
.../net/wireless/marvell/mwifiex/uap_cmd.c | 171 ++++++++
drivers/net/wireless/marvell/mwifiex/util.c | 104 +++++
18 files changed, 974 insertions(+), 17 deletions(-)
base-commit: 783004b6dbda2cfe9a552a4cc9c1d168a2068f6c
I applied the two commits of this series on top of v6.7 but unfortunately the AP
is failing to start with the patches. I get this output from "hostapd -d" (running
on a Verdin AM62 with IW416):
nl80211: kernel reports: Match already configured
nl80211: Register frame command failed (type=176): ret=-114 (Operation
already in progress)
nl80211: Register frame match - hexdump(len=0): [NULL]
If I run the same hostapd on v6.7 without the patches, the AP is started with no
issues.
Is there anything else that should be done in order to test this?
Rafael
I applied patch v8 (mbox from patch work) to Linux stable repository (tag v6.7.2).
Both client and AP mode can work with and without WPA3.
David
I went back and executed the tests again. I re-applied the pach on top
of tag v6.7.2 to make sure we're seeing exactly the same thing.
At first, the behavior I was seeing was exactly the same I reported
before. Upon starting hostapd with our basic example configuration, it
would fail to start the AP with the error:
nl80211: kernel reports: Match already configured
nl80211: Could not configure driver mode
After some investigation of what could cause this error, I found out
that it was connman that was interfering with this somehow. After
killing the connman service, the AP would start correctly.
I want to point out that this behavior is different from the unpatched
driver. With that one we don't need to kill connman in order to start
the AP with hostapd.
After seeing the AP starting up, I did a quick series of tests (Toradex
Verdin AM62 with 1GB of RAM and two antennas connected via SMA adapter):
1) AP test: I was able to use the simple AP configuration with two
clients connected simultaneously. I executed simple ping tests and also
a quick run of iperf3 with the following results
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 16.8 MBytes 14.1 Mbits/sec 11 sender
[ 5] 0.00-10.05 sec 16.4 MBytes 13.7 Mbits/sec
receiver
I repeated the same iperf3 test several times with similar results.
Comparing the iperf3 results with what I get on the unpatched driver
(v6.7.2), there seems to be a difference in average bandwidth:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 20.2 MBytes 17.0 Mbits/sec 0 sender
[ 5] 0.00-10.04 sec 19.7 MBytes 16.4 Mbits/sec
receiver
2) Client test: I also executed a similar test but now with the AM62 as
the client. It was possible to connect to an AP and do the ping tests
without problems.
The iperf3 results are in line with what we see on the AP:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 19.3 MBytes 16.2 Mbits/sec 32 sender
[ 5] 0.00-10.01 sec 19.0 MBytes 15.9 Mbits/sec
receiver
Comparing with the unpatched v6.7.2 we can also see a difference:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 23.4 MBytes 19.6 Mbits/sec 0 sender
[ 5] 0.00-10.01 sec 20.7 MBytes 17.3 Mbits/sec
receiver
3) Simple WPA3 AP test: to finish this round of tests, I started an AP
with a configuration enabling SAE. The AP was started successfully and I
could connect a client with wpa_supplicant. Ping tests were also
succesful here.
The iperf3 result shows a bigger bandwidth than all the previous tests:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 20.6 MBytes 17.3 Mbits/sec 35 sender
[ 5] 0.00-10.04 sec 19.8 MBytes 16.6 Mbits/sec
receiver
To summarize the results, it seems that the basic functionality is
working and also WPA3 support.
We have a different behavior when starting the AP, where now we need to
stop connman (blacklisting the uap0 interface will probably also work)
beforehand.
I don't know if the bandwidth results are something to be worried about,
I saw some variation between iperf3 runs, but the results I posted show
an average of what I was seeing.
Rafael
