Files
bes2600-dkms/bes2600
claude-noether f2cf586f89 bes2600: bus_reset on connection-loss storm to dodge assoc-comeback blackhole
When mac80211 declares connection loss against this AP (typically driven
by inactivity-deauth or beacon-loss), the userspace reauth that follows
sometimes enters a long blackhole: the AP responds to auth with success
but defers assoc with the 802.11v "assoc comeback" timer; ohm retries
faster than the comeback grants permission; the AP eventually fires an
unprotected deauth-reason-6 ("Class 2 frame received from non-
authenticated station"), and recovery only completes via cross-SSID or
cross-channel fallback. Receipts: ~86 s blackhole observed in the
phase-7 rep on 2026-05-07 02:42, with three subsequent BSSIDs returning
assoc comeback timeouts before reason-9 (STA_REQ_ASSOC_WITHOUT_AUTH)
fired. Documented in marfrit/besser:notes/phase4-2026-05-07.md.

When N=3 driver-side connection_loss decisions fire within a 60 s window
on the same vif, skip the ieee80211_connection_loss() path and trigger
the c5.2-introduced bes2600_chrdev_do_bus_reset() instead. The bus
reset removes and re-probes the chip; userspace re-associates with a
fresh chip state, dodging the AP's comeback-timer rejection cycle.

Predicted Phase 7 delta vs current baseline:
- api_connection_loss rate: unchanged (we don't address the trigger)
- conditional probability of >5 s blackhole given event: <= 30 %
- worst-case recovery: 86 s -> < 10 s

Contract pin: bes2600_chrdev_do_bus_reset(sbus_ops, sbus_priv) at
bes2600/bes_chardev.c:455, introduced by c5.2. The function is async-
returning: sbus_ops->bus_reset() schedules an SDIO rescan; the helper
waits up to 3 s for the remove() callback to clear sbus_priv, then
returns. Per-vif state is gone after this point, so the recover work
lives on bes2600_common (hw_priv) and uses the global bes2600_cdev for
the bus_reset call rather than dereferencing per-vif state.

Threshold (3 / 60 s) is well above the steady-state per-vif
connection_loss rate observed in the patch-A phase-7 rep (0.86/h under
sustained load), so a true storm is required to trip it.

Files touched:
- bes2600/bes2600.h: 3 counter fields on struct bes2600_vif, 1
  work_struct on struct bes2600_common, 3 prototypes
- bes2600/sta.c: 3 helpers + storm-account hook in
  bes2600_connection_loss_work + storm-init in bes2600_vif_setup +
  cancel_work_sync in the hw_priv shutdown path; #include bes_chardev.h
  was already pulled in by an earlier c-stack patch
- bes2600/main.c: INIT_WORK alongside other hw_priv work_structs
- bes2600/debug.c: ConnectionLossStormRecoveries seq_printf in the
  per-vif status seq_file output

The cw1200/cw1260 ancestor has no equivalent; this is a clean
addition. checkpatch.pl --no-tree --strict: clean (0/0/0).

Signed-off-by: Claude (noether) <claude@reauktion.de>
2026-05-07 12:06:46 +02:00
..
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00
2025-09-17 16:35:45 +02:00