Message-ID: <48364f66-99b4-40ca-b4b2-4adf1071960f@beims.me>
Date: Wed, 7 Feb 2024 18:30:03 -0300
From: Rafael Beims <rafael@...ms.me>
To: David Lin <yu-hao.lin@....com>,
 "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "briannorris@...omium.org" <briannorris@...omium.org>,
 "kvalo@...nel.org" <kvalo@...nel.org>,
 "francesco@...cini.it" <francesco@...cini.it>,
 Pete Hsieh <tsung-hsien.hsieh@....com>
Subject: Re: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to support host
 mlme

On 30/01/2024 04:19, David Lin wrote:
>> From: Rafael Beims <rafael@...ms.me>
>> Sent: Friday, January 19, 2024 1:09 AM
>> To: David Lin <yu-hao.lin@....com>; linux-wireless@...r.kernel.org
>> Cc: linux-kernel@...r.kernel.org; briannorris@...omium.org;
>> kvalo@...nel.org; francesco@...cini.it; Pete Hsieh
>> <tsung-hsien.hsieh@....com>
>> 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

Powered by blists - more mailing lists