On 14/02/2024 23:07, David Lin wrote:
From: Francesco Dolcini <francesco@xxxxxxxxxx>
Sent: Thursday, February 8, 2024 3:25 PM
To: Rafael Beims <rafael@xxxxxxxx>
Cc: David Lin <yu-hao.lin@xxxxxxx>; linux-wireless@xxxxxxxxxxxxxxx;
linux-kernel@xxxxxxxxxxxxxxx; briannorris@xxxxxxxxxxxx; kvalo@xxxxxxxxxx;
francesco@xxxxxxxxxx; Pete Hsieh <tsung-hsien.hsieh@xxxxxxx>
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@xxxxxxxx> 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
