OpenWiFi 5.1 on rxg_sdan 1.20 — retest for !5593

Lab rXg (fwd), 2026‑10‑14. Every-BSSID sweep, two-sensor client-to-client matrix, a ghost-station persistence test, and 4.2.4 on QSDK APs. Follows the Oct 5 sweep, which ran on the 1.18 alpha.

Bottom line

• sdan 1.20 is good on every AP. Each AP loaded the build for its own OpenWrt release; five replaced a running module without a reboot; nothing hung.
• North-south: 11/11 BSSIDs pass at 15/15 across 2.4, 5 and 6 GHz (Oct 5: 10/11), including a 4.2.4 EAP111 on its 23.05 build.
• 4.x is covered on QSDK too: the WF189 (ipq53xx) and WF186h (ipq50xx) swapped 1.16 → 1.20 live on 4.2.4 during the client rollout, and the WF660a and WF186h, moved back to 4.2.4, passed every BSSID and local switching (section 6).
• 1.20 local switching works: two clients on different radios of the same AP are switched on the AP (about 3,600–4,500 packets per case), with nothing sent up the tunnel.
• Cross-AP failures are not sdan. All of them involve the 186h and 188n, the only two APs sharing a 5 GHz channel (157). A client that roams between same-channel APs leaves a ghost on the old AP that never ages out; peers on the old AP's BSS can't reach the client (0/601 pings over 10 minutes). This predates 1.20 and !5593, and with the ghosts cleared after each join the pair passes in both directions. Section 5 traces why hostapd never drops them.

Versions under test

1. sdan 1.20 on each AP

Every hash matches the file the rXg serves for that build. The hot swaps used the delete_module syscall that 1.0.41 introduced. The 186h's and 189's builds were checked after the profile reflash to 5.1.0-0.006.

2. North-south: every BSSID — 11/11

Client: s1, a WF189 on 5.1.0-0.006 acting as a sensor. Every BSSID associated and leased on the first attempt, all on VLAN 301 (10.20.2.0/24). The 6 GHz client presents the MAC registered on the mPSK account, because WPA3-SAE binds the key to the station MAC.

3. Client-to-client — 16/17 on the first pass

Two sensors: A = s1 (WF189, 5.1) and B = the EAP111 (4.2.4, MediaTek). Each case places both, leases both, then in each direction sends 10 ICMP echoes, 1 MB of TCP each way, and 200 × 1200-byte UDP datagrams counted by the receiver. rxg_sdanctl counters on the AP(s) are read before and after, so a pass shows which path carried it.

• cross-band / cross-band-6 (two radios of one AP) is the case 1.20's local switching exists for: every one was switched on the AP, with no tunnel traffic.
• same-band passes but never reaches sdan: both clients share one VLAN interface, and with the runtime ap_isolate=0 mac80211 bridges them inside the BSS. sdan only switches between different wlan interfaces.
• cross-AP goes through the uplink; the one failure is section 4.

4. The cross-AP failures are ghost stations

186h ↔ 188n failed in both directions, in both orders, and with the sensors swapped; every other AP pair passed. The 186h and 188n are the only two APs whose 5 GHz radios share a channel (157). Taking one sensor off that channel mostly cleared it: 2.4 ↔ 2.4 and 186h/2.4 ↔ 188n/5 passed, while 186h/5 ↔ 188n/2.4 still failed one way.

186h ↔ 188n, both orders

186h ↔ 189, both orders

188n ↔ 660a, both orders

186h ↔ 188n, other band combinations

186h same-5 alone, after the re-run

After a failure the 188n's hostapd still listed both sensors as associated and authorized on VLAN 301 while they were on the 186h, and its sdan had learned their MACs as local. Joining on a shared channel often lands on the other AP first and then ROAMs to the target, which sends no deauth, so each join can leave a ghost behind. A re-run of the full matrix with a clean deauth after every case still scored 14/17, with every failure on the 186h's 5 GHz BSS:

Section 6's run clears each sensor's MAC from every other AP once both have joined. With that, 186h ↔ 188n passes in both directions, with one ghost cleared before each case.

5. Ghost persistence — never ages out on a shared channel

A (s1) joined the 188n on 5 GHz, then roamed with a plain reassociation to the 186h on the same channel and stayed there for 10 minutes, pinging the rXg once a second. B (EAP111) stayed on the 188n's 5 GHz BSS and pinged A once a second. Every 10 s the 188n was asked whether hostapd still listed A, how long A had been inactive, and how fresh sdan's entry for A was.

A → rXg 601/601, B → A 0/601 over the whole run. The ghost's inactive time stayed between 90 and 200 ms throughout, because the 188n's radio counts A's frames to the 186h as A's activity, so hostapd's ap_max_inactivity=300 poll never fires. sdan's entry for A on the 188n aged out at about 350 s and B → A stayed dead, so the black hole is mac80211 on the old AP delivering to the ghost, not sdan.

Impact: a client that roams between APs on the same channel can't be reached by devices on the old AP's BSS and VLAN until it changes channel or roams back — in an MDU, a phone that moved APs and a TV or printer in the same unit. Its own Internet traffic is unaffected. Nothing in the rXg or rg_wss_client drops the client from the old AP; the likely fix is the rXg sending hostapd del_client to other APs when a station associates.

Why hostapd never drops it

Upstream hostapd e17107912 (what we ship) and the QSDK 5.4 mac80211.

1. Nothing tells the old AP the client left. A roam is a reassociation to the new AP. hostapd's only cleanup for a client that moved, hostapd_prune_associations(), walks the BSSes in the same hostapd process (other radios on the same AP), never other APs. IAPP (802.11F), which made the old AP drop a roamed client, was removed in hostapd 018edec9b (2019).
2. The inactivity timer's checks both pass on a bare 802.11 ACK. ap_handle_timer() reads the kernel's inactive time: mac80211's ieee80211_sta_last_active(), the later of last_rx and last_ack. Every frame the old AP forwards to the ghost and gets ACKed resets it, so the station never looks idle. After 300 s of real idleness hostapd sends a QoS-null poll, and an ACK clears PENDING_POLL and keeps the station for another 300 s. A radio ACKs every unicast frame addressed to its MAC, whichever BSS it's associated with, so a client parked on the same channel keeps the ghost alive indefinitely.
3. The client never refuses. It drops the old AP's frames silently instead of answering with a deauth.

On a different channel the client isn't there to ACK, the poll fails, and the ghost drops after about 5 minutes. hostapd can't tell its own station from one associated to a co-channel neighbour, so the fix belongs above it: the rXg telling the old AP to del_client a station that associated elsewhere (rgnets/rxg#4495).

6. 4.2.4 on QSDK APs

Live swap during the client rollout. The WF189 and WF186h were still on 4.2.4 when the 1.0.41 client reached them, so each swapped its loaded 1.16 module for 1.20 without a reboot. The rXg's syslog has the lines; the EAP111's came from its own log.

Every new hash matches the file the rXg serves. The WF189 and WF186h stayed online on 1.20 for about 75 minutes, until the profile moved them to 5.1.

WF660a and WF186h moved back to 4.2.4. After the profile pointed them at 4.2.4-0.011 again, the WF660a loaded ipq60xx/generic 5.4.164 23.05 (31cf65c751ce) and the WF186h ipq50xx/generic 5.4.164 23.05 (4ea03ee6b30c), both matching what the rXg serves.

Cross-band on each 4.2.4 AP was switched on the AP. 660a ↔ 189 is 4.2.4 ↔ 5.1. The last case failed in the harness: sensord raised an exception before the sensor associated, so it says nothing about the AP, and same-band cases don't exercise sdan anyway.

Scope

• Only the mPSK key hbhtestkey3 (VLAN 301). No 802.1X, no wired clients, so 1.20's split horizon between wired ports is not covered.
• One sensor pair; this measures reachability and path, not capacity or roaming performance.
• The second WF-188n is offline and was not tested.

Method

Sensors run with rgminiloader stopped so the rXg cannot reconfigure them. s1's tri-band MLO radio is split into per-band radios (ath12k mlo_capable=0); the EAP111 needs no split. Each client sits in its own VRF via rg_wss_client's VrfDomain, so a reply proves the path through that association. Targets are read live from each AP's iw dev. Harness: ~/lab/sensor/sweep.py, pair.py and ghost.py driving sensord.py; raw results in runs/sweep-20261014-*, runs/pair-20261014-* and runs/ghost-20261014-061639.