Mirrors
/
aredn
mirror of https://github.com/aredn/aredn.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
aredn/patches/750-ibss-2g-fix.patch

21 lines
847 B
Diff
Raw Normal View History

Fix IBSS problem on 2.4GHz (#608) There's a bug where 2.4GHz channels will associate incorrectly with other 2.4 channels even though they are on different frequencies. The problem appears to be triggered during scans when scan probes are sent and received on many different frequencies, but are then reported as as they arrive as if they come from the selected frequency of the device, causing incorrect stations to be created. This can only occur for IBSS (adhoc) mode, when the IBSS frequency is fixed, and when the SSID is also fixed. We do all this for AREDN. Fortunately these probe contains (but *only* on 2.4 GHz) the actual frequency of the sending device, so we can avoid incorrectly creating stations which are not really a match. This situation does not seem to happen on 5GHz channels. e Please enter the commit message for your changes. Lines starting
2022-12-31 20:20:37 -07:00
--- /dev/null
+++ b/package/kernel/mac80211/patches/ath/302-ibss-2g-fix.patch
@@ -0,0 +1,17 @@
+--- a/net/mac80211/ibss.c
++++ b/net/mac80211/ibss.c
+@@ -1197,6 +1197,14 @@
+ (unsigned long long)(rx_timestamp - beacon_timestamp),
+ jiffies);
+
++ if (sdata->u.ibss.fixed_channel &&
++ band == NL80211_BAND_2GHZ &&
++ elems->ds_params &&
Enable ac neg channels (#615)
2023-01-03 22:25:22 -07:00
++ sdata->u.ibss.chandef.center_freq1 != ieee80211_channel_to_frequency(elems->ds_params[0], band)) {
++ ibss_dbg(sdata, "Reject beacon: chan %d center_freq1 %d center_freq %d beacon_freq %d\n", elems->ds_params[0], sdata->u.ibss.chandef.center_freq1, channel->center_freq, ieee80211_channel_to_frequency(elems->ds_params[0], band));
Fix IBSS problem on 2.4GHz (#608) There's a bug where 2.4GHz channels will associate incorrectly with other 2.4 channels even though they are on different frequencies. The problem appears to be triggered during scans when scan probes are sent and received on many different frequencies, but are then reported as as they arrive as if they come from the selected frequency of the device, causing incorrect stations to be created. This can only occur for IBSS (adhoc) mode, when the IBSS frequency is fixed, and when the SSID is also fixed. We do all this for AREDN. Fortunately these probe contains (but *only* on 2.4 GHz) the actual frequency of the sending device, so we can avoid incorrectly creating stations which are not really a match. This situation does not seem to happen on 5GHz channels. e Please enter the commit message for your changes. Lines starting
2022-12-31 20:20:37 -07:00
++ goto put_bss;
Enable ac neg channels (#615)
2023-01-03 22:25:22 -07:00
++ }
Fix IBSS problem on 2.4GHz (#608) There's a bug where 2.4GHz channels will associate incorrectly with other 2.4 channels even though they are on different frequencies. The problem appears to be triggered during scans when scan probes are sent and received on many different frequencies, but are then reported as as they arrive as if they come from the selected frequency of the device, causing incorrect stations to be created. This can only occur for IBSS (adhoc) mode, when the IBSS frequency is fixed, and when the SSID is also fixed. We do all this for AREDN. Fortunately these probe contains (but *only* on 2.4 GHz) the actual frequency of the sending device, so we can avoid incorrectly creating stations which are not really a match. This situation does not seem to happen on 5GHz channels. e Please enter the commit message for your changes. Lines starting
2022-12-31 20:20:37 -07:00
++
+ if (beacon_timestamp > rx_timestamp) {
+ ibss_dbg(sdata,
+ "beacon TSF higher than local TSF - IBSS merge with BSSID %pM\n",