Wifi Shell Sample Does Not Really Work For Enterprise Without Lots Of Tweaks

Introduction

In this article, we delve into a debugging journey encountered while using the Zephyr WiFi shell sample to connect to an enterprise network. The initial goal was to leverage the samples/net/wifi/shell example within the Zephyr RTOS to establish a connection to a WiFi network secured with EAP-TLS authentication. However, several challenges and quirks were discovered during the process, particularly when attempting to connect to enterprise-level networks. This article serves as a comprehensive guide, detailing the issues faced, the steps taken to diagnose them, and the solutions or workarounds found. It highlights potential bugs and areas for improvement within the Zephyr project, specifically concerning WiFi connectivity and enterprise network support. This exploration is crucial for developers and engineers aiming to implement robust and reliable WiFi solutions using Zephyr in enterprise environments.

Initial Setup and Bug Encounter

The initial setup involved utilizing the samples/net/wifi/shell example provided in the Zephyr RTOS. The testing was conducted on two different boards: esp32s3_devkitc/esp32s3/procpu and frdm-rw612. The primary objective was to connect to two distinct networks, one being an open network and the other secured with EAP-TLS. Connecting to the open network was successful without any issues. However, attempts to connect to the EAP-TLS network proved problematic, even after specifying EAP-PEAP-MSCHAPV2. This discrepancy highlighted an initial bug, suggesting that the sample might not be fully equipped to handle enterprise-level authentication methods without significant modifications.

Walkthrough of Commands and Results

To illustrate the issues encountered, the following table summarizes the commands executed and their respective outcomes:

Commands 2 and 3 consistently timed out, even with the addition of overlay configurations like overlay-enterprise-variable-bufs.conf or overlay-enterprise.conf. This suggested a deeper issue within the configuration or the underlying implementation of the WiFi connection process for enterprise networks. The timeouts indicated a failure to establish a connection, pointing towards potential problems with authentication or network negotiation.

Root Cause Analysis and Bug Identification

After extensive investigation, it was discovered that the configuration option CONFIG_WIFI_NM_WPA_SUPPLICANT_CRYPTO_ENTERPRISE=y requires CONFIG_WIFI_NM_WPA_SUPPLICANT=y to function correctly. This dependency was not immediately apparent and represented a significant bug in the sample. Without enabling CONFIG_WIFI_NM_WPA_SUPPLICANT=y, the NET_REQUEST_WIFI_ENTERPRISE_CREDS command, which is crucial for handling enterprise credentials, is not issued. This oversight prevented the system from properly negotiating the authentication process for the EAP-TLS network.

Compilation Failures and Board-Specific Issues

Adding CONFIG_WIFI_NM_WPA_SUPPLICANT=y to overlay-enterprise.conf resulted in compilation failures for both the FRDM-RW612 and ESP32S3 boards. This complication further highlighted the intricacies of configuring Zephyr for enterprise WiFi connections. For the FRDM-RW612 board, it was necessary to also disable CONFIG_NXP_WIFI_SOFTAP_SUPPORT=n to achieve successful compilation. This board-specific requirement added another layer of complexity to the configuration process. After these adjustments, commands 1 and 3 were functional on the FRDM-RW612 board, indicating progress in resolving the initial issues.

Multiple Callback Invocations

Another quirk observed on the FRDM-RW612 board was that the connection callback was invoked multiple times upon a successful connection. This resulted in the "Connected" message being printed several times, which, while not a critical error, suggested an inefficiency or potential bug in the callback mechanism. This behavior could lead to unintended side effects if the callback function performs additional actions beyond simply printing a message.

ESP32S3-Specific Challenges

For the ESP32S3 board, it was necessary to add PSRAM support, as detailed in an Espressif blog post. This requirement introduced another bug in the sample, as it was not immediately clear that PSRAM was necessary for the ESP32S3 to function correctly with the WiFi shell example. Furthermore, adding PSRAM support led to compilation errors originating from files under modules/hal/espressif/components/wpa_supplicant/src/ap/*. These errors indicated potential issues within the WPA supplicant implementation for the ESP32S3, adding another layer of complexity to the debugging process. Resolving these errors would likely require a deeper understanding of the WPA supplicant internals and the specific requirements of the ESP32S3 hardware.

Addressing the Identified Bugs

Bug 1: Dependency on CONFIG_WIFI_NM_WPA_SUPPLICANT

The first identified bug was the implicit dependency of CONFIG_WIFI_NM_WPA_SUPPLICANT_CRYPTO_ENTERPRISE=y on CONFIG_WIFI_NM_WPA_SUPPLICANT=y. To address this, it is essential to ensure that CONFIG_WIFI_NM_WPA_SUPPLICANT=y is enabled whenever enterprise-level WiFi features are required. This can be achieved by explicitly setting this configuration option in the project’s configuration files or overlay files. The absence of this configuration leads to the NET_REQUEST_WIFI_ENTERPRISE_CREDS command not being issued, effectively preventing enterprise network connections.

Solution Implementation

To resolve this, modify the overlay-enterprise.conf file to include:

CONFIG_WIFI_NM_WPA_SUPPLICANT=y

This ensures that the necessary WPA supplicant support is enabled for enterprise connections.

Bug 2: Compilation Failures and CONFIG_NXP_WIFI_SOFTAP_SUPPORT

The second bug involved compilation failures on the FRDM-RW612 board when CONFIG_WIFI_NM_WPA_SUPPLICANT=y was enabled. This issue was resolved by disabling CONFIG_NXP_WIFI_SOFTAP_SUPPORT=n. This configuration change suggests a conflict between the WPA supplicant and the soft AP support provided by NXP on this specific board. It is crucial to understand the implications of disabling soft AP support, as it may affect other functionalities that rely on this feature.

Solution Implementation

Modify the overlay-enterprise.conf file (or a board-specific overlay) to include:

CONFIG_NXP_WIFI_SOFTAP_SUPPORT=n

This adjustment allows the project to compile successfully for the FRDM-RW612 board while enabling WPA supplicant support.

Bug 3: Multiple Callback Invocations

The third potential bug was the multiple invocations of the connection callback on the FRDM-RW612 board. While this does not prevent a successful connection, it indicates a possible inefficiency or issue in the callback handling mechanism. To address this, it may be necessary to investigate the code responsible for triggering the callback and ensure that it is invoked only once per connection event. This could involve adding checks to prevent duplicate callbacks or modifying the event handling logic.

Investigation and Potential Solutions

1. Examine the WiFi driver code: Look into the driver implementation for the FRDM-RW612 to understand how connection events are handled and callbacks are triggered.
2. Implement a debounce mechanism: Introduce a flag or timer to ensure the callback is only processed once within a specific time frame.
3. Review the event handling logic: Analyze the event loop and interrupt handlers to identify any potential race conditions or duplicate event triggers.

Bug 4: ESP32S3 PSRAM Requirement and Compilation Errors

The fourth bug pertains to the ESP32S3 board, which requires PSRAM to be enabled for the WiFi shell example to function correctly. This requirement is not immediately obvious and can lead to confusion for new users. Additionally, enabling PSRAM resulted in compilation errors within the WPA supplicant components. Addressing this requires a multi-faceted approach:

Solution Implementation for PSRAM Requirement

To enable PSRAM, add the necessary configuration options to the prj.conf file or a board-specific overlay:

CONFIG_ESP32_SPIRAM=y
CONFIG_ESP32_WIFI_PSRAM=y

Addressing Compilation Errors

The compilation errors within the WPA supplicant components require a more detailed investigation. Potential causes include:

1. Incorrect memory allocation: PSRAM may not be correctly allocated or accessed by the WPA supplicant.
2. Compatibility issues: The WPA supplicant version may not be fully compatible with the ESP32S3 or the Zephyr RTOS version.
3. Configuration errors: There may be specific configuration options required for the ESP32S3 that are not enabled.

To resolve these errors, consider the following steps:

1. Review the WPA supplicant configuration: Ensure all necessary configuration options for the ESP32S3 are enabled.
2. Check memory allocation: Verify that PSRAM is correctly allocated and accessible to the WPA supplicant.
3. Update WPA supplicant: If possible, update to a more recent version of the WPA supplicant that may include bug fixes or compatibility improvements.
4. Consult ESP32S3 documentation: Refer to the Espressif documentation for any specific requirements or known issues related to WPA supplicant and PSRAM.

Experimental Status and Alternative Solutions

It's worth noting that WIFI_NM_WPA_SUPPLICANT is marked as [EXPERIMENTAL] in Zephyr, which implies that bugs and issues are expected. This status underscores the need for thorough testing and debugging when using this feature. The initial expectation was to find an alternative method for handling EAP authentication without relying on WPA supplicant, but none were readily apparent. This highlights a potential gap in Zephyr's enterprise network support, where alternative authentication mechanisms might be beneficial.

Conclusion

In conclusion, while the Zephyr WiFi shell sample provides a useful starting point for WiFi connectivity, it requires significant tweaking and debugging to function correctly in enterprise network environments. The identified bugs and quirks underscore the challenges of implementing robust enterprise-level WiFi support within an RTOS. Specifically, the implicit dependency of CONFIG_WIFI_NM_WPA_SUPPLICANT_CRYPTO_ENTERPRISE on CONFIG_WIFI_NM_WPA_SUPPLICANT, the compilation issues on FRDM-RW612, the multiple callback invocations, and the ESP32S3-specific requirements all highlight areas for improvement within the Zephyr project. Addressing these issues will enhance Zephyr's usability and reliability in enterprise settings. It is crucial for developers to be aware of these potential pitfalls and to implement the necessary workarounds or solutions. Furthermore, contributing bug reports and fixes back to the Zephyr project can help improve the overall quality and stability of the RTOS for the broader community. The experimental status of WIFI_NM_WPA_SUPPLICANT suggests ongoing development and refinement, making it essential for users to stay informed about updates and best practices.