Wow, this is already in the Linux kernel - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/net/mac80211/agg-tx.c?id=v5.10.88&id2=v5.10.87
5 Likes
I spent some time over the holidays testing a workaround for the 5GHz crashing issue that required a reboot to bring back up.
Every time that I experienced that issue, I was on channel 149 with driver default TX power of 30 dBm. That 5GHz band would always crash anywhere between 12 hours and 3 days of up time and the only fix was to reboot the router.
Channel 36 with driver default TX power of 23 dBm seems to fix the issue. I had 9 days of up time. Then I switched back to 149 briefly and it crashed as expected. I’ve been back on 36 again since then for another 7 days of up time.
I don’t understand why this is the case, but this is my experience with it. I don’t understand how one specific channel can cause a wifi band to crash. But things are so good now that I don’t want to mess with it.
WiFi is so incredibly great on my WRT3200ACM for the past 16 days when using channel 36 for 5 GHz band. 2.4 GHz has always been great.
EDIT: For the record, I should note that I have witnessed the 5 GHz band go down a few times on channel 36. However, it always came back up on its own within a minute and never required rebooting the router. Channel 149 required rebooting the router 100% of the time to bring the band back up. 149 seems to cause some sort of hard lockup of the radio.
1 Like
I don't remember what channel I was on using 21 train code, but I believe it was on 149 as well. I could sometimes just restart the radio, sometimes had to reboot.. Have been back on 19.07.8 for 5 days with no issues at all.
I actually had issues getting the wireless to work at all manually specifying the channel.
1 Like
This is great info, the past year I was unable to use 5GHz on my WRT1900AC but since yesterday this changed and I was unable to us 2.4GHz. Upgraded to 21.02.1 and now finally got both 5 and 2.4 GHz radios working again but now experiencing the occassional los of internet connection. (initially the 2.4GHz was not working but switching from channel 11 to 6 seems to have solved that)
My Wifi is loosing it's connection to internet every 50 minutes or so it seems (since I started my working day over an hour ago). are there any suggestions, apart from waiting for 21.02.02, to get rid of this flaky behaviour?
Install either master snapshot or 21.02-snapshot, which both already contain the fix.
(see the first message of the thread for links)
I don't have that issue with a recent Master snapshot as @hnyman points out. If you haven't installed one before you can grab it here:
Do a clean install. After booting, SSH into the router and install the following packages I use below which is robust and stable. Once installed you can configure it from the web interface as usual and enable any add-ons like SQM, Adblock, Samba, etc.
opkg update && opkg install luci luci-ssl irqbalance luci-app-advanced-reboot luci-app-sqm luci-app-adblock luci-app-upnp luci-app-wireguard luci-app-samba4 kmod-usb3 kmod-ata-marvell-sata kmod-usb-storage kmod-usb-storage-uas block-mount usbutils mount-utils luci-app-hd-idle kmod-fs-ext4 kmod-fs-exfat iperf3 nano
People have reported that there's some sort of read-only mode set in the 21.02 snapshots (by design?) where configurations/installs don't stick? Just FYI.
Well installed the snapshot version for my WRT1900AC, that went well. What I find rather strange is that one of my Mac books can connect to the 24GHz Wifi but has not internet connection apparently. But when I connect my phone to the same network is happily find the internet.
I decided to install the snapshot now because the Mac book was not able to find the 5GHz network at all (but according to the console it was present and working) Now hoping the WiFi is more stable than it was, but the no internet thingy does make me worry
OK, I have read up on most of this issue, which I am experiencing after upgrading to the master 21.02.1 r16325-88151b8303.
Now I want to either revert back to 19.7 or to one of the snapshots.
Though the thing that I might mistakenly think is that there is a difference between master snapshots or normal snapshots.
I have searched for differences between those and couldn't get an answer and I can only find:
https://firmware-selector.openwrt.org/?version=SNAPSHOT&target=mvebu%2Fcortexa9&id=linksys_wrt32x
And:
https://downloads.openwrt.org/snapshots/targets/mvebu/cortexa9/
Are they the same? Or have I been searching with my eyes closed?
That's very strange, I run two iPhones, two Thinkpads, and a Shield TV connected to mine all working great, on 5GHz. Maybe try restarting just the 5GHz band it doesn't seen internet on, also double check your wifi settings maybe there is a tweak. Is there a driver you can update on the Macbook? I haven't seen any wifi issues with latest snapshots.
If you get desperate consider disabling wifi on the router and buy a seperate access point, plugin to one of the ethernet ports. I know not ideal but they work. There are $100 Wifi 6 ones that work great like the U6-Lite-US.
Well for the past day I didn't have any WiFi disconnect issues, so it seems installing the SNAPSHOT version did solve the most annoying problem. And no I cannot install a new driver on that Mac.... they restricted what I can do on that Mac to the bare minimum....
I would recommend the 21.02 snapshots for stability. Those snapshots follow the 21.02 branch which is what will become the next stable build 21.02.2 and so on.
Link: https://downloads.openwrt.org/releases/21.02-SNAPSHOT/targets/mvebu/cortexa9/
The Master branch snapshots have much more frequent changes and can potentially be unstable at times. If you want bleeding edge, go for Master snapshots. If you want more stability with minimal changes, go for 21.02 snapshots until 21.02.2 comes out.
1 Like
@WildByDesign @dgilman I just updated my DFS-free build, you might give it a try: https://httpstorm.com/openwrt/WRT3200ACM/2022-01-06.r18239/
It includes a patch to the radios which disables reporting of the hard-coded region. You can set any 5 GHz channel you like. I personally set 160 MHz mode on channel 100, though my devices only support 80 MHz. Important note: if you decide to keep your configuration, particularly /etc/config/network, make sure to edit it: the WAN interface is renamed to wan, the LAN interfaces which are normally lan1-lan4 are simply lan. This is because my build reverts the DSA patch back to swconfig. If uncertain, start with a blank config or add lan to you LAN interfaces, before upgrading the firmware:
config device
option name 'br-lan'
list ports 'lan'
1 Like
@anon4457646 I recall having this conversation with @nbd, and he figured that client bridge will fail group rekey by design. The default period is 1 day. The solution is to disable group rekeying by setting Time interval for rekeying GTK: option wpa_group_rekey '0'
@cowwoc You don't need identical hardware. I've been using WRT3200 + TL-1043ND for years in WDS mode. Either side can be the AP.
1 Like
Can this patch also be used on the current stable OpenWRT FWs or snapshots? Sounds interesting to bypass the DFS check.
1 Like
@Koldur Yes, here is the patch to disable region reporting by the radios, to avoid conflict between radio2 which is hard-coded to US, and radio0-1 which are set to EU (note EU 98 is not a valid region, so the driver usually reports it as FR, can be changed in source code). When OpenWRT sees a mix of regions, it gets confused and radio0 tends to crash. It also disables all DFS channels. https://github.com/httpstorm/openwrt/commit/cff5be016b3f7b90ba632c7b733de20ed596d287
The other important patch disables DFS in reg-db for BG, DE, US, and a few other countries: https://github.com/httpstorm/openwrt/commit/76fe41829587ed5ac3b989779b2c0382b0d5860d
With these patches applied, the 5 GHz radio will happily run on any DFS channel. I get the best signal and speed on channel 100. Please ignore the reported TX power, since mwlwifi does not support getting or setting that. OpenWRT will report whatever is set in reg-db.
Note that patches usually apply to a certain range of commits. Branch gvalkov follows the master, other branches were named upon the date I created them, optimally find something close to the release date of 21.02, and try to apply the patches.
git clone https://github.com/httpstorm/openwrt
cd openwrt
git checkout gvalkov
git log
1 Like
thanks for that.
is that needed only on AP side?
Please reconsider this patch, regulatory compliance in regards to DFS is really important. A misbehaving AP not vacating DFS channels with an active (weather-) radar (the primary, licensed, user of these channels; APs are merely guests as long as the channels aren't used in your region) will be noticed by radar operators and is visible in the radar images up to 80-100 km in range, completely destroying the radar usage for its surrounding. Given that these radar installations are important for both weather services and flight safety (civilian and military) and to quite some extent maritime navigation, regulators will come down heavy handed on violations of these frequencies, with fees easily racking up into the 5-6 figure range and potential criminal repercussions as well.
If a chipset/ driver can't properly use DFS channels (vacate them immediately in the presence of a radar installation), it mustn't use these frequencies at all. Users violating these (reasonable) requirements have already caused regulatory bodies on both sides of the ocean (FCC and ETSI) to make vendors lock down their devices even further (which is making it harder and harder to provide OpenWrt on modern devices), causing quite a disservice to users of third party opensource firmware users at large.
1 Like