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
