Mwifiex channel and hostapd do not match

Technical Support
, , ,
1

We are encountering a very strange issue. We have and Apalis im8 configured as a Wi-Fi Access Point. We have a verdin imx8mm configuration as a Station. The hostapd configuration is as follows:
interface=uap0
ssid=FlexNX
country_code=US
hw_mode=a
channel=0
ieee80211ac=1
ieee80211d=1
ieee80211h=1
own_ip_addr=192.168.8.1
wpa=2
wpa_pairwise=CCMP
rsn_pairwise=CCMP
wmm_enabled=1
wpa_passphrase=******
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0

Normally, everything is fine. Every once in a while the AP’s Automatic Channel selection selects channel 34 (freq = 5170), which is an invalid channel. I was able to capture this event and tried to manaully change the hostapd configuration and restart.
channel=44

The Hostapd status indicates it is transmitting on channel 44 freq=5220:
hostapd_cli status
Selected interface ‘uap0’
state=ENABLED
phy=phy0
freq=5220
num_sta_non_erp=0
num_sta_no_short_slot_time=0
num_sta_no_short_preamble=0
olbc=0
num_sta_ht_no_gf=0
num_sta_no_ht=0
num_sta_ht_20_mhz=0
num_sta_ht40_intolerant=0
olbc_ht=0
ht_op_mode=0x0
cac_time_seconds=0
cac_time_left_seconds=N/A
channel=44
edmg_enable=0
edmg_channel=0
secondary_channel=0
ieee80211n=0
ieee80211ac=1
ieee80211ax=0
beacon_int=100
dtim_period=2
vht_oper_chwidth=0
vht_oper_centr_freq_seg0_idx=0
vht_oper_centr_freq_seg1_idx=0
vht_caps_info=00000000
rx_vht_mcs_map=fffa
tx_vht_mcs_map=fffa
supported_rates=0c 12 18 24 30 48 60 6c
max_txpower=23
bss[0]=uap0
bssid[0]=34:6f:24:4f:74:ab
ssid[0]=FlexNX_00101
num_sta[0]=1

However the STA reports a different story, this is output from wpa_cli:
<3>CTRL-EVENT-DISCONNECTED bssid=34:6f:24:4f:74:ab reason=0
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>WPS-AP-AVAILABLE
<3>Trying to associate with 34:6f:24:4f:74:ab (SSID=‘FlexNX_00101’ freq=5240 MHz)
<3>Associated with 34:6f:24:4f:74:ab
<3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
<3>CTRL-EVENT-DISCONNECTED bssid=34:6f:24:4f:74:ab reason=0
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>WPS-AP-AVAILABLE
<3>Trying to associate with 34:6f:24:4f:74:ab (SSID=‘FlexNX_00101’ freq=5170 MHz)
<3>Associated with 34:6f:24:4f:74:ab
<3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
<3>WPA: Key negotiation completed with 34:6f:24:4f:74:ab [PTK=CCMP GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to 34:6f:24:4f:74:ab completed [id=0 id_str=]
status

bssid=34:6f:24:4f:74:ab
freq=5170
ssid=FlexNX_00101
id=0
mode=station
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=192.168.8.163
address=ec:2e:98:86:f9:6d
uuid=2687faab-195c-5a57-9407-be0ad9dc7d1e

It still indicates channel 34 frequency 5170!!! It looks like the AP started at channel 44, but then switched back to channel 34.

This problem has been very elusive as our verdin based stations remain connected while PC’s and phones cannot see this AP. I haven’t seen anyone else with this issue so we are getting desperate.

Our OS is based from the Toradex yocto BSP reference image 6.9.0 (kirkstone).

Any help or information you can provide would be greatly appreciated.
Thank you,
Jeff

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Based on the context provided, it seems that the issue arises from the automatic channel selection feature of the hostapd configuration, which is selecting an invalid channel (channel 34, freq=5170) for the US region. This is causing connectivity issues, particularly for devices like PCs and phones, while some Verdin-based stations remain connected.

Here are some steps you can take to address this issue:

  1. Manual Channel Configuration: As you have already attempted, setting the channel manually to a valid channel (e.g., channel 44) is a good step. Ensure that this configuration is persistent and not overridden by any other scripts or configurations.

  2. Firmware and Software Updates: Check for any available updates for the hostapd software and the firmware of the Wi-Fi module. Updates may contain fixes for known issues related to channel selection.

  3. Configuration Verification: Double-check the hostapd configuration file to ensure there are no conflicting settings that might cause the channel to revert to an invalid one. Also, verify that no other processes or scripts are modifying the configuration at runtime.

  4. Logging and Monitoring: Implement detailed logging to capture events related to channel changes. This can help identify the exact conditions under which the channel switches back to an invalid one.

  5. Regulatory Domain Settings: Ensure that the regulatory domain settings are correctly configured for the US. This can be done by setting the correct country code in the hostapd configuration and ensuring that the kernel’s regulatory database is up to date.

  6. Hardware Compatibility: Verify that the Wi-Fi hardware being used is fully compatible with the channels and configurations being set. Some hardware might have limitations or require specific configurations to operate correctly.

If these steps do not resolve the issue, further investigation into the specific hardware and software interactions may be necessary, possibly involving support from Toradex or the hardware vendor.

Please, also check if these links can help you solve your problem:

iMX8 Wifi Access point unreliable.

3

Hey @mackin_jeff,

A few ideas:

Can you run iw reg get and post the output, this should ouput the current regulatory domain (US) configuration on the device(the apalis). I just want to make sure.

And can you also run sudo journalctl -u hostapd after this ACS event occurs, this should give us some more information.

It’s possible the network manager (connman) is interfering as well. You may be able to disable/stop the service sudo systemctl stop connman to see if the problem persists.

-Eric

4

One more question on the Apalis iMX8 Wi-Fi firmware. It appears as though the mwifiex driver is loading the Firmware file /lib/firmware/mrvl/pcieusb8997_combo_v4.bin, is this correct?
I’ve noticed this file is 639044 bytes while the version I downloaded at
kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel tag 20220509 is 638992. I would expect these to be the same as I don’t see it overwritten in any bbappend files in the yocto BSP.

5

iw reg get:

phy#0
country US: DFS-FCC
(902 - 904 @ 2), (N/A, 30), (N/A)
(904 - 920 @ 16), (N/A, 30), (N/A)
(920 - 928 @ 8), (N/A, 30), (N/A)
(2400 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
(5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN
(5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR, PASSIVE-SCAN
(57240 - 71000 @ 2160), (N/A, 40), (N/A)

6

connman is configured by a Toradex to blacklist the uap0 interface in the bbappend recipe file meta-toradex-demos\recipes-connectivity\connman\connman\0001-Adjust-main-configuration.patch.
Re-creating the issue takes a long time and disabling connman leave me without a debug interface.

7

I disabled connman and still saw the issue. This is the wpa_cli output from the station:
<3>Trying to associate with 34:6f:24:4f:74:ab (SSID=‘FlexNX_00101’ freq=5260 MHz)
<3>Associated with 34:6f:24:4f:74:ab
<3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
<3>WPA: Key negotiation completed with 34:6f:24:4f:74:ab [PTK=CCMP GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to 34:6f:24:4f:74:ab completed [id=0 id_str=]
<3>CTRL-EVENT-DISCONNECTED bssid=34:6f:24:4f:74:ab reason=0
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>Trying to associate with 34:6f:24:4f:74:ab (SSID=‘FlexNX_00101’ freq=5170 MHz)
<3>Associated with 34:6f:24:4f:74:ab
<3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
<3>WPA: Key negotiation completed with 34:6f:24:4f:74:ab [PTK=CCMP GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to 34:6f:24:4f:74:ab completed [id=0 id_str=]

The hostapd journal only has the start:

Nov 11 16:26:04 FlexNX-00101 systemd[1]: Starting Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator…
Nov 11 16:26:05 FlexNX-00101 systemd[1]: Started Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator.

And connman is definitely not running:
systemctl status connman

  • connman.service - Connection service
    Loaded: loaded (/lib/systemd/system/connman.service; disabled; vendor preset: enabled)
    Active: inactive (dead)
8

Hey @mackin_jeff,

Thanks for verifying all of that. Is there a way to recreate the event happening? Or does this randomly occur?

-Eric

9

It’s pretty random. During our QA testing this is reported every few days. However I have rebooting the system over and over and I saw it twice today. I am monitoring the AP with a verdin based station, watching the events on wpa_cli. If I see freq=5170 (channel 34), I know that has happened.

10

Hey @mackin_jeff,

Do you have another Apalis that you can try, to see if the problem might be hardware related rather than software?

-Eric

11

This is a problem we have seen on many units so I don’t think it’s hardware related. I added the “chanlist” configuration to hostapd, and am updating the linux-firmware-nxp89xx recipe in yocto to use the latest pcie8997_combo_v4.bin instead of the older pcieusb8997_combo_v4.bin in the kernel archives (we don’t need bluetooth). Hopefully this will sort out this issue.

12

Hey @mackin_jeff,

Checking in, did updating the binary resolve the issue?

-Eric