> From: Rafael Beims <rafael@xxxxxxxx> > Sent: Friday, February 16, 2024 6:11 PM > To: David Lin <yu-hao.lin@xxxxxxx>; Francesco Dolcini <francesco@xxxxxxxxxx> > Cc: linux-wireless@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > briannorris@xxxxxxxxxxxx; kvalo@xxxxxxxxxx; Pete Hsieh > <tsung-hsien.hsieh@xxxxxxx> > 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 15/02/2024 22:48, David Lin wrote: > >> From: David Lin > >> Sent: Friday, February 16, 2024 9:41 AM > >> To: Rafael Beims <rafael@xxxxxxxx>; Francesco Dolcini > >> <francesco@xxxxxxxxxx> > >> Cc: linux-wireless@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > >> briannorris@xxxxxxxxxxxx; kvalo@xxxxxxxxxx; Pete Hsieh > >> <tsung-hsien.hsieh@xxxxxxx> > >> Subject: RE: [EXT] Re: [PATCH v8 0/2] wifi: mwifiex: add code to > >> support host mlme > >> > >>> From: Rafael Beims <rafael@xxxxxxxx> > >>> Sent: Thursday, February 15, 2024 8:11 PM > >>> To: David Lin <yu-hao.lin@xxxxxxx>; Francesco Dolcini > >>> <francesco@xxxxxxxxxx> > >>> Cc: linux-wireless@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > >>> briannorris@xxxxxxxxxxxx; kvalo@xxxxxxxxxx; Pete Hsieh > >>> <tsung-hsien.hsieh@xxxxxxx> > >>> 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@xxxxxxxxxx> > >>>>> Sent: Thursday, February 8, 2024 3:25 PM > >>>>> To: Rafael Beims <rafael@xxxxxxxx> > >>>>> Cc: David Lin <yu-hao.lin@xxxxxxx>; > >>>>> linux-wireless@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > >>>>> briannorris@xxxxxxxxxxxx; kvalo@xxxxxxxxxx; francesco@xxxxxxxxxx; > >>>>> Pete Hsieh <tsung-hsien.hsieh@xxxxxxx> > >>>>> 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@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 > >>>> 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.go/ > ogle.com%2Fg%2Fbeagleboard%2Fc%2F3Um2Xqa2MHU&data=05%7C02%7Cy > u-hao.lin%40nxp.com%7C4c74f7c309e243eb6c0c08dc2ed78b4c%7C686ea1d3 > bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638436750492293425%7CUnknow > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW > wiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=99eQWmm39kbo63JKNFbiljFQz > o%2Bz7ki%2FSsllw%2FdonbE%3D&reserved=0 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 > 1. Without host mlme, management packet filter of AP mode is the same as client mode. Authentication/Association packets are handled by firmware and once if station is connected, firmware will send station connection event to driver. So you can still start wpa_supplicant and hostapd on uap0 at same time. However, this is not correct setting and usage. 2. With host mlme, management packet filter of AP mode is not the same as client mode. Authentication/Association packets are sent to hostapd, so cfg80211 won't allow wpa_supplicant and hostapd run on uap0 at same time (different management packet filter). I think no matter with or without patch v8, setting of connman for uap0 should not be client mode. Setting of connman for uap0 should be ap mode or bypass to control it as client mode. The behavior of patch v8 is correct and it can avoid user to run wpa_supplicant and hostapd on AP wireless interface at same time. There is no side effect of patch v8 for this behavior. I also found document from Toradex about how to run connman for AP mode: https://developer.toradex.com/linux-bsp/application-development/networking-connectivity/how-to-setup-wi-fi-access-point-mode-linux/ Please check section 8: Enable and start hostapd service: First, make sure to blacklist the uap0 interface on connmanctl by adding it to NetworkInterfaceBlacklist at connman/main.conf. I think to block uap0 from connman is correct way to run hostapd on uap0. David
