From 43c8f0cba8fc007f22725a483204d4b4ad81c58e Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Mon, 18 May 2026 15:57:20 +0200 Subject: [PATCH] =?UTF-8?q?patches/driver/bes2600:=20scan-filter-5ghz=20re?= =?UTF-8?q?finement=20=E2=80=94=20allow=20targeted=20single-channel=20scan?= =?UTF-8?q?s?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Updates both flavors with the n_channels > 1 refinement (was > 0). The original guard refused ALL 5 GHz scans which broke 5 GHz association via NM band=a profiles (NM iterates freq_list per channel, single-channel scans were also refused). Tightened: only multi-channel 5 GHz scans (the per-band-sweep that triggers the firmware storm) are refused; single-channel 5 GHz scans pass through so NM/wpa_supplicant can find and associate to 5 GHz BSSes. Verified on ohm with locally-built pkgrel=3 (srcversion BEB625FA7443171EA8D55F7): associated to 5 GHz BSSID c0:25:06:e6:5b:33 on 5240 MHz / ch.48, 150 Mbit/s MCS 7 40MHz short-GI; Pattern A still 0 since boot. Patch file is now a concatenation of two commits from marfrit/bes2600-dkms bes2600/scan-filter-5ghz branch: 093a503 (original Patch I) 8cd10f4 (this refinement) patch -Np1 applies them sequentially -> net effect = single squash. Refs: besser#1 (closed), PKGBUILD update at marfrit/besser claude-noether-14 commit 122582e (pkgrel=3 deployed to ohm on 2026-05-18 same session). --- ...r-5-GHz-scans-at-the-driver-boundary.patch | 79 ++++++++++++++++++- ...r-5-GHz-scans-at-the-driver-boundary.patch | 79 ++++++++++++++++++- 2 files changed, 156 insertions(+), 2 deletions(-) diff --git a/patches/driver/bes2600/scan-filter-5ghz-danctnix/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch b/patches/driver/bes2600/scan-filter-5ghz-danctnix/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch index 4447378..76df117 100644 --- a/patches/driver/bes2600/scan-filter-5ghz-danctnix/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch +++ b/patches/driver/bes2600/scan-filter-5ghz-danctnix/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch @@ -1,7 +1,8 @@ From 093a5038b8b68f316d976b7cb69609ca7f24f322 Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Mon, 18 May 2026 11:27:40 +0200 -Subject: [PATCH] bes2600: filter 5 GHz scans at the driver boundary (besser#1) +Subject: [PATCH 1/2] bes2600: filter 5 GHz scans at the driver boundary + (besser#1) The BES2600 firmware refuses WSM start-scan for 5 GHz with status 2 ("rejected by policy"). This shows up in dmesg as the recurring @@ -89,3 +90,79 @@ index fb1d298..a81afb6 100644 -- 2.54.0 + +From 8cd10f487c8144d462a510812ba0fa717b3e24df Mon Sep 17 00:00:00 2001 +From: Markus Fritsche +Date: Mon, 18 May 2026 15:56:34 +0200 +Subject: [PATCH 2/2] bes2600: scan-filter-5ghz: allow targeted single-channel + scans (besser#1 follow-up) + +The original Patch I refused EVERY 5 GHz scan request unconditionally +(req->n_channels > 0 && band == NL80211_BAND_5GHZ). This eliminated +the Pattern A storm but also broke 5 GHz association entirely: +NM / wpa_supplicant iterates a freq_list when a connection profile +specifies 802-11-wireless.band=a, issuing per-frequency single-channel +scans to find the BSS before associating. Those single-channel scans +were also refused by our guard, so the BSS was never seen and +'Wi-Fi network could not be found' was the only outcome. + +Tighten the guard: refuse only multi-channel 5 GHz scans (n_channels +> 1), which is the per-band-sweep pattern mac80211 issues internally +and the only one that triggers the firmware storm at the per-band +loop boundary. Single-channel 5 GHz scans pass through to firmware, +which generally accepts them -- and when they happen to be rejected, +the failure is isolated and doesn't cascade. + +Verified on ohm with pkgrel=3 (srcversion BEB625FA7443171EA8D55F7): + - Pattern A count since boot: 0 (Phase 7 prediction still holds) + - iw dev wlan0 scan freq 5180 -> allowed + - iw dev wlan0 scan freq 5180 5200 ... -> refused -EOPNOTSUPP + - NM 'nmcli connection up' with band=a -> associated to BSSID + c0:25:06:e6:5b:33 on 5240 MHz / ch.48 in ~1 second + - TX bitrate 150 Mbit/s MCS 7 40MHz short-GI (vs 72.2 Mbit/s + HT20 on 2.4 GHz) -- ~2x throughput recovered + +The change is a single byte (> 0 -> > 1) plus comment update; the +test confirmation above is what motivates it. + +Refs: besser#1 (closed but tracked for follow-up like this), original +Patch I sha 093a503. +--- + bes2600/scan.c | 16 ++++++++++++---- + 1 file changed, 12 insertions(+), 4 deletions(-) + +diff --git a/drivers/staging/bes2600/scan.c b/drivers/staging/bes2600/scan.c +index a81afb6..497523b 100644 +--- a/drivers/staging/bes2600/scan.c ++++ b/drivers/staging/bes2600/scan.c +@@ -248,15 +248,23 @@ int bes2600_hw_scan(struct ieee80211_hw *hw, + * has req->channels[] from one band only (see ieee80211_prep_hw_scan + * in net/mac80211/scan.c). Refuse the 5 GHz iteration at the driver + * boundary so userspace gets a clean aborted-scan for that portion +- * rather than waiting for the firmware reject to cascade up. 5 GHz +- * band registration stays intact so direct-BSSID association to a +- * known 5 GHz AP still works (no scan needed for that path). ++ * rather than waiting for the firmware reject to cascade up. ++ * ++ * Only the multi-channel case is refused (n_channels > 1): that's ++ * the per-band-sweep pattern mac80211 issues internally and the ++ * one that triggers the firmware storm at the per-band loop ++ * boundary. Single-channel 5 GHz scans (BSS verification, NM's ++ * per-freq iteration when 802-11-wireless.band=a is set) pass ++ * through to firmware, which generally accepts them since the ++ * storm is the back-to-back per-band issue, not a blanket 5 GHz ++ * reject. This preserves 5 GHz association via the ++ * "wpa_supplicant iterates freq_list per channel" path. + * + * Contract: per include/net/mac80211.h struct ieee80211_ops.hw_scan + * documentation, a negative return aborts the scan without requiring + * ieee80211_scan_completed(). + */ +- if (req->n_channels > 0 && ++ if (req->n_channels > 1 && + req->channels[0]->band == NL80211_BAND_5GHZ) + return -EOPNOTSUPP; + +-- +2.54.0 + diff --git a/patches/driver/bes2600/scan-filter-5ghz/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch b/patches/driver/bes2600/scan-filter-5ghz/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch index 4447378..76df117 100644 --- a/patches/driver/bes2600/scan-filter-5ghz/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch +++ b/patches/driver/bes2600/scan-filter-5ghz/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch @@ -1,7 +1,8 @@ From 093a5038b8b68f316d976b7cb69609ca7f24f322 Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Mon, 18 May 2026 11:27:40 +0200 -Subject: [PATCH] bes2600: filter 5 GHz scans at the driver boundary (besser#1) +Subject: [PATCH 1/2] bes2600: filter 5 GHz scans at the driver boundary + (besser#1) The BES2600 firmware refuses WSM start-scan for 5 GHz with status 2 ("rejected by policy"). This shows up in dmesg as the recurring @@ -89,3 +90,79 @@ index fb1d298..a81afb6 100644 -- 2.54.0 + +From 8cd10f487c8144d462a510812ba0fa717b3e24df Mon Sep 17 00:00:00 2001 +From: Markus Fritsche +Date: Mon, 18 May 2026 15:56:34 +0200 +Subject: [PATCH 2/2] bes2600: scan-filter-5ghz: allow targeted single-channel + scans (besser#1 follow-up) + +The original Patch I refused EVERY 5 GHz scan request unconditionally +(req->n_channels > 0 && band == NL80211_BAND_5GHZ). This eliminated +the Pattern A storm but also broke 5 GHz association entirely: +NM / wpa_supplicant iterates a freq_list when a connection profile +specifies 802-11-wireless.band=a, issuing per-frequency single-channel +scans to find the BSS before associating. Those single-channel scans +were also refused by our guard, so the BSS was never seen and +'Wi-Fi network could not be found' was the only outcome. + +Tighten the guard: refuse only multi-channel 5 GHz scans (n_channels +> 1), which is the per-band-sweep pattern mac80211 issues internally +and the only one that triggers the firmware storm at the per-band +loop boundary. Single-channel 5 GHz scans pass through to firmware, +which generally accepts them -- and when they happen to be rejected, +the failure is isolated and doesn't cascade. + +Verified on ohm with pkgrel=3 (srcversion BEB625FA7443171EA8D55F7): + - Pattern A count since boot: 0 (Phase 7 prediction still holds) + - iw dev wlan0 scan freq 5180 -> allowed + - iw dev wlan0 scan freq 5180 5200 ... -> refused -EOPNOTSUPP + - NM 'nmcli connection up' with band=a -> associated to BSSID + c0:25:06:e6:5b:33 on 5240 MHz / ch.48 in ~1 second + - TX bitrate 150 Mbit/s MCS 7 40MHz short-GI (vs 72.2 Mbit/s + HT20 on 2.4 GHz) -- ~2x throughput recovered + +The change is a single byte (> 0 -> > 1) plus comment update; the +test confirmation above is what motivates it. + +Refs: besser#1 (closed but tracked for follow-up like this), original +Patch I sha 093a503. +--- + bes2600/scan.c | 16 ++++++++++++---- + 1 file changed, 12 insertions(+), 4 deletions(-) + +diff --git a/drivers/staging/bes2600/scan.c b/drivers/staging/bes2600/scan.c +index a81afb6..497523b 100644 +--- a/drivers/staging/bes2600/scan.c ++++ b/drivers/staging/bes2600/scan.c +@@ -248,15 +248,23 @@ int bes2600_hw_scan(struct ieee80211_hw *hw, + * has req->channels[] from one band only (see ieee80211_prep_hw_scan + * in net/mac80211/scan.c). Refuse the 5 GHz iteration at the driver + * boundary so userspace gets a clean aborted-scan for that portion +- * rather than waiting for the firmware reject to cascade up. 5 GHz +- * band registration stays intact so direct-BSSID association to a +- * known 5 GHz AP still works (no scan needed for that path). ++ * rather than waiting for the firmware reject to cascade up. ++ * ++ * Only the multi-channel case is refused (n_channels > 1): that's ++ * the per-band-sweep pattern mac80211 issues internally and the ++ * one that triggers the firmware storm at the per-band loop ++ * boundary. Single-channel 5 GHz scans (BSS verification, NM's ++ * per-freq iteration when 802-11-wireless.band=a is set) pass ++ * through to firmware, which generally accepts them since the ++ * storm is the back-to-back per-band issue, not a blanket 5 GHz ++ * reject. This preserves 5 GHz association via the ++ * "wpa_supplicant iterates freq_list per channel" path. + * + * Contract: per include/net/mac80211.h struct ieee80211_ops.hw_scan + * documentation, a negative return aborts the scan without requiring + * ieee80211_scan_completed(). + */ +- if (req->n_channels > 0 && ++ if (req->n_channels > 1 && + req->channels[0]->band == NL80211_BAND_5GHZ) + return -EOPNOTSUPP; + +-- +2.54.0 +