linux-kernel - Re: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to support host mlme

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b77af968-ec6f-44df-a544-4ea2a5ad3ff2@beims.me>
Date: Thu, 15 Feb 2024 09:11:17 -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 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