Re: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to support host mlme

From: Rafael Beims
Date: Wed Feb 07 2024 - 17:07:53 EST

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