staging/xback/package, branch master

ustream-ssl: build after mbedtls when only uclient needs it

2026-11-04T13:09:16Z

uclient build-depends on ustream-ssl. With none of the libustream packages selected, ustream-ssl is built for uclient alone, as its default variant, mbedtls. The dependency of that variant on mbedtls only applies when libustream-mbedtls is selected, so nothing orders the two: when ustream-ssl configures before mbedtls is installed, CMake fails with mbedtls_library, mbedx509_library and mbedcrypto_library set to NOTFOUND. Builds of several trees on one jobserver hit this. Build after mbedtls unless an openssl or wolfssl variant is selected. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

gdb: build only gdbserver when gdb is not selected

2026-11-04T11:22:42Z

Selecting gdbserver alone builds all of gdb, and the build dependencies of the gdb package pull in gmp, mpfr, ncurses, readline and zlib, while gdbserver uses none of them. On ath79 that took 1245 s of CPU and 249 s on 8 threads, most of it in a serial chain that tends to end the build. Make the libraries of gdb depend on its own selection, so that they are no longer build dependencies of gdbserver, and configure without gdb, bfd, opcodes, libctf, libsframe, libbacktrace and libdecnumber when gdb is not selected. gdbserver then builds from gdbsupport, gnulib and libiberty alone: 132 s of CPU and 39 s. The binary and the runtime dependencies of both packages stay the same, and selecting gdb as well reconfigures for the full build. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

hostapd: enable the bgscan modules in the full wpa_supplicant config

2026-11-02T09:13:56Z

The full config, which the full and mesh wpa_supplicant variants are built with, leaves CONFIG_BGSCAN_SIMPLE and CONFIG_BGSCAN_LEARN off. A bgscan parameter in a network block is then accepted but does nothing: the station never scans in the background, and moves to another AP of its network only after it lost the current one. Seen on stations with bgscan="simple:30:-75:300:...": three hours of wpa_supplicant debug output without a single background scan, on test boards and on stations in the field alike (no bgscan code in the binary). An rb922 station (QCA988X, 10.1-ct firmware) that went an hour with heavy traffic and no scan also got into a state where its firmware no longer left the channel for a scan; with a scan every 10 minutes it ran 100 minutes of the same traffic without that. Enable both modules (bgscan learn is what a "learn" bgscan parameter asks for). They add 8 kB to the wpa_supplicant binary (mips_24kc). Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

hostapd: AP: restart the inactivity timer when a STA authenticates again

2026-11-02T09:13:56Z

A STA that roams to another AP with FT does not tell the AP it leaves, so that AP times it out: it disassociates the STA after a failed poll and deauthenticates and removes it AP_DEAUTH_DELAY (1 s) later. When the STA comes back in that second, its Authentication frame is accepted, but nothing stops the timer: it removes the STA before the Reassociation Request frame arrives, which is then rejected as a Class 2 frame from a STA that is not authenticated. The STA has to start over without FT, which takes 1-2 s instead of tens of milliseconds. Restart the timer as for a new STA when an existing STA authenticates. Seen on two rb922 roaming APs (ap_max_inactivity=30) with a station roaming between them every 46 s: 1 of 90 roams took 1.7 s, with "deauthenticated due to inactivity (timer DEAUTH/REMOVE)" between the FT authentication and "Station tried to associate before authentication". A new hwsim test that holds the Reassociation Request frame until the timer has expired fails without this patch in every run that gets that timing, and passes with it; the ap_ft module shows no change. The bug is still in upstream hostap (checked on 2026-10-30). Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

hostapd: bgscan simple: scan right away on beacon loss

2026-11-02T09:13:56Z

bgscan simple only logs a beacon loss report. A station whose AP goes out of range, or stops sending beacons, looks for another AP only at its next scan interval, which can be minutes away when the signal was above the threshold until then. Meanwhile it stays with an AP it does not hear, as long as that AP still acknowledges the frames the kernel sends to probe it. Scan right away on beacon loss, like on a further signal drop, unless the last background scan was less than 10 seconds ago. An AP that is not seen in that scan makes wpa_supplicant move to another AP of the network. Seen on field stations with bgscan simple:30:-75:300: up to 22 beacon loss reports in 15 hours, most of them without a disconnection, and no scan for minutes after them. The hwsim bgscan tests pass, and the full hwsim run shows no change against the unpatched package. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

hostapd: backport FT and nl80211 robustness fixes

2026-11-02T09:13:56Z

Backport from upstream hostap, all after the 2026-08-07 snapshot: fcae90b60 FT: Fix off-by-2 buffer bounds check in wpa_ft_process_rdie() f6e620ec6 FT: Ignore request requests without any resource descriptors ebe890e18 FT: Do not allow RIC related items to consume all available room 6daa7ff84 Check buffer room when writing Timeout Interval element 396a62817 FT: Ignore request descriptors with invalid or incomplete element(s) 741d70dd8 FT: Do not process RIC-Request in initial MD association 8a2611102 nl80211: Verify frame length before reading auth_alg The FT fixes bound what a station can make an AP write into its (Re)Association Response; roaming APs here run 802.11r FT-PSK. 6daa7ff84 uses buf + buflen in send_assoc_resp(): the end pointer of upstream 0eb84a59d is not in this snapshot. Built for ath79 (all hostapd variants of the tree); the patches apply on top of the full patch set. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

hostapd: wpa_supplicant: request a scan when a timed out attempt holds the state

2026-11-02T09:13:56Z

Since upstream commit bbcc1adbc ("Try the next AP from scan results if connection attempt fails"), wpas_connection_failed() returns without requesting a scan when fast associate selects a BSS from the last scan results. After an SME authentication or association timeout, the failed attempt still holds the state at that point: selecting the same BSS again starts nothing, yet no scan is requested. The station then stays DISCONNECTED until something else triggers a scan, also with other APs of its network in range. Seen on an rb922 station whose AP restarted during authentication: it stayed disconnected for minutes next to two APs of its network. With this patch it reconnected 11 s after the APs answered again (10 s ignore list, then a scan), in each of the repeated tests. The bug is still in upstream hostap (checked on 2026-10-30). Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

hostapd: sync config files with upstream

2026-11-02T09:13:56Z

Sync the config files with the defconfig files of hostap 831364bf (2.12), the version the package builds. Each file is now the upstream defconfig with the OpenWrt settings, plus the OpenWrt-only uBus and CTRL_IFACE_MIB options at the end. The upstream defconfig now enables CONFIG_DPP2, CONFIG_OWE, CONFIG_IEEE80211BE and CONFIG_IPV6 and disables CONFIG_WNM. The files keep their current values, so no option changes state. CONFIG_DRIVER_HOSTAP, which was disabled, is gone with the driver. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

mac80211: follow a sender whose sequence numbers went back

2026-11-02T09:13:56Z

With firmware that runs the block-ack sessions itself (ath10k), a sender can keep sending frames behind the receiver's reorder window without a new session. They are acknowledged over the air and then dropped by mac80211 as out of date, without being counted, until the sequence numbers catch up: up to 2048 frames. Traffic waiting for answers never gets there, so the link stays dead. Seen between QCA988X and QCA4019 radios in an IBSS mesh under load, with runs of frames 7-23 sequence numbers behind the window. After 64 frames in a row behind the window, restart it at the incoming frame (module parameter reorder_resync, 0 keeps the old behaviour and only logs). Replays are still caught by the PN check. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

ath10k-ct: reset a tx block-ack session the peer no longer accepts

2026-11-02T09:13:56Z

The firmware runs the tx block-ack sessions itself. Under channel contention, the session to a peer can get out of sync with the receiver: every A-MPDU to that peer fails, while beacons, broadcasts and the other peers keep working, and nothing recovers it. On a QCA4019 mesh with two loaded links sharing the channel, the link died within 15-170 s and never came back. A delba made the firmware set up a new session, and traffic recovered at once. An AP with WDS stations shows the same: one station suddenly gets nothing any more, while the others keep working. There every broadcast of the bridge goes out as a unicast A-MPDU to each station. After 30 unicast tx failures in a row to a peer of an IBSS, mesh, AP or station interface (an AP's WDS stations included), send a delba for that TID, at most once per peer every 5 s (module parameter ba_reset_fails, 0 turns it off). Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte