Hi,
I am using a iMX8 module to create Wifi accesspoints. Once a client successfully connected the AP is closed, reconfigured for another channel and reopened. However after some AP creation attemeps the mwifiex driver crashes like shown below. Any help would be much appreciated!
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Greetings,
The issue you’re encountering with the mwifiex driver crashing on your Apalis iMX8QP 2GB WB module when creating and reconfiguring WiFi access points appears to be related to the firmware or driver state not handling the rapid changes in configuration robustly. Here are several steps and considerations to help address or mitigate the issue:
Firmware and Driver Update: Ensure that your system is running the latest firmware and drivers for the WiFi module. Firmware bugs and driver issues can often lead to instability, especially under non-standard operating conditions such as rapidly reconfiguring the access point settings.
Serializing Access Point Operations: If your application logic allows, consider adding a delay between shutting down the access point and reconfiguring it for a new channel. This can give the firmware and driver stack more time to properly reset its state and may prevent the crash.
Reviewing Driver Logs: Look into the kernel logs (dmesg) for any warnings or errors that precede the crash. These logs can provide clues on what the driver or firmware was doing right before the failure occurred. It’s possible that specific operations or sequences of operations are triggering a bug.
Limiting Rapid Reconfigurations: If the use case permits, try to limit the frequency of access point reconfigurations. Continuous reconfiguration might be pushing the driver or hardware into an untested or unstable state.
Debugging and Reporting: If the issue persists, consider enabling more detailed logging for the mwifiex driver if available. This could provide further insights into the failure. Reporting this issue to the maintainers of the mwifiex driver with detailed logs and steps to reproduce can also help in identifying and fixing the bug.
Alternative Configurations: Evaluate if your application’s requirements could be met with less frequent changes to the WiFi access point settings or by using a fixed channel if the environment allows.
Hardware Considerations: Although less likely, hardware issues or limitations could also contribute to such problems. Ensure that the WiFi module is properly seated in the carrier board and that there are no hardware faults.
Remember, continuous rapid reconfiguration of WiFi settings is a relatively uncommon use case, and the driver or firmware might not be optimized for such operations. If the problem is critical to your application and cannot be resolved through the above suggestions, consider reaching out to the community or forums where developers discuss similar issues for potential workarounds or patches.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
Just to summarize. You create a bunch of access-points and after some attempts it stops working. Is that more or less right?
Some questions.
How are you exactly creating these access-points?
Is this issue predictably reproducible? Or is there some random elements to it? For example does it always fail on the 10th attempt, or something like that?
Finally, I assume restating the driver/system brings it back into a good state?
Hi @jeremias.tx,
I am creating an accesspoint with hostapd (see config script below) on my iMX8. Once the AP is started a Raspberry Pi scans for this specific SSID and connects. As far as i remember the connection always works at the first time. Then the connection is closed and the AP is reconfigured for another channel. Starting the AP again does also work. Typically the next connection attempt causes this issue on the iMX8 site. I was never able to do that procedure more than three times before the mwifiex driver crashes.
Sometimes the driver reloads automatically - in that case my program can be rerun but it will trigger that issue again.
uap0: AP-ENABLED
uap0: STA 00:0e:8e:ab:13:8a IEEE 802.11: associated
uap0: STA 00:0e:8e:ab:13:8a WPA: event 1 notification
uap0: STA 00:0e:8e:ab:13:8a WPA: start authentication
uap0: STA 00:0e:8e:ab:13:8a IEEE 802.1X: unauthorizing port
uap0: STA 00:0e:8e:ab:13:8a WPA: sending 1/4 msg of 4-Way Handshake
uap0: STA 00:0e:8e:ab:13:8a WPA: EAPOL-Key timeout
uap0: STA 00:0e:8e:ab:13:8a WPA: sending 1/4 msg of 4-Way Handshake
uap0: STA 00:0e:8e:ab:13:8a IEEE 802.1X: did not Ack EAPOL-Key frame (unicast index=27)
uap0: STA 00:0e:8e:ab:13:8a IEEE 802.1X: did not Ack EAPOL-Key frame (unicast index=27)
uap0: STA 00:0e:8e:ab:13:8a WPA: EAPOL-Key timeout
uap0: STA 00:0e:8e:ab:13:8a WPA: sending 1/4 msg of 4-Way Handshake
uap0: STA 00:0e:8e:ab:13:8a IEEE 802.1X: did not Ack EAPOL-Key frame (unicast index=27)
uap0: STA 00:0e:8e:ab:13:8a WPA: EAPOL-Key timeout
uap0: STA 00:0e:8e:ab:13:8a WPA: sending 1/4 msg of 4-Way Handshake
uap0: STA 00:0e:8e:ab:13:8a IEEE 802.1X: did not Ack EAPOL-Key frame (unicast index=27)
uap0: STA 00:0e:8e:ab:13:8a WPA: EAPOL-Key timeout
uap0: STA 00:0e:8e:ab:13:8a WPA: PTKSTART: Retry limit 4 reached
uap0: STA 00:0e:8e:ab:13:8a WPA: event 3 notification
uap0: STA 00:0e:8e:ab:13:8a IEEE 802.1X: unauthorizing port
uap0: STA 00:0e:8e:ab:13:8a MLME: MLME-DEAUTHENTICATE.indication(00:0e:8e:ab:aa:cc, 15)
uap0: STA 00:0e:8e:ab:13:8a MLME: MLME-DELETEKEYS.request(00:0e:8e:ab:aa:cc)
uap0: STA 00:0e:8e:ab:13:8a IEEE 802.11: disassociated
uap0: STA 00:0e:8e:ab:13:8a WPA: event 2 notification
uap0: STA 00:0e:8e:ab:13:8a IEEE 802.1X: unauthorizing port
uap0: interface state ENABLED->DISABLED
uap0: AP-DISABLED
and another dmesg printout. First three connections worked. Then it crashed.
Okay I spent some time trying to reproduce this on my own setup and I think I’ve done it at least once. Took me more connection attempts than the three times you described but nonetheless after several back and forth connection attempts it seems like I got the driver to crash with logs similar to what you shared.
In the end the hostapd.conf I was using wasn’t even that similar to yours:
Which tells me that your specific hostapd.conf isn’t causing the issue. It seems like the issue can just manifest due to repeated connection attempts within a short time frame. Let me report this internally and see what our team can come up with.
You may need to come up with a workaround of sorts in the meantime, as there is no telling how complex this issue may be and how long it will take to investigate and possibly fix. I suppose unloading and reloading the driver when a crash is detected would be the only practical workaround at the moment.
Hi @jeremias.tx,
Thanks for your investigations. In the mean time i did some further testing. First of all it seems like that problem only occurs when using WPA2. And it seems to be more likely to trigger that issue when changing the channels during the connection attempts. I am looping channels 1-13 in standard “g” and the driver is crashing almost every time at the third connection attempt.
How can i recognize that crash?
BR
First of all it seems like that problem only occurs when using WPA2.
This does seem to be a possible factor or at least all my attempts before had WPA2 configured.
I am looping channels 1-13 in standard “g” and the driver is crashing almost every time at the third connection attempt.
I’m not completely sure if the changing of channels is required for this. As I said earlier it did take me more than 3 connection attempts to manifest a driver crash. At first I did what you said and changed my channel in hostapd.conf between attempts. But then, I just kept the channel the same and tried repeated connection attempts and that’s when the driver crash happened for me. Now it can still be possible that looping through channels as you did increases the chance of a crash. Hard to say though.
How can i recognize that crash?
Given the nature of this issue, probably the best that can be done at the moment is to have some kind of error detection by either parsing the logs for signs of the driver crash, or picking up on when the uap0 interface goes down. There might be a more sophisticated way to go about this, but this is just what comes to my mind at the moment.
