On 22/02/2024 05:01, David Lin wrote:
From: Rafael Beims <rafael@xxxxxxxx>
Sent: Friday, February 16, 2024 6:11 PM
To: David Lin <yu-hao.lin@xxxxxxx>; Francesco Dolcini <francesco@xxxxxxxxxx>
Cc: linux-wireless@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
briannorris@xxxxxxxxxxxx; kvalo@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 15/02/2024 22:48, David Lin wrote:
From: David Lin
Sent: Friday, February 16, 2024 9:41 AM
To: Rafael Beims <rafael@xxxxxxxx>; Francesco Dolcini
<francesco@xxxxxxxxxx>
Cc: linux-wireless@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
briannorris@xxxxxxxxxxxx; kvalo@xxxxxxxxxx; Pete Hsieh
<tsung-hsien.hsieh@xxxxxxx>
Subject: RE: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to
support host mlme
From: Rafael Beims <rafael@xxxxxxxx>
Sent: Thursday, February 15, 2024 8:11 PM
To: David Lin <yu-hao.lin@xxxxxxx>; Francesco Dolcini
<francesco@xxxxxxxxxx>
Cc: linux-wireless@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
briannorris@xxxxxxxxxxxx; kvalo@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 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
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@xxxxxxxxxxx> #Verdin AM62 IW416 SD
Rafael
