Implement the NAN Data Path encrypted datapath per Wi-Fi Aware v4.0 (§7.1.3.5, §9.5.16): - Responder + initiator sides of the M1-M4 Shared-Key Descriptor exchange, with MIC compute/verify, PTK derivation, and PMK/PMKID derivation via PBKDF2-SHA256 over passphrase or pre-shared PMK. - CSIA / SCIA attribute build + parse, NCS-SK-128 cipher suite. - Per-NDL security context on ndl_info::security_ctx; per-svc PMK cache. - ndp_response_indication callback for initiator peer-NDI binding. - host<->blob ABI migrated from 27 direct esp_nan_* externs to a single nan_secure_dp_funcs callback struct in esp_private/wifi.h. - nan_security.c split out of nan_app.c (~340 lines de-duplicated into shared M1-M4 helpers). - CONFIG_ESP_WIFI_NAN_ENCRYPTED_DATAPATH gates the secure path so non- security builds compile out the crypto/handshake code. - ROM patch (esp32s31): mask ieee80211_encap_esfbuf to match the c5/c6/c61 pattern for NAN-capable chips. Hardening: PMK stack copies zeroized on every return, NDP attribute parsers bounds-checked, CSID range-checked before shifting, NDL slot reuse only when handshake state is IDLE, get_csia/scia_len aligned with their builders on empty input. API surface: NDP security types moved out of esp_wifi_types_generic.h into esp_private/wifi.h (internal-only). security pointer dropped from struct ndp_cb_peer_info. Discovery-side wifi_nan_security_type_t and the NDP Info callbacks removed (subsumed by csid_bitmap and SSI respectively).
esp_wifi (remote)
The esp_wifi_remote component provides transparent WiFi connectivity for ESP chips through external WiFi hardware while keeping the public esp_wifi API compatible. It routes esp_wifi calls from a host device to a WiFi-capable slave via RPC, enabling WiFi on chips without native WiFi or adding a second WiFi interface alongside local esp_wifi.
Remote connectivity is provided by backend solutions such as esp_hosted, wifi_remote_over_eppp, and wifi_remote_over_at.
Directory Structure and Auto-Generation
The esp_wifi_remote component relies heavily on auto-generated code to maintain synchronization with the native esp_wifi API. The generation is handled by scripts/generate_and_check.py, which parses the original esp_wifi headers and produces the necessary remote wrappers, mocked C implementations, and Kconfig files.
Key Directories and Files
include/: Contains the generated header files defining the remote API (e.g.,esp_wifi_remote_api.h,esp_eap_client_remote_api.h).include/injected/: Contains modified copies of the native ESP-IDF headers (likeesp_wifi.h,esp_mesh.h,esp_now.h). The generator script copies these from the nativeesp_wifi/includedirectory and "injects" changes into them—specifically replacing native Kconfig macros (e.g.,CONFIG_ESP_WIFI_,CONFIG_SOC_WIFI_) with remote-specific macros (e.g.,CONFIG_WIFI_RMT_,CONFIG_SLAVE_SOC_WIFI_). This allows the remote component to reuse the native data structures while relying on different Kconfig selections corresponding to the slave device.scripts/generate_and_check.py: The core Python script responsible for generating the remote wrappers, injected headers, Kconfig mappings, and default implementations. This script is run as part of the CI pipeline (check_wif_remote_apijob) to ensure the generated files are always up-to-date with any changes to the native WiFi API.esp_wifi_remote_weak.c&esp_eap_client_remote_weak.c: Auto-generated C files containing weakly linked default implementations for the remote APIs. By default, these functions log a warning and return an unsupported error (ESP_ERR_NOT_SUPPORTED). Backend solutions (likeesp_hosted) provide the actual strong implementations for these functions to route the calls over RPC.Kconfig.*.in: Template Kconfig files used by the generator script. They bridge standard Wi-Fi configuration selections to the slave targets, enabling the host to configure the remote WiFi hardware seamlessly