Mwifiex driver crashing when using AP and station mode

Technical Support
, , ,
1

The WiFi interface driver mwifiex_sdio crashes similar as described in another thread [1], when conducting the following experiment.

  1. Start hostapd for uap0.
  2. Connect a host to the hostapd network and start pinging.
  3. Connect mlan0 to a WiFi network.
  4. Disconnect from mlan0 or shut down the AP and let mlan0 go down.

After step 3 or step 4, WiFi crashes and the interfaces disappear, sometimes immediately, other times after repeating step 3 and 4 a couple of times. First it seemed that this is only if both uap0 and mlan0 are operating on the same band, but that observation turned out to be wrong after some further testing.

cat /etc/hostapd.conf

interface=uap0
bridge=br0
hw_mode=a
channel=36
ieee80211ac=1
wmm_enabled=1
country_code=CH
rsn_pairwise=CCMP
group_cipher=CCMP

wpa=2
ssid=asterix
wpa_passphrase=hinkelstein

[  780.130005] IPv4: martian source 192.168.230.18 from 192.168.230.120, on dev mlan0
[  780.130029] ll header: 00000000: 10 68 38 da c3 c5 ca 7c 1f 0d 37 94 08 00
[  827.248943] mwifiex_sdio mmc0:0001:1: info: successfully disconnected from ca:7c:1f:0d:37:94: reason code 3
[  847.869207] mwifiex_sdio mmc0:0001:1: info: trying to associate to bssid ca:7c:1f:0d:37:94
[  858.142387] mwifiex_sdio mmc0:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id = 0x12, act = 0x7cca
[  858.142420] mwifiex_sdio mmc0:0001:1: num_data_h2c_failure = 0
[  858.142430] mwifiex_sdio mmc0:0001:1: num_cmd_h2c_failure = 0
[  858.142440] mwifiex_sdio mmc0:0001:1: is_cmd_timedout = 1
[  858.142449] mwifiex_sdio mmc0:0001:1: num_tx_timeout = 0
[  858.142458] mwifiex_sdio mmc0:0001:1: last_cmd_index = 3
[  858.142468] mwifiex_sdio mmc0:0001:1: last_cmd_id: 28 00 28 00 16 00 12 00 10 00
[  858.142478] mwifiex_sdio mmc0:0001:1: last_cmd_act: 13 00 13 00 01 00 ca 7c 01 00
[  858.142489] mwifiex_sdio mmc0:0001:1: last_cmd_resp_index = 2
[  858.142498] mwifiex_sdio mmc0:0001:1: last_cmd_resp_id: 28 80 28 80 16 80 28 80 10 80
[  858.142508] mwifiex_sdio mmc0:0001:1: last_event_index = 4
[  858.142517] mwifiex_sdio mmc0:0001:1: last_event: 58 00 58 00 58 00 58 00 58 00
[  858.142527] mwifiex_sdio mmc0:0001:1: data_sent=0 cmd_sent=0
[  858.142537] mwifiex_sdio mmc0:0001:1: ps_mode=0 ps_state=0
[  858.142574] mwifiex_sdio mmc0:0001:1: info: association to bssid ca:7c:1f:0d:37:94 failed
[  858.143066] mwifiex_sdio mmc0:0001:1: ===mwifiex driverinfo dump start===
[  858.143084] mwifiex_sdio mmc0:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (16.92.21.p137) 
[  858.143114] mwifiex_sdio mmc0:0001:1: SDIO register dump start
[  858.143341] mwifiex_sdio mmc0:0001:1: SDIO Func0 (0x0-0x9): 43 03 02 02 03 00 00 02 03 00 
[  858.143479] mwifiex_sdio mmc0:0001:1: SDIO Func1 (0x10-0x17): 00 00 00 00 00 00 c0 ff 
[  858.143685] mwifiex_sdio mmc0:0001:1: SDIO Func1: (0x8) c3 (0x58) 00 (0x5c) 08 (0x5d) 00 (0x60) 07 (0x61) 0c (0x62) 00 (0x64) 10 (0x65) 00 (0x66) 00 (0x68) 00 (0x69) 00 (0x6a) 00 
[  858.143863] mwifiex_sdio mmc0:0001:1: SDIO Func1 (0xe8-0xf2): XX YY ZZ 00 2a 00 07 04 24 14 70 
[  858.146529] mwifiex_sdio mmc0:0001:1: PREP_CMD: FW is in bad state
[  858.243810] mwifiex_sdio mmc0:0001:1: Ignore scan. Card removed or firmware in bad state
[  858.243828] mwifiex_sdio mmc0:0001:1: scan failed: -14
[  858.246237] mwifiex_sdio mmc0:0001:1: SDIO Func1 (0xe8-0xf2): XX YY ZZ 00 34 00 07 04 24 14 70 
[  858.246256] mwifiex_sdio mmc0:0001:1: SDIO register dump end
[  858.246308] mwifiex_sdio mmc0:0001:1: ===mwifiex driverinfo dump end===
[  858.246440] mwifiex_sdio mmc0:0001:1: == mwifiex firmware dump start ==
[  858.268853] mwifiex_sdio mmc0:0001:1: Fail to pull ctrl_data
[  858.268869] mwifiex_sdio mmc0:0001:1: firmware dump failed
[  858.268879] mwifiex_sdio mmc0:0001:1: == mwifiex dump information to /sys/class/devcoredump start
[  858.269015] mwifiex_sdio mmc0:0001:1: == mwifiex dump information to /sys/class/devcoredump end
[  858.269026] mwifiex_sdio mmc0:0001:1: PREP_CMD: FW is in bad state
[  858.269259] mwifiex_sdio mmc0:0001:1: info: shutdown mwifiex...
[  858.269285] mwifiex: Have pending ack frames!
[  858.269785] mwifiex_sdio mmc0:0001:1: PREP_CMD: card is removed
[  858.272054] mwifiex_sdio mmc0:0001:1: PREP_CMD: card is removed
[  858.322927] mwifiex_sdio mmc0:0001:1: PREP_CMD: card is removed
[  858.322954] mwifiex_sdio mmc0:0001:1: Failed to delete mgmt IEs!
[  858.322960] mwifiex_sdio mmc0:0001:1: PREP_CMD: card is removed
[  858.322965] mwifiex_sdio mmc0:0001:1: Failed to stop the BSS
[  858.323532] br0: port 1(uap0) entered disabled state
[  858.323728] mwifiex_sdio mmc0:0001:1: PREP_CMD: card is removed
[  858.326634] mwifiex_sdio mmc0:0001:1 uap0 (unregistering): left allmulticast mode
[  858.326656] mwifiex_sdio mmc0:0001:1 uap0 (unregistering): left promiscuous mode
[  858.326669] br0: port 1(uap0) entered disabled state
[  858.413381] mwifiex_sdio mmc0:0001:1: PREP_CMD: card is removed
[  858.683147] mwifiex_sdio mmc0:0001:1: WLAN FW already running! Skip FW dnld
[  858.683169] mwifiex_sdio mmc0:0001:1: WLAN FW is active
[  869.022585] mwifiex_sdio mmc0:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id = 0xa9, act = 0x0
[  869.022626] mwifiex_sdio mmc0:0001:1: num_data_h2c_failure = 0
[  869.022637] mwifiex_sdio mmc0:0001:1: num_cmd_h2c_failure = 0
[  869.022646] mwifiex_sdio mmc0:0001:1: is_cmd_timedout = 1
[  869.022656] mwifiex_sdio mmc0:0001:1: num_tx_timeout = 0
[  869.022664] mwifiex_sdio mmc0:0001:1: last_cmd_index = 4
[  869.022676] mwifiex_sdio mmc0:0001:1: last_cmd_id: 28 00 28 00 16 00 12 00 a9 00
[  869.022686] mwifiex_sdio mmc0:0001:1: last_cmd_act: 13 00 13 00 01 00 ca 7c 00 00
[  869.022696] mwifiex_sdio mmc0:0001:1: last_cmd_resp_index = 2
[  869.022705] mwifiex_sdio mmc0:0001:1: last_cmd_resp_id: 28 80 28 80 16 80 28 80 10 80
[  869.022714] mwifiex_sdio mmc0:0001:1: last_event_index = 4
[  869.022723] mwifiex_sdio mmc0:0001:1: last_event: 58 00 58 00 58 00 58 00 58 00
[  869.022735] mwifiex_sdio mmc0:0001:1: data_sent=1 cmd_sent=0
[  869.022745] mwifiex_sdio mmc0:0001:1: ps_mode=0 ps_state=0
[  869.032738] mwifiex_sdio mmc0:0001:1: info: _mwifiex_fw_dpc: unregister device

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.84-7.2.0-g87bfb710b6f1 #1-Torizon SMP PREEMPT Mon Mar 31 08:47:48 UTC 2025
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/ec5fdc9bc7c0ebcb94571134de99e8315cf167c45f92d826d0535da5317de216/0
Distro name:              NAME="Torizon OS"
Distro version:           VERSION_ID=7.2.0-build.13
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-15336914
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version:          0064 V1.1A
Serial number:            15336914
Processor arch:           aarch64
------------------------------------------------------------

[1] Mwifiex crashes when creating an accesspoint - #4 by qojote

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello! Thank you for providing a detailed description and relevant logs. Based on your report and current documentation, here’s a summary and some recommendations:

Key Points

  1. AW-CM276NF Module Limitation
    The Wi-Fi module on your Verdin iMX8M Plus (AW-CM276NF) is a single MAC device, which means it can only operate on one channel at a time—across both AP (uap0) and STA (mlan0) modes. Running concurrent AP and station interfaces can therefore result in conflicts if the underlying driver/firmware isn’t handling these transitions robustly (reference).

  2. Driver and Firmware Issues
    The mwifiex_sdio driver is known to have stability issues, particularly when toggling between AP and STA roles or manipulating both interfaces concurrently, and especially on newer kernel versions. Your logs indicate the firmware is entering a bad state after these operations, which matches known limitations (reference). The line PREP_CMD: FW is in bad state and other timeouts suggest kernel/driver/firmware desynchronization.

  3. Recent SDIO Driver Concerns
    Investigations point to driver issues most pronounced when using the SDIO-based Wi-Fi on Verdin iMX8M Plus modules (reference).

Recommendations

1. Channel & Band Consistency

Even though you noted that the crash seems independent of the Wi-Fi band/channel, the documentation still recommends for dual mode (AP + STA) on single-MAC devices, both interfaces should use the same band and channel. Mismatched settings often escalate driver/firmware instability.

  • Ensure both the AP (hostapd) and station (mlan0) are on the same band and, ideally, the same channel. If possible, configure both networks to operate in 5GHz band on, for example, channel 36.

2. Driver Alternatives

If you experience instability with the mainline mwifiex_sdio driver, it is possible to explore NXP’s downstream kernel drivers, which may offer more robust support for this use case (reference). However, migrating to these drivers may involve custom kernel development.

3. Reset & Recovery Script

When the Wi-Fi crashes and interfaces disappear, a hardware-level reset or module reload is required. Consider automating this with a script to unbind/rebind the SDIO device, or perform a system reboot upon detection of failure. While this is more of a workaround, it can restore network functionality in unattended systems.

4. Minimize State Flipping

Reduce the frequency of state changes between AP and STA, and avoid frequent toggling or rapid connect/disconnect cycles since the current driver/firmware combination seems especially fragile under these conditions.

5. Monitor for Updates

Stay updated with new Torizon OS releases, as ongoing work may produce fixes or workarounds for your hardware/kernel combination.

Important:
Due to the module and driver limitations, fully robust AP+STA operation is not always achievable on this platform. Review your application requirements and, if possible, consider separating infrastructure (STA) and soft-AP features across different hardware modules to maximize stability.

Let me know if you’d like configuration examples or additional troubleshooting steps.

Best regards,
Toradex AI Assistant.

3

Dear @simon.isg,

I believe the issue might be that you are using the module as AP and station (STA) simultaneously, which is in itself is possible, though it should be noted that in order for that to work they must operate on the same channel (either 2.4GHz or 5GHz).

Best regards,
Collin

4

Hi Collin,

Thanks a lot for your answer. Do you have a working example which allows to operate the module as AP and STA and gracefully handle channel changes, e.g. when some roaming or band steering happens for the AP the embedded device is connected to?

Thanks,
Simon

5

Dear @simon.isg,

thank you for your reply. May I ask what your specific use-case is? I would like to understand why you are trying to use the Wi-Fi module as both AP and STA.

Regarding you question we have the following two pages, which describe how you can get the Access point mode as well as the client mode (which is the station mode).

In general channel changes are not recommended, since for this setup to work you will have to use the same channel for both of the modes.

Looking through a test we conducted in the past I found the following steps that were taken for Torizon OS.

General setup:
Disable docker-compose service: sudo systemctl disable docker-compose
Create the /etc/NetworkManager/conf.d/99-disable-uap.conf:

[main]
plugins=keyfile

[keyfile]
unmanaged-devices=interface-name:uap*

Create the /etc/systemd/network/80-wifi-ap.network :

[Match]
Name=uap0
Type=wlan
WLANInterfaceType=ap

[Network]
Address=192.168.0.1/24
DHCPServer=yes

[DHCPServer]
PoolOffset=10
PoolSize=30
EmitDNS=yes
DNS=8.8.8.8

STA configuration:
Two available APs from the same router are available:

  • 2.4GHz
    • STA-wifi-2G
    • STA-2G
  • 5GHz
    • STA-wifi-5G
    • STA-5G

To connect to those APs, the following script and commands were used.

  • To connect with STA-wifi-2G, it should be launched with ./start-sta.sh 2G
  • To connect with STA-wifi-5G, it should be launched with ./start-sta.sh 5G
set -x

wifi_frequency=$1

case ${wifi_frequency} in
        2G)

                echo Wi-Fi 2.4GHz was selected
                ;;
        5G)
                echo Wi-Fi 5GHz was selected
                ;;
        *)
                echo "first argument (wifi frequency) must be either 2G or 5G!"
                exit 1
                ;;
esac

wifi_ssid=STA-wifi-${wifi_frequency}
wifi_password=STA-${wifi_frequency}

nmcli device wifi list | cat
nmcli device wifi connect ${wifi_ssid} password ${wifi_password}
nmcli connection modify ${wifi_ssid} connection.autoconnect no

sleep 5

ping 8.8.8.8 -c 3 || (echo "Could't connect to internet! ping failed!" && exit 2)

iw dev

ip_address=$(ip addres show dev wlo1 || ip address show dev mlan0)
echo ${ip_address} | grep -P "mlan|wlo" && echo "We got IPV4! All good!" || (echo "We got no IPV4 address! Exiting" && exit 3)

set +x

AP configuration:
To create and run the access point on the module, the following script and commands are used:

  • To create the AP with 2G, it should be launched with ./start-ap.sh 2G
  • To create the AP with 5G, it should be launched with ./start-ap.sh 5G
set -x

if [ "$EUID" -ne 0 ]; then
  echo "This script must be run as sudo."
  exit 1
fi

ap_frequency=$1
case ${ap_frequency} in
        5G)
                ssid=test-wifi-5GHz
                hw_mode=a
                channel=40
                ieee80211_config="ieee80211n=1"
                ;;
        2G)
                ssid=test-wifi-2GHz
                hw_mode=g
                channel=1
                ieee80211_config=""
                ;;
        *)
                echo "first argument must be 5G or 2G for AP frequency!"
                ;;
esac

cat <<EOF > /etc/hostapd.conf
interface=uap0
ssid=${ssid}
hw_mode=${hw_mode}
channel=${channel}
own_ip_addr=192.168.0.1
wpa=2
wpa_passphrase=test123456789
${ieee80211_config}
EOF

systemctl start hostapd

sleep 5

systemctl --no-pager status hostapd

iw dev

ip address show dev uap0

set +x

Please let me know how you fare with this approach.

Best regards,
Collin

6

Hi Collin,

Thanks a lot for your detailed reply.

The use cases could be as follows (more details via PM):

  • My device is connected to the office WiFi, and I connect my notebook to the device via a dedicated management WiFi provided by the device as AP (e.g. like done in some IoT devices).
  • My device is like a router - my host connects to the Toradex device, and the Toradex device uses the office network to connect to the internet.

My concern is as follows:

  • I set up the WiFi STA and AP as you describe. Things work properly for some time, both STA and AP operate on the same channel.
  • The office AP all of a sudden decides that the STA should change e.g. from 2.4GHz to 5GHz (e.g. via bandsteering), or the device is moved to another room, where another office AP has a stronger signal, and therefore NetworkManager decides (as it should be) to use the stronger AP.

In such cases, we need to react accordingly.

Thanks,
Simon

7

Dear @simon.isg,

Thank you for your explanation. From the top of my head something that might aid you in this would likely be to first detect/monitor the channel changes via either iwconfig or iw dev mlanX info. Should a switch have occurred, you would likely then have to restart the AP (uap0) on the new channel used by the STA. This however feels a little “hacky” in my opinion.

A second way might be to use the dbus API for NetworkManager. With that you could acquire/monitor the information of your STA. It is capable of detecting roaming or bandsteering events in somewhat real-time. You could then alter the AP within your application as soon as a change is noticed.

Best regards,
Collin

8

Hi Collin

Thanks a lot for your explanation. From my experiments I conclude that the monitoring approach can lead to race conditions - if we’re not detecting fast enough, the change might happen for mlan0, while uap0 is still on the old channel. This then causes the driver to crash.

For the time being we fix the channel in NetworkManager once connected on mlan0 to prevent any roaming or bandsteering.

Thank you very much.

9

Dear @simon.isg,

Thank you very much for sharing your findings. Interesting that mlan0 fetching the new connection first causes the driver to crash. Your workaround does sound very reasonable though.

Please let me know if there is anything else surrounding this I could help you with.

Best regards,
Collin

10

One addendum: The country code must be set in hostapd, otherwise the behaviour in case of the roaming procedure described above reaches from not being able to set the AP (NO_IR locked channels on 5GHz) to driver crashes.

Thanks for your support Collin, I think the ticket can be closed.

1 Like