Message-ID: <3d1c45bd-fb89-4a4c-8f53-b1775f6c9a3e@beims.me>
Date: Fri, 16 Feb 2024 07:10:42 -0300
From: Rafael Beims <rafael@...ms.me>
To: David Lin <yu-hao.lin@....com>, Francesco Dolcini <francesco@...cini.it>
Cc: "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "briannorris@...omium.org" <briannorris@...omium.org>,
 "kvalo@...nel.org" <kvalo@...nel.org>, Pete Hsieh <tsung-hsien.hsieh@....com>
Subject: Re: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to support host
 mlme

On 15/02/2024 22:48, David Lin wrote:
>> From: David Lin
>> Sent: Friday, February 16, 2024 9:41 AM
>> To: Rafael Beims <rafael@...ms.me>; Francesco Dolcini
>> <francesco@...cini.it>
>> Cc: linux-wireless@...r.kernel.org; linux-kernel@...r.kernel.org;
>> briannorris@...omium.org; kvalo@...nel.org; Pete Hsieh
>> <tsung-hsien.hsieh@....com>
>> Subject: RE: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to support host
>> mlme
>>
>>> From: Rafael Beims <rafael@...ms.me>
>>> Sent: Thursday, February 15, 2024 8:11 PM
>>> To: David Lin <yu-hao.lin@....com>; Francesco Dolcini
>>> <francesco@...cini.it>
>>> Cc: linux-wireless@...r.kernel.org; linux-kernel@...r.kernel.org;
>>> briannorris@...omium.org; kvalo@...nel.org; Pete Hsieh
>>> <tsung-hsien.hsieh@....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@...cini.it>
>>>>> Sent: Thursday, February 8, 2024 3:25 PM
>>>>> To: Rafael Beims <rafael@...ms.me>
>>>>> Cc: David Lin <yu-hao.lin@....com>; linux-wireless@...r.kernel.org;
>>>>> linux-kernel@...r.kernel.org; briannorris@...omium.org;
>>>>> kvalo@...nel.org; 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
>>>>>
>>>>> 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@...ms.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

Powered by blists - more mailing lists