BK7231X (BK7231N/CB2S): WiFi station connect always fails at WPA2 4-way handshake (reason=15), reproducible with stock example; works fine on open networks and under a different SDK on the same hardware

[MohammedAlkaylani]

Environment

• TuyaOpen version: v1.9.0 (commit 91e070c)
• Platform: BK7231X, chip BK7231N
• Module: CB2S
• Reproduced on two independent physical modules

Summary

tal_wifi_station_connect() / tkl_wifi_station_connect() consistently fails to
complete the WPA2-PSK 4-way handshake, disconnecting with reason=15
(4-Way Handshake Timeout) immediately after a successful association. This
reproduces with the completely stock, unmodified examples/wifi/sta
example — no custom code involved.

Steps to reproduce

1. Build and flash the stock examples/wifi/sta example, unmodified, with
   a real WPA2-PSK SSID/password hardcoded in.
2. Flash to a CB2S (BK7231N) board.
3. Monitor serial output.

Observed behavior

Scan succeeds, authentication succeeds, association succeeds, the AP's RSN
IE is parsed (standard WPA2-PSK/CCMP, PMF neither required nor capable —
nothing unusual). Then, consistently:

sm_deauth_handler
sm_deauth_handler reason=15,vif=0
sm_disconnect_process reason=15
...
RW_EVT_STA_CONNECT_FAILED 5
[... ty E] WiFi connect failed

This happens on every WPA2-PSK network tested (multiple SSIDs, including a
mobile hotspot at close range with an independently-verified-correct
password).

What's been ruled out

• Wrong password — verified by connecting to the same network directly
  from another device with the same credentials.
• Distance/signal strength — reproduced at close range (~1m).
• Mesh/multi-AP networks — reproduced against a plain mobile hotspot
  (single AP, no mesh).
• Power supply — reproduced on a bench supply, not just USB-UART power.
• Our own application code — reproduces identically with the
  completely stock examples/wifi/sta example.
• Hardware defect on one unit — reproduces identically on a second,
  independent physical module.
• RF calibration data (see below) — reproduces even without any OTP/
  calibration issue being the determining factor (see the open-network
  test).

What does differ

• Open (no-password) network: connects cleanly, no deauth, reaches
  WLAN_EVENT_CONNECTED and starts DHCP. Same firmware, same hardware,
  only difference is no WPA2 handshake is attempted.
• Same physical module, LibreTiny instead of TuyaOpen: connects
  successfully to the same WPA2-PSK network that fails under TuyaOpen.
  Since this proves the radio hardware itself is capable of a clean
  handshake, this points at something in TuyaOpen's BK7231N WiFi
  driver/stack rather than the module.

Possibly-related boot log warning (present on both affected modules)

No txpwr header found in flash
[NOTE]: rfcali data isn't exist
otp flash data type error 0
check rfcali data failed

Note: a separate, known-working, factory Tuya BK7231N device I found for
comparison shows only the benign "no txpwr table, using defaults" case,
without the otp flash data type error line — so this may indicate these
two modules' calibration/OTP state differs from a normal factory-
provisioned unit. However, given the LibreTiny comparison above, this
does not appear to be sufficient on its own to explain the failure, since
the open-network test succeeds despite the same warning being present.

Investigation into the actual failure point

sm_deauth_handler (which fires the observed reason=15) is declared in
platform/BK7231X/beken_os/beken378/ip/umac/src/sm/sm.h but its
implementation is compiled into the prebuilt librwnx.a (Beken's WiFi
MAC/baseband library), confirmed via tuya.map. This is a closed binary,
so I can't inspect or patch the actual handshake-timeout logic directly.

Separately, I also tried enabling LWIP_EAPOL_SUPPORT (off by default in
this build), on the theory this might be needed for EAPOL frame handling.
This causes a link failure: eapol.c calls tuya_hostap_eapol_input,
which is declared (extern) in include/lwip/ethernetif.h but has no
implementation anywhere in the source tree or in any prebuilt .a
(confirmed via nm across every archive in the repo). This may be
entirely unrelated dead code for this platform (the driver appears to run
its own internal wpa_supplicant-based handshake state machine rather than
routing EAPOL frames through lwIP), but flagging it in case it's a
genuine gap.

Version tested

Also attempted testing against v1.8.0 for regression bisection.

Question for maintainers

Is this a known issue with the BK7231X WiFi driver's WPA2 handshake
handling? Is there a way to obtain source (or at least more detailed
debug output) for the RWNX MAC layer's handshake logic, or a known
workaround/config option we're missing?

Happy to provide full boot logs, .config, or test further as needed.