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

[Francesco Dolcini]

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