| Message ID | 20231222032123.1036277-1-yu-hao.lin@nxp.com |
|---|---|
| Headers | show |
| Series | wifi: mwifiex: add code to support host mlme | expand |
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
> From: Rafael Beims <rafael@beims.me> > Sent: Friday, January 19, 2024 1:09 AM > To: David Lin <yu-hao.lin@nxp.com>; linux-wireless@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; briannorris@chromium.org; > kvalo@kernel.org; francesco@dolcini.it; Pete Hsieh > <tsung-hsien.hsieh@nxp.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 Our test is on v6.1. I will try to test on v6.7. Thanks for your information.
> From: Rafael Beims <rafael@beims.me> > Sent: Friday, January 19, 2024 1:09 AM > To: David Lin <yu-hao.lin@nxp.com>; linux-wireless@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; briannorris@chromium.org; > kvalo@kernel.org; francesco@dolcini.it; Pete Hsieh > <tsung-hsien.hsieh@nxp.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
On 30/01/2024 04:19, David Lin wrote: >> From: Rafael Beims <rafael@beims.me> >> Sent: Friday, January 19, 2024 1:09 AM >> To: David Lin <yu-hao.lin@nxp.com>; linux-wireless@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org; briannorris@chromium.org; >> kvalo@kernel.org; francesco@dolcini.it; Pete Hsieh >> <tsung-hsien.hsieh@nxp.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
On Wed, Feb 07, 2024 at 06:30:03PM -0300, Rafael Beims wrote: > On 30/01/2024 04:19, David Lin wrote: > > > From: Rafael Beims <rafael@beims.me> > > > 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. ... > > > > David Lin (2): > > > > wifi: mwifiex: add host mlme for client mode > > > > wifi: mwifiex: add host mlme for AP mode ... > > > 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? > > > > > > > > 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. > > > 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. Any idea what's going on in this regard? Is such a change in behavior expected? Francesco
> From: Francesco Dolcini <francesco@dolcini.it> > Sent: Thursday, February 8, 2024 3:25 PM > To: Rafael Beims <rafael@beims.me> > Cc: David Lin <yu-hao.lin@nxp.com>; linux-wireless@vger.kernel.org; > linux-kernel@vger.kernel.org; briannorris@chromium.org; kvalo@kernel.org; > francesco@dolcini.it; Pete Hsieh <tsung-hsien.hsieh@nxp.com> > Subject: Re: [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 Wed, Feb 07, 2024 at 06:30:03PM -0300, Rafael Beims wrote: > > On 30/01/2024 04:19, David Lin wrote: > > > > From: Rafael Beims <rafael@beims.me> 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. > > ... > > > > > > David Lin (2): > > > > > wifi: mwifiex: add host mlme for client mode > > > > > wifi: mwifiex: add host mlme for AP mode > > ... > > > > > 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? > > > > > > > > > > > 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. > > > > > 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. > > Any idea what's going on in this regard? Is such a change in behavior expected? > > Francesco When I tried to test v6.7.2+ (with patch v8) on NB + SDIO IW416, it needs to issue "sudo systemctl stop NetworkManager" in order to test AP mode. For i.MX + SDIO IW416, it needs to install following two files for client and AP mode to "/lib/systemd/network" for systemd-networkd: <<Client mode: 80-wifi-station.network>> [Match] Type=wlan WLANInterfaceType=station [Network] DHCP=yes <<AP mode: 80-wifi-ap.network>> [Match] Type=wlan WLANInterfaceType=ap [Network] Address=192.168.100.1/24 DHCPServer=yes [DHCPServer] PoolOffset=100 PoolSize=20 I think this is not related to driver. David
On 14/02/2024 23:07, David Lin wrote: >> From: Francesco Dolcini <francesco@dolcini.it> >> Sent: Thursday, February 8, 2024 3:25 PM >> To: Rafael Beims <rafael@beims.me> >> Cc: David Lin <yu-hao.lin@nxp.com>; linux-wireless@vger.kernel.org; >> linux-kernel@vger.kernel.org; briannorris@chromium.org; kvalo@kernel.org; >> francesco@dolcini.it; Pete Hsieh <tsung-hsien.hsieh@nxp.com> >> Subject: Re: [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 Wed, Feb 07, 2024 at 06:30:03PM -0300, Rafael Beims wrote: >>> On 30/01/2024 04:19, David Lin wrote: >>>>> From: Rafael Beims <rafael@beims.me> 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. >> ... >> >>>>>> David Lin (2): >>>>>> wifi: mwifiex: add host mlme for client mode >>>>>> wifi: mwifiex: add host mlme for AP mode >> ... >> >>>>> 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? >>>>> >>>>> >>>> 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. >>>> >>> 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. >> Any idea what's going on in this regard? Is such a change in behavior expected? >> >> Francesco > When I tried to test v6.7.2+ (with patch v8) on NB + SDIO IW416, it needs to issue "sudo systemctl stop NetworkManager" in order to test AP mode. The issue I reported is that the kernel with the patch is behaving differently when compared to the kernel without the patch. I kept all the test conditions the same, just replacing the kernel. It seems that you can reproduce this on your end using NetworkManager. This is a change in behavior on userspace that's not currently explained. > For i.MX + SDIO IW416, it needs to install following two files for client and AP mode to "/lib/systemd/network" for systemd-networkd: > > <<Client mode: 80-wifi-station.network>> > > [Match] > Type=wlan > WLANInterfaceType=station > > [Network] > DHCP=yes > > <<AP mode: 80-wifi-ap.network>> > > [Match] > Type=wlan > WLANInterfaceType=ap > > [Network] > Address=192.168.100.1/24 > DHCPServer=yes > > [DHCPServer] > PoolOffset=100 > PoolSize=20 > > I think this is not related to driver. > > David I didn't really understand what systemd-networkd has to do with anything being discussed here. We could use it to create an AP, but that's not the test I did. In my case I used hostapd directly. Rafael
> From: Rafael Beims <rafael@beims.me> > Sent: Thursday, February 15, 2024 8:11 PM > To: David Lin <yu-hao.lin@nxp.com>; Francesco Dolcini <francesco@dolcini.it> > Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; > briannorris@chromium.org; kvalo@kernel.org; Pete Hsieh > <tsung-hsien.hsieh@nxp.com> > Subject: Re: [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 14/02/2024 23:07, David Lin wrote: > >> From: Francesco Dolcini <francesco@dolcini.it> > >> Sent: Thursday, February 8, 2024 3:25 PM > >> To: Rafael Beims <rafael@beims.me> > >> Cc: David Lin <yu-hao.lin@nxp.com>; linux-wireless@vger.kernel.org; > >> linux-kernel@vger.kernel.org; briannorris@chromium.org; > >> kvalo@kernel.org; francesco@dolcini.it; Pete Hsieh > >> <tsung-hsien.hsieh@nxp.com> > >> Subject: Re: [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 Wed, Feb 07, 2024 at 06:30:03PM -0300, Rafael Beims wrote: > >>> On 30/01/2024 04:19, David Lin wrote: > >>>>> From: Rafael Beims <rafael@beims.me> 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. > >> ... > >> > >>>>>> David Lin (2): > >>>>>> wifi: mwifiex: add host mlme for client mode > >>>>>> wifi: mwifiex: add host mlme for AP mode > >> ... > >> > >>>>> 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? > >>>>> > >>>>> > >>>> 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. > >>>> > >>> 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. > >> Any idea what's going on in this regard? Is such a change in behavior > expected? > >> > >> Francesco > > When I tried to test v6.7.2+ (with patch v8) on NB + SDIO IW416, it needs to > issue "sudo systemctl stop NetworkManager" in order to test AP mode. > > The issue I reported is that the kernel with the patch is behaving differently > when compared to the kernel without the patch. I kept all the test conditions > the same, just replacing the kernel. It seems that you can reproduce this on > your end using NetworkManager. > > This is a change in behavior on userspace that's not currently explained. > > > For i.MX + SDIO IW416, it needs to install following two files for client and > AP mode to "/lib/systemd/network" for systemd-networkd: > > > > <<Client mode: 80-wifi-station.network>> > > > > [Match] > > Type=wlan > > WLANInterfaceType=station > > > > [Network] > > DHCP=yes > > > > <<AP mode: 80-wifi-ap.network>> > > > > [Match] > > Type=wlan > > WLANInterfaceType=ap > > > > [Network] > > Address=192.168.100.1/24 > > DHCPServer=yes > > > > [DHCPServer] > > PoolOffset=100 > > PoolSize=20 > > > > I think this is not related to driver. > > > > David > > I didn't really understand what systemd-networkd has to do with anything > being discussed here. We could use it to create an AP, but that's not the test I > did. In my case I used hostapd directly. > > > Rafael I think the difference between previous driver is host mlme. Systemd-networkd is only for address assignment, so it won't affect the test of AP mode. However, Ubuntu Network Manager will affect AP mode test, so it needs to stop it before running hostapd. David
> From: David Lin > Sent: Friday, February 16, 2024 9:41 AM > To: Rafael Beims <rafael@beims.me>; Francesco Dolcini > <francesco@dolcini.it> > Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; > briannorris@chromium.org; kvalo@kernel.org; Pete Hsieh > <tsung-hsien.hsieh@nxp.com> > Subject: RE: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to support host > mlme > > > From: Rafael Beims <rafael@beims.me> > > Sent: Thursday, February 15, 2024 8:11 PM > > To: David Lin <yu-hao.lin@nxp.com>; Francesco Dolcini > > <francesco@dolcini.it> > > Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; > > briannorris@chromium.org; kvalo@kernel.org; Pete Hsieh > > <tsung-hsien.hsieh@nxp.com> > > Subject: Re: [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 14/02/2024 23:07, David Lin wrote: > > >> From: Francesco Dolcini <francesco@dolcini.it> > > >> Sent: Thursday, February 8, 2024 3:25 PM > > >> To: Rafael Beims <rafael@beims.me> > > >> Cc: David Lin <yu-hao.lin@nxp.com>; linux-wireless@vger.kernel.org; > > >> linux-kernel@vger.kernel.org; briannorris@chromium.org; > > >> kvalo@kernel.org; francesco@dolcini.it; Pete Hsieh > > >> <tsung-hsien.hsieh@nxp.com> > > >> Subject: Re: [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 Wed, Feb 07, 2024 at 06:30:03PM -0300, Rafael Beims wrote: > > >>> On 30/01/2024 04:19, David Lin wrote: > > >>>>> From: Rafael Beims <rafael@beims.me> 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. > > >> ... > > >> > > >>>>>> David Lin (2): > > >>>>>> wifi: mwifiex: add host mlme for client mode > > >>>>>> wifi: mwifiex: add host mlme for AP mode > > >> ... > > >> > > >>>>> 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? > > >>>>> > > >>>>> > > >>>> 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. > > >>>> > > >>> 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. > > >> Any idea what's going on in this regard? Is such a change in > > >> behavior > > expected? > > >> > > >> Francesco > > > When I tried to test v6.7.2+ (with patch v8) on NB + SDIO IW416, it > > > needs to > > issue "sudo systemctl stop NetworkManager" in order to test AP mode. > > > > The issue I reported is that the kernel with the patch is behaving > > differently when compared to the kernel without the patch. I kept all > > the test conditions the same, just replacing the kernel. It seems that > > you can reproduce this on your end using NetworkManager. > > > > This is a change in behavior on userspace that's not currently explained. > > > > > For i.MX + SDIO IW416, it needs to install following two files for > > > client and > > AP mode to "/lib/systemd/network" for systemd-networkd: > > > > > > <<Client mode: 80-wifi-station.network>> > > > > > > [Match] > > > Type=wlan > > > WLANInterfaceType=station > > > > > > [Network] > > > DHCP=yes > > > > > > <<AP mode: 80-wifi-ap.network>> > > > > > > [Match] > > > Type=wlan > > > WLANInterfaceType=ap > > > > > > [Network] > > > Address=192.168.100.1/24 > > > DHCPServer=yes > > > > > > [DHCPServer] > > > PoolOffset=100 > > > PoolSize=20 > > > > > > I think this is not related to driver. > > > > > > David > > > > I didn't really understand what systemd-networkd has to do with > > anything being discussed here. We could use it to create an AP, but > > that's not the test I did. In my case I used hostapd directly. > > > > > > Rafael > > I think the difference between previous driver is host mlme. Systemd-networkd > is only for address assignment, so it won't affect the test of AP mode. However, > Ubuntu Network Manager will affect AP mode test, so it needs to stop it before > running hostapd. > > David I found https://groups.google.com/g/beagleboard/c/3Um2Xqa2MHU to setup commman with hostapd. Can you give me your setting for commman? Thanks. David
On 15/02/2024 22:48, David Lin wrote: >> From: David Lin >> Sent: Friday, February 16, 2024 9:41 AM >> To: Rafael Beims <rafael@beims.me>; Francesco Dolcini >> <francesco@dolcini.it> >> Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; >> briannorris@chromium.org; kvalo@kernel.org; Pete Hsieh >> <tsung-hsien.hsieh@nxp.com> >> Subject: RE: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to support host >> mlme >> >>> From: Rafael Beims <rafael@beims.me> >>> Sent: Thursday, February 15, 2024 8:11 PM >>> To: David Lin <yu-hao.lin@nxp.com>; Francesco Dolcini >>> <francesco@dolcini.it> >>> Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; >>> briannorris@chromium.org; kvalo@kernel.org; Pete Hsieh >>> <tsung-hsien.hsieh@nxp.com> >>> Subject: Re: [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 14/02/2024 23:07, David Lin wrote: >>>>> From: Francesco Dolcini <francesco@dolcini.it> >>>>> Sent: Thursday, February 8, 2024 3:25 PM >>>>> To: Rafael Beims <rafael@beims.me> >>>>> Cc: David Lin <yu-hao.lin@nxp.com>; linux-wireless@vger.kernel.org; >>>>> linux-kernel@vger.kernel.org; briannorris@chromium.org; >>>>> kvalo@kernel.org; francesco@dolcini.it; Pete Hsieh >>>>> <tsung-hsien.hsieh@nxp.com> >>>>> Subject: Re: [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 Wed, Feb 07, 2024 at 06:30:03PM -0300, Rafael Beims wrote: >>>>>> On 30/01/2024 04:19, David Lin wrote: >>>>>>>> From: Rafael Beims <rafael@beims.me> 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. >>>>> ... >>>>> >>>>>>>>> David Lin (2): >>>>>>>>> wifi: mwifiex: add host mlme for client mode >>>>>>>>> wifi: mwifiex: add host mlme for AP mode >>>>> ... >>>>> >>>>>>>> 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? >>>>>>>> >>>>>>>> >>>>>>> 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. >>>>>>> >>>>>> 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. >>>>> Any idea what's going on in this regard? Is such a change in >>>>> behavior >>> expected? >>>>> Francesco >>>> When I tried to test v6.7.2+ (with patch v8) on NB + SDIO IW416, it >>>> needs to >>> issue "sudo systemctl stop NetworkManager" in order to test AP mode. >>> >>> The issue I reported is that the kernel with the patch is behaving >>> differently when compared to the kernel without the patch. I kept all >>> the test conditions the same, just replacing the kernel. It seems that >>> you can reproduce this on your end using NetworkManager. >>> >>> This is a change in behavior on userspace that's not currently explained. >>> >>>> For i.MX + SDIO IW416, it needs to install following two files for >>>> client and >>> AP mode to "/lib/systemd/network" for systemd-networkd: >>>> <<Client mode: 80-wifi-station.network>> >>>> >>>> [Match] >>>> Type=wlan >>>> WLANInterfaceType=station >>>> >>>> [Network] >>>> DHCP=yes >>>> >>>> <<AP mode: 80-wifi-ap.network>> >>>> >>>> [Match] >>>> Type=wlan >>>> WLANInterfaceType=ap >>>> >>>> [Network] >>>> Address=192.168.100.1/24 >>>> DHCPServer=yes >>>> >>>> [DHCPServer] >>>> PoolOffset=100 >>>> PoolSize=20 >>>> >>>> I think this is not related to driver. >>>> >>>> David >>> I didn't really understand what systemd-networkd has to do with >>> anything being discussed here. We could use it to create an AP, but >>> that's not the test I did. In my case I used hostapd directly. >>> >>> >>> Rafael >> I think the difference between previous driver is host mlme. Systemd-networkd >> is only for address assignment, so it won't affect the test of AP mode. However, >> Ubuntu Network Manager will affect AP mode test, so it needs to stop it before >> running hostapd. >> >> David > I found https://groups.google.com/g/beagleboard/c/3Um2Xqa2MHU to setup commman with hostapd. Can you give me your setting for commman? Thanks. > > David > Just to make it clear, we are *not* setting up the AP with connman. On our reference images we have a simple service that starts hostapd directly. We also have connman running by default and it's responsible for setting up the other interfaces (ethernet, wifi client). In this setup, we previously were able to just start the hostapd service and the AP would start working. Now with the patch, connman seems to be doing something with the interface that causes the AP to fail starting. For reference, this is the simple AP service we start: [Unit] Description=Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator Requires=enable-wifi.service [Service] Type=forking PIDFile=/run/hostapd.pid ExecStart=/usr/sbin/hostapd /etc/hostapd-tdx-demo-img.conf -P /run/hostapd.pid -B [Install] WantedBy=multi-user.target If you want to replicate this behavior on your side, probably just building connman with yocto and adding it to your image is enough. After enabling connman to start at boot time, you can try to start hostapd manually. Regards, Rafael
> From: Rafael Beims <rafael@beims.me> > Sent: Friday, February 16, 2024 6:11 PM > To: David Lin <yu-hao.lin@nxp.com>; Francesco Dolcini <francesco@dolcini.it> > Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; > briannorris@chromium.org; kvalo@kernel.org; Pete Hsieh > <tsung-hsien.hsieh@nxp.com> > Subject: Re: [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 15/02/2024 22:48, David Lin wrote: > >> From: David Lin > >> Sent: Friday, February 16, 2024 9:41 AM > >> To: Rafael Beims <rafael@beims.me>; Francesco Dolcini > >> <francesco@dolcini.it> > >> Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; > >> briannorris@chromium.org; kvalo@kernel.org; Pete Hsieh > >> <tsung-hsien.hsieh@nxp.com> > >> Subject: RE: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to > >> support host mlme > >> > >>> From: Rafael Beims <rafael@beims.me> > >>> Sent: Thursday, February 15, 2024 8:11 PM > >>> To: David Lin <yu-hao.lin@nxp.com>; Francesco Dolcini > >>> <francesco@dolcini.it> > >>> Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; > >>> briannorris@chromium.org; kvalo@kernel.org; Pete Hsieh > >>> <tsung-hsien.hsieh@nxp.com> > >>> Subject: Re: [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 14/02/2024 23:07, David Lin wrote: > >>>>> From: Francesco Dolcini <francesco@dolcini.it> > >>>>> Sent: Thursday, February 8, 2024 3:25 PM > >>>>> To: Rafael Beims <rafael@beims.me> > >>>>> Cc: David Lin <yu-hao.lin@nxp.com>; > >>>>> linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; > >>>>> briannorris@chromium.org; kvalo@kernel.org; francesco@dolcini.it; > >>>>> Pete Hsieh <tsung-hsien.hsieh@nxp.com> > >>>>> Subject: Re: [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 Wed, Feb 07, 2024 at 06:30:03PM -0300, Rafael Beims wrote: > >>>>>> On 30/01/2024 04:19, David Lin wrote: > >>>>>>>> From: Rafael Beims <rafael@beims.me> 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. > >>>>> ... > >>>>> > >>>>>>>>> David Lin (2): > >>>>>>>>> wifi: mwifiex: add host mlme for client mode > >>>>>>>>> wifi: mwifiex: add host mlme for AP mode > >>>>> ... > >>>>> > >>>>>>>> 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? > >>>>>>>> > >>>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>> 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. > >>>>> Any idea what's going on in this regard? Is such a change in > >>>>> behavior > >>> expected? > >>>>> Francesco > >>>> When I tried to test v6.7.2+ (with patch v8) on NB + SDIO IW416, it > >>>> needs to > >>> issue "sudo systemctl stop NetworkManager" in order to test AP mode. > >>> > >>> The issue I reported is that the kernel with the patch is behaving > >>> differently when compared to the kernel without the patch. I kept > >>> all the test conditions the same, just replacing the kernel. It > >>> seems that you can reproduce this on your end using NetworkManager. > >>> > >>> This is a change in behavior on userspace that's not currently explained. > >>> > >>>> For i.MX + SDIO IW416, it needs to install following two files for > >>>> client and > >>> AP mode to "/lib/systemd/network" for systemd-networkd: > >>>> <<Client mode: 80-wifi-station.network>> > >>>> > >>>> [Match] > >>>> Type=wlan > >>>> WLANInterfaceType=station > >>>> > >>>> [Network] > >>>> DHCP=yes > >>>> > >>>> <<AP mode: 80-wifi-ap.network>> > >>>> > >>>> [Match] > >>>> Type=wlan > >>>> WLANInterfaceType=ap > >>>> > >>>> [Network] > >>>> Address=192.168.100.1/24 > >>>> DHCPServer=yes > >>>> > >>>> [DHCPServer] > >>>> PoolOffset=100 > >>>> PoolSize=20 > >>>> > >>>> I think this is not related to driver. > >>>> > >>>> David > >>> I didn't really understand what systemd-networkd has to do with > >>> anything being discussed here. We could use it to create an AP, but > >>> that's not the test I did. In my case I used hostapd directly. > >>> > >>> > >>> Rafael > >> I think the difference between previous driver is host mlme. > >> Systemd-networkd is only for address assignment, so it won't affect > >> the test of AP mode. However, Ubuntu Network Manager will affect AP > >> mode test, so it needs to stop it before running hostapd. > >> > >> David > > I found > https://groups.go/ > ogle.com%2Fg%2Fbeagleboard%2Fc%2F3Um2Xqa2MHU&data=05%7C02%7Cy > u-hao.lin%40nxp.com%7C4c74f7c309e243eb6c0c08dc2ed78b4c%7C686ea1d3 > bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638436750492293425%7CUnknow > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW > wiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=99eQWmm39kbo63JKNFbiljFQz > o%2Bz7ki%2FSsllw%2FdonbE%3D&reserved=0 to setup commman with > hostapd. Can you give me your setting for commman? Thanks. > > > > David > > > Just to make it clear, we are *not* setting up the AP with connman. On our > reference images we have a simple service that starts hostapd directly. We also > have connman running by default and it's responsible for setting up the other > interfaces (ethernet, wifi client). > > In this setup, we previously were able to just start the hostapd service and the > AP would start working. Now with the patch, connman seems to be doing > something with the interface that causes the AP to fail starting. > > For reference, this is the simple AP service we start: > > [Unit] > Description=Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS > Authenticator Requires=enable-wifi.service > > [Service] > Type=forking > PIDFile=/run/hostapd.pid > ExecStart=/usr/sbin/hostapd /etc/hostapd-tdx-demo-img.conf -P > /run/hostapd.pid -B > > > [Install] > WantedBy=multi-user.target > > > If you want to replicate this behavior on your side, probably just building > connman with yocto and adding it to your image is enough. After enabling > connman to start at boot time, you can try to start hostapd manually. > > > Regards, > > Rafael > 1. Without host mlme, management packet filter of AP mode is the same as client mode. Authentication/Association packets are handled by firmware and once if station is connected, firmware will send station connection event to driver. So you can still start wpa_supplicant and hostapd on uap0 at same time. However, this is not correct setting and usage. 2. With host mlme, management packet filter of AP mode is not the same as client mode. Authentication/Association packets are sent to hostapd, so cfg80211 won't allow wpa_supplicant and hostapd run on uap0 at same time (different management packet filter). I think no matter with or without patch v8, setting of connman for uap0 should not be client mode. Setting of connman for uap0 should be ap mode or bypass to control it as client mode. The behavior of patch v8 is correct and it can avoid user to run wpa_supplicant and hostapd on AP wireless interface at same time. There is no side effect of patch v8 for this behavior. I also found document from Toradex about how to run connman for AP mode: https://developer.toradex.com/linux-bsp/application-development/networking-connectivity/how-to-setup-wi-fi-access-point-mode-linux/ Please check section 8: Enable and start hostapd service: First, make sure to blacklist the uap0 interface on connmanctl by adding it to NetworkInterfaceBlacklist at connman/main.conf. I think to block uap0 from connman is correct way to run hostapd on uap0. David
On 22/02/2024 05:01, David Lin wrote: >> From: Rafael Beims <rafael@beims.me> >> Sent: Friday, February 16, 2024 6:11 PM >> To: David Lin <yu-hao.lin@nxp.com>; Francesco Dolcini <francesco@dolcini.it> >> Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; >> briannorris@chromium.org; kvalo@kernel.org; Pete Hsieh >> <tsung-hsien.hsieh@nxp.com> >> Subject: Re: [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 15/02/2024 22:48, David Lin wrote: >>>> From: David Lin >>>> Sent: Friday, February 16, 2024 9:41 AM >>>> To: Rafael Beims <rafael@beims.me>; Francesco Dolcini >>>> <francesco@dolcini.it> >>>> Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; >>>> briannorris@chromium.org; kvalo@kernel.org; Pete Hsieh >>>> <tsung-hsien.hsieh@nxp.com> >>>> Subject: RE: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to >>>> support host mlme >>>> >>>>> From: Rafael Beims <rafael@beims.me> >>>>> Sent: Thursday, February 15, 2024 8:11 PM >>>>> To: David Lin <yu-hao.lin@nxp.com>; Francesco Dolcini >>>>> <francesco@dolcini.it> >>>>> Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; >>>>> briannorris@chromium.org; kvalo@kernel.org; Pete Hsieh >>>>> <tsung-hsien.hsieh@nxp.com> >>>>> Subject: Re: [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 14/02/2024 23:07, David Lin wrote: >>>>>>> From: Francesco Dolcini <francesco@dolcini.it> >>>>>>> Sent: Thursday, February 8, 2024 3:25 PM >>>>>>> To: Rafael Beims <rafael@beims.me> >>>>>>> Cc: David Lin <yu-hao.lin@nxp.com>; >>>>>>> linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; >>>>>>> briannorris@chromium.org; kvalo@kernel.org; francesco@dolcini.it; >>>>>>> Pete Hsieh <tsung-hsien.hsieh@nxp.com> >>>>>>> Subject: Re: [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 Wed, Feb 07, 2024 at 06:30:03PM -0300, Rafael Beims wrote: >>>>>>>> On 30/01/2024 04:19, David Lin wrote: >>>>>>>>>> From: Rafael Beims <rafael@beims.me> 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. >>>>>>> ... >>>>>>> >>>>>>>>>>> David Lin (2): >>>>>>>>>>> wifi: mwifiex: add host mlme for client mode >>>>>>>>>>> wifi: mwifiex: add host mlme for AP mode >>>>>>> ... >>>>>>> >>>>>>>>>> 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? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>> 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. >>>>>>> Any idea what's going on in this regard? Is such a change in >>>>>>> behavior >>>>> expected? >>>>>>> Francesco >>>>>> When I tried to test v6.7.2+ (with patch v8) on NB + SDIO IW416, it >>>>>> needs to >>>>> issue "sudo systemctl stop NetworkManager" in order to test AP mode. >>>>> >>>>> The issue I reported is that the kernel with the patch is behaving >>>>> differently when compared to the kernel without the patch. I kept >>>>> all the test conditions the same, just replacing the kernel. It >>>>> seems that you can reproduce this on your end using NetworkManager. >>>>> >>>>> This is a change in behavior on userspace that's not currently explained. >>>>> >>>>>> For i.MX + SDIO IW416, it needs to install following two files for >>>>>> client and >>>>> AP mode to "/lib/systemd/network" for systemd-networkd: >>>>>> <<Client mode: 80-wifi-station.network>> >>>>>> >>>>>> [Match] >>>>>> Type=wlan >>>>>> WLANInterfaceType=station >>>>>> >>>>>> [Network] >>>>>> DHCP=yes >>>>>> >>>>>> <<AP mode: 80-wifi-ap.network>> >>>>>> >>>>>> [Match] >>>>>> Type=wlan >>>>>> WLANInterfaceType=ap >>>>>> >>>>>> [Network] >>>>>> Address=192.168.100.1/24 >>>>>> DHCPServer=yes >>>>>> >>>>>> [DHCPServer] >>>>>> PoolOffset=100 >>>>>> PoolSize=20 >>>>>> >>>>>> I think this is not related to driver. >>>>>> >>>>>> David >>>>> I didn't really understand what systemd-networkd has to do with >>>>> anything being discussed here. We could use it to create an AP, but >>>>> that's not the test I did. In my case I used hostapd directly. >>>>> >>>>> >>>>> Rafael >>>> I think the difference between previous driver is host mlme. >>>> Systemd-networkd is only for address assignment, so it won't affect >>>> the test of AP mode. However, Ubuntu Network Manager will affect AP >>>> mode test, so it needs to stop it before running hostapd. >>>> >>>> David >>> I found >> https://groups.go/ >> ogle.com%2Fg%2Fbeagleboard%2Fc%2F3Um2Xqa2MHU&data=05%7C02%7Cy >> u-hao.lin%40nxp.com%7C4c74f7c309e243eb6c0c08dc2ed78b4c%7C686ea1d3 >> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638436750492293425%7CUnknow >> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW >> wiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=99eQWmm39kbo63JKNFbiljFQz >> o%2Bz7ki%2FSsllw%2FdonbE%3D&reserved=0 to setup commman with >> hostapd. Can you give me your setting for commman? Thanks. >>> David >>> >> Just to make it clear, we are *not* setting up the AP with connman. On our >> reference images we have a simple service that starts hostapd directly. We also >> have connman running by default and it's responsible for setting up the other >> interfaces (ethernet, wifi client). >> >> In this setup, we previously were able to just start the hostapd service and the >> AP would start working. Now with the patch, connman seems to be doing >> something with the interface that causes the AP to fail starting. >> >> For reference, this is the simple AP service we start: >> >> [Unit] >> Description=Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS >> Authenticator Requires=enable-wifi.service >> >> [Service] >> Type=forking >> PIDFile=/run/hostapd.pid >> ExecStart=/usr/sbin/hostapd /etc/hostapd-tdx-demo-img.conf -P >> /run/hostapd.pid -B >> >> >> [Install] >> WantedBy=multi-user.target >> >> >> If you want to replicate this behavior on your side, probably just building >> connman with yocto and adding it to your image is enough. After enabling >> connman to start at boot time, you can try to start hostapd manually. >> >> >> Regards, >> >> Rafael >> > 1. Without host mlme, management packet filter of AP mode is the same as client mode. Authentication/Association packets are handled by firmware and once if station is connected, firmware will send station connection event to driver. So you can still start wpa_supplicant and hostapd on uap0 at same time. However, this is not correct setting and usage. > > 2. With host mlme, management packet filter of AP mode is not the same as client mode. Authentication/Association packets are sent to hostapd, so cfg80211 won't allow wpa_supplicant and hostapd run on uap0 at same time (different management packet filter). > > I think no matter with or without patch v8, setting of connman for uap0 should not be client mode. Setting of connman for uap0 should be ap mode or bypass to control it as client mode. > > The behavior of patch v8 is correct and it can avoid user to run wpa_supplicant and hostapd on AP wireless interface at same time. There is no side effect of patch v8 for this behavior. > > I also found document from Toradex about how to run connman for AP mode: > > https://developer.toradex.com/linux-bsp/application-development/networking-connectivity/how-to-setup-wi-fi-access-point-mode-linux/ > > Please check section 8: > > Enable and start hostapd service: > First, make sure to blacklist the uap0 interface on connmanctl by adding it to NetworkInterfaceBlacklist at connman/main.conf. > > I think to block uap0 from connman is correct way to run hostapd on uap0. > > David > That explains the difference in behavior, thank you! Tested-by: <rafael.beims@toradex.com> #Verdin AM62 IW416 SD Rafael
On Fri, Dec 22, 2023 at 11:21:21AM +0800, 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. I did test this series with 88W8997, using SDIO interface, 16.68.1.p197 firmware. Host MLME is disabled in this specific combination, I just wanted to verify that no obvious regression was introduced, and I was not able to see any difference in behavior nor in performances. Tested-by: Francesco Dolcini <francesco.dolcini@toradex.com> # 88W8997-SD Francesco
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