<feed xmlns='http://www.w3.org/2005/Atom'>
<title>staging/xback, branch master</title>
<subtitle>Staging tree of Koen Vandeputte</subtitle>
<id>https://git-03.infra.openwrt.org/openwrt/staging/xback/atom?h=master</id>
<link rel='self' href='https://git-03.infra.openwrt.org/openwrt/staging/xback/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git-03.infra.openwrt.org/openwrt/staging/xback/'/>
<updated>2026-11-02T09:13:56Z</updated>
<entry>
<title>hostapd: enable the bgscan modules in the full wpa_supplicant config</title>
<updated>2026-11-02T09:13:56Z</updated>
<author>
<name>Koen Vandeputte</name>
</author>
<published>2026-10-31T22:58:36Z</published>
<link rel='alternate' type='text/html' href='https://git-03.infra.openwrt.org/openwrt/staging/xback/commit/?id=bfc4b8fd6c7efbdef7693df8442c7d629dbc9367'/>
<id>urn:sha1:bfc4b8fd6c7efbdef7693df8442c7d629dbc9367</id>
<content type='text'>
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 &lt;koen.vandeputte@citymesh.com&gt;
</content>
</entry>
<entry>
<title>hostapd: AP: restart the inactivity timer when a STA authenticates again</title>
<updated>2026-11-02T09:13:56Z</updated>
<author>
<name>Koen Vandeputte</name>
</author>
<published>2026-10-30T20:24:18Z</published>
<link rel='alternate' type='text/html' href='https://git-03.infra.openwrt.org/openwrt/staging/xback/commit/?id=7da11a30b8c3968db977be081d1227b352ec1822'/>
<id>urn:sha1:7da11a30b8c3968db977be081d1227b352ec1822</id>
<content type='text'>
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 &lt;koen.vandeputte@citymesh.com&gt;
</content>
</entry>
<entry>
<title>hostapd: bgscan simple: scan right away on beacon loss</title>
<updated>2026-11-02T09:13:56Z</updated>
<author>
<name>Koen Vandeputte</name>
</author>
<published>2026-10-30T20:23:42Z</published>
<link rel='alternate' type='text/html' href='https://git-03.infra.openwrt.org/openwrt/staging/xback/commit/?id=d31cb17d31416ad12a0c1e920465581e5d569076'/>
<id>urn:sha1:d31cb17d31416ad12a0c1e920465581e5d569076</id>
<content type='text'>
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 &lt;koen.vandeputte@citymesh.com&gt;
</content>
</entry>
<entry>
<title>hostapd: backport FT and nl80211 robustness fixes</title>
<updated>2026-11-02T09:13:56Z</updated>
<author>
<name>Koen Vandeputte</name>
</author>
<published>2026-10-30T16:36:22Z</published>
<link rel='alternate' type='text/html' href='https://git-03.infra.openwrt.org/openwrt/staging/xback/commit/?id=b2867f06d7bb68cfb9998eabf904a183506d69f6'/>
<id>urn:sha1:b2867f06d7bb68cfb9998eabf904a183506d69f6</id>
<content type='text'>
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 &lt;koen.vandeputte@citymesh.com&gt;
</content>
</entry>
<entry>
<title>hostapd: wpa_supplicant: request a scan when a timed out attempt holds the state</title>
<updated>2026-11-02T09:13:56Z</updated>
<author>
<name>Koen Vandeputte</name>
</author>
<published>2026-10-30T16:28:34Z</published>
<link rel='alternate' type='text/html' href='https://git-03.infra.openwrt.org/openwrt/staging/xback/commit/?id=a998a3970f8092f83efb50cfef64a9244c922fbf'/>
<id>urn:sha1:a998a3970f8092f83efb50cfef64a9244c922fbf</id>
<content type='text'>
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 &lt;koen.vandeputte@citymesh.com&gt;
</content>
</entry>
<entry>
<title>hostapd: sync config files with upstream</title>
<updated>2026-11-02T09:13:56Z</updated>
<author>
<name>Koen Vandeputte</name>
</author>
<published>2026-11-02T08:53:59Z</published>
<link rel='alternate' type='text/html' href='https://git-03.infra.openwrt.org/openwrt/staging/xback/commit/?id=a909670e1a1908fcac55da371e05d3cd8cf34999'/>
<id>urn:sha1:a909670e1a1908fcac55da371e05d3cd8cf34999</id>
<content type='text'>
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 &lt;koen.vandeputte@citymesh.com&gt;
</content>
</entry>
<entry>
<title>mac80211: follow a sender whose sequence numbers went back</title>
<updated>2026-11-02T09:13:56Z</updated>
<author>
<name>Koen Vandeputte</name>
</author>
<published>2026-10-26T21:17:09Z</published>
<link rel='alternate' type='text/html' href='https://git-03.infra.openwrt.org/openwrt/staging/xback/commit/?id=8154ee7f3d401fd27fad557f8bce37aa81c399ce'/>
<id>urn:sha1:8154ee7f3d401fd27fad557f8bce37aa81c399ce</id>
<content type='text'>
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 &lt;koen.vandeputte@citymesh.com&gt;
</content>
</entry>
<entry>
<title>ath10k-ct: reset a tx block-ack session the peer no longer accepts</title>
<updated>2026-11-02T09:13:56Z</updated>
<author>
<name>Koen Vandeputte</name>
</author>
<published>2026-10-26T21:17:09Z</published>
<link rel='alternate' type='text/html' href='https://git-03.infra.openwrt.org/openwrt/staging/xback/commit/?id=2a9fa5ee3506aa7b8fdd41baa7a00fd1454a28d2'/>
<id>urn:sha1:2a9fa5ee3506aa7b8fdd41baa7a00fd1454a28d2</id>
<content type='text'>
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 &lt;koen.vandeputte@citymesh.com&gt;
</content>
</entry>
<entry>
<title>ath10k-ct: fix the record count of the tx mode switch indication</title>
<updated>2026-11-02T09:13:56Z</updated>
<author>
<name>Koen Vandeputte</name>
</author>
<published>2026-10-23T15:01:06Z</published>
<link rel='alternate' type='text/html' href='https://git-03.infra.openwrt.org/openwrt/staging/xback/commit/?id=67d8b7dc1aba0660a1657c520f2ac665baf6ac80'/>
<id>urn:sha1:67d8b7dc1aba0660a1657c520f2ac665baf6ac80</id>
<content type='text'>
The tx mode switch handler reads the number of records from info0 with
the mask and shift of the threshold field of info1, so about half of
the records are skipped. A peer whose record is skipped keeps a push
allowance of zero in push-pull mode.

On QCA4019 radios in a mesh under load, this stopped all transmission
to some stations while the others kept working, until the station was
removed.

Assisted-by: Claude Opus 5.5
Signed-off-by: Koen Vandeputte &lt;koen.vandeputte@citymesh.com&gt;
</content>
</entry>
<entry>
<title>imx: dts: Ventana: add the NAND controller cell sizes</title>
<updated>2026-11-02T09:13:56Z</updated>
<author>
<name>Koen Vandeputte</name>
</author>
<published>2026-10-22T14:01:56Z</published>
<link rel='alternate' type='text/html' href='https://git-03.infra.openwrt.org/openwrt/staging/xback/commit/?id=71462b32b92bc7379f6d280fc46ba21adcc75ec3'/>
<id>urn:sha1:71462b32b92bc7379f6d280fc46ba21adcc75ec3</id>
<content type='text'>
The Gateworks Ventana boot loader adds the NAND partitions to the device
tree as partition@ nodes directly below the gpmi NAND controller, but
the controller node has no #address-cells and #size-cells. Parsing the
partitions then triggers two warnings with a backtrace at every boot:

  Missing '#address-cells' in /soc/nand-controller@112000
  WARNING: CPU: 3 PID: 1 at drivers/of/base.c:115 of_bus_n_addr_cells+0xac/0xc8
  Missing '#size-cells' in /soc/nand-controller@112000
  WARNING: CPU: 3 PID: 1 at drivers/of/base.c:142 of_bus_n_size_cells+0xac/0xc8

Add a patch giving the gpmi node of every Ventana board the one-cell
address and size the partitions use.

Tested on a Gateworks GW-5400 Ventana with the patched device tree: no
warnings, the uboot, env and ubi partitions are found as before.

Assisted-by: Claude Opus 5.5
Signed-off-by: Koen Vandeputte &lt;koen.vandeputte@citymesh.com&gt;
</content>
</entry>
</feed>
