Received-SPF: pass (google.com: domain of linux-wireless+bounces-3625-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Feedback-ID: idc214666:Fastmail
Message-ID: <b77af968-ec6f-44df-a544-4ea2a5ad3ff2@beims.me>
Date: Thu, 15 Feb 2024 09:11:17 -0300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to support host
 mlme
Content-Language: pt-BR
To: David Lin <yu-hao.lin@nxp.com>, Francesco Dolcini <francesco@dolcini.it>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "briannorris@chromium.org" <briannorris@chromium.org>,
 "kvalo@kernel.org" <kvalo@kernel.org>, Pete Hsieh <tsung-hsien.hsieh@nxp.com>
References: <20231222032123.1036277-1-yu-hao.lin@nxp.com>
 <97bb3869-3b82-4b64-87cd-9b63d4516649@beims.me>
 <PA4PR04MB96389A5DDB41DFF80CBB4738D17D2@PA4PR04MB9638.eurprd04.prod.outlook.com>
 <48364f66-99b4-40ca-b4b2-4adf1071960f@beims.me>
 <ZcSB3_16C6JTgBJB@gaggiata.pivistrello.it>
 <PA4PR04MB96381141AFBE8E61B8DD94F9D14D2@PA4PR04MB9638.eurprd04.prod.outlook.com>
From: Rafael Beims <rafael@beims.me>
In-Reply-To: <PA4PR04MB96381141AFBE8E61B8DD94F9D14D2@PA4PR04MB9638.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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