Skip to content

[beken-72xx] Keep 802.11n enabled at weak RSSI#392

Open
rmounce wants to merge 2 commits into
libretiny-eu:masterfrom
rmounce:fix-bk72xx-noht-rssi-threshold
Open

[beken-72xx] Keep 802.11n enabled at weak RSSI#392
rmounce wants to merge 2 commits into
libretiny-eu:masterfrom
rmounce:fix-bk72xx-noht-rssi-threshold

Conversation

@rmounce

@rmounce rmounce commented Jul 14, 2026

Copy link
Copy Markdown

Problem

BK72xx STAs frequently associate as 802.11g-only (no HT capability in the association request) even though the chip and AP both support 802.11n. Whether a given boot ends up on 11n or 11g appears random, and power-cycling does not reliably change it. The UART logs in #297 show the same signature (no ht in scan followed by a legacy association).

Root cause

Disassembly of scanu.o in librwnx_bk7231u.a (the same code is present in the bk7231n and bk7251 libs) shows:

  • scanu_frame_handler passes the RSSI of the join-scan result frame to scanu_change_ht_supported().
  • scanu_change_ht_supported() compares it against a threshold obtained from rwnx_get_noht_rssi_thresold() — a weak hook declared in beken378/ip/lmac/src/rwnx/rwnx_config.h:522 and defined nowhere — falling back to a hardcoded -50 dBm. If the scan frame is weaker, it clears me_env.ht_supported (UART log: dis ht_support), so the subsequent association request omits the HT capability IE and the STA associates as 802.11g.
  • HT is restored only at the start of the next scan (scanu_recover_ht_supported, called from scanu_start), and sm_assoc_rsp_handler separately latches an is_n_only_mode flag that suppresses the disable path — which is why the resulting mode is racy/intermittent rather than deterministic.

-50 dBm is a signal level most real-world devices don't reach, so in practice most BK72xx devices run 11g most of the time.

Fix

Define the SDK's weak threshold hook with a -100 dBm default, overridable via -DLT_BK_NOHT_RSSI_THRESHOLD (e.g. -50 to restore the vendor behavior). The blob truncates the return value to signed 8-bit, so valid values are -128..-1.

The definition lives in fixups/wlan_ui.c rather than its own file: the blob's reference to the hook is weak, and a weak reference does not extract a standalone member from the fixups archive (verified — in a separate file the object compiles but is not linked). It is itself marked __attribute__((weak)) so user code can still provide its own definition.

Verification

Tested on a BK7231T Tuya bulb (ESPHome 2026.5.3, LibreTiny 1.13.0) at -70 dBm against OpenWrt APs (MT7622, 2.4 GHz HT20):

  • Before: associated [WMM] only (hostapd station flags) after most reboots, 11g rates.
  • After: associates [WMM][HT] deterministically across reboots, MCS rates in use. DTIM WiFi power save unaffected.

🤖 Generated with Claude Code

rmounce and others added 2 commits July 14, 2026 16:00
The rwnx blob disables the STA's HT capability before association when
the join-scan result's RSSI is below a threshold defaulting to -50 dBm,
falling back to an 802.11g-only association. Define the SDK's weak
threshold hook (rwnx_get_noht_rssi_thresold) so the threshold can be
set at build time via LT_BK_NOHT_RSSI_THRESHOLD. No behavior change by
default.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
-50 dBm is a signal level most real-world devices don't reach, so in
practice the vendor default leaves most BK72xx devices on 802.11g, and
the racy HT recovery makes the resulting mode intermittent across
reboots. Default the threshold to -100 dBm so HT stays enabled at any
usable signal level.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@rmounce
rmounce force-pushed the fix-bk72xx-noht-rssi-threshold branch from d32e21f to 500b3b2 Compare July 14, 2026 06:47
@rmounce
rmounce marked this pull request as ready for review July 14, 2026 07:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant