Suggest possible change to cheapest available Intel card, if possible. Use linux or windows10 driver, not intel driver. I get my best results this way. Experts at smallnetbuilder were not able to figure my similar problem out. Bonus: intel card will not load your cpu, making laptop faster!
I have disabled 802.11r, 802.11w and KRACK.
I acutally have a spare wifi card - I try at weekend. Its not intel alas, something cheap - as a few years ago it was the only card I could get with a half height external header.
I'll dig some more in my logs to see what I can see - currently running of a very long ethernet cable ...
N.B. my desk top I set up when mini itx was getting popular, so its a very quiet mini-itx set up. AMD E350 processor, so low powered.
P.S. And just checked - current wifi card is a Qualcomm Atheros AR9285 Wireless Network Adapter - a AZureWave device - so better quality than I was expecting. The alternative is ab Edimax device ...
1 Like
Hi everyone, I just wanted to inform you that I've been using 21.02.0 on DIR-882 and everything works great (updated from some older 19.07 snapshot). Uptime is now 25 days with no issues at all. I run with PPPoE, Pi-hole, zabbix agent and bunch of devices over 2.4 and 5GHz network.
Thank you for great work!
1 Like
Can someone help?. How can i install this new firmware on a rocket m5 xw?. I cant see in the ath79 location and im still at ar71xx.
I'm getting a hickup on 5GHz WiFi during DFS radar events, device TP-Link C2600:
Fri Oct 8 12:05:44 2021 daemon.notice hostapd: wlan0: DFS-RADAR-DETECTED freq=5260 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5290 cf2=0
Fri Oct 8 12:05:44 2021 daemon.notice hostapd: dfs_downgrade_bandwidth: no DFS channels left, waiting for NOP to finish
Fri Oct 8 12:05:44 2021 daemon.notice hostapd: wlan0: AP-DISABLED
..
Fri Oct 8 12:05:44 2021 daemon.err hostapd: 20/40 MHz: center segment 0 (=58) and center freq 1 (=5270) not in sync
Fri Oct 8 12:05:44 2021 kern.warn kernel: [285195.388010] ath10k_pci 0000:01:00.0: No VIF found for vdev 1
Fri Oct 8 12:05:44 2021 kern.warn kernel: [285195.388038] ath10k_pci 0000:01:00.0: wmi-event-beacon-tx, could not find vdev for id: 1
Fri Oct 8 12:05:47 2021 kern.warn kernel: [285198.484582] ath10k_pci 0000:01:00.0: WARNING: failed to wait for beacon tx callback for vdev 1: 0
Fri Oct 8 12:05:47 2021 kern.warn kernel: [285198.484925] ath10k_pci 0000:01:00.0: peer-unmap-event: unknown peer id 1
Fri Oct 8 12:05:47 2021 kern.warn kernel: [285198.492510] ath10k_pci 0000:01:00.0: peer-unmap-event: unknown peer id 1
Fri Oct 8 12:05:47 2021 kern.warn kernel: [285198.500529] ath10k_pci 0000:01:00.0: peer-unmap-event: unknown peer id 1
Fri Oct 8 12:05:47 2021 daemon.notice netifd: Network device 'wlan0-1' link is down
..
Fri Oct 8 12:36:13 2021 daemon.notice hostapd: wlan0: interface state DFS->DFS
Fri Oct 8 12:36:13 2021 daemon.notice hostapd: wlan0: DFS-CAC-START freq=5260 chan=52 sec_chan=1, width=0, seg0=58, seg1=0, cac_time=60s
Fri Oct 8 12:36:13 2021 daemon.err hostapd: 20/40 MHz: center segment 0 (=58) and center freq 1 (=5270) not in sync
Fri Oct 8 12:36:13 2021 daemon.err hostapd: Can't set freq params
Fri Oct 8 12:36:13 2021 daemon.err hostapd: DFS start_dfs_cac() failed, -1
Fri Oct 8 12:36:13 2021 daemon.notice hostapd: wlan0: DFS-NOP-FINISHED freq=5320 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5320 cf2=0
After this the DFS scan restarts after a while and fails again, before giving up. After restarting the 5GHz device (QCA9990 802.11nac) everything works fine again.
I remember during 19.07 when radar was detected it would just fallback to a non-dfs channel. Is this a configuration issue on my end? AP is running on channel 52 (5260MHz), channel width 80MHz, 802.11ac:
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11a'
option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option country 'SI'
option htmode 'VHT80'
option txpower '20'
option cell_density '1'
option channel '52'
config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option key 'pass'
option ssid 'ssid'
option network 'lan'
option encryption 'sae-mixed'
option wpa_disable_eapol_key_retries '1'
option ieee80211w '1'
option ieee80211r '1'
option ft_over_ds '0'
option ft_psk_generate_local '1'
option ieee80211k '1'
option bss_transition '1'
Between 19.07 and 21.02 there was a change in the default behavior with regards to the channel selection on OpenWrt. If you pick a channel via the option channel but don't supply the additional option channels (which is a list of channels that the access point may use) then OpenWrt or hostapd will only use exactly this channel, even if your chosen channel is blocked due to DFS. I actually wrote a patch that reverts this change since I think it breaks DFS operation and is not expected behavior by new users, but it was rejected. The reasoning behind the original change was that a DFS event may otherwise cause the access point to switch to a channel that doesn't require DFS and then stay there until the access point is restarted (and such a channel may only allow reduced transmit power levels). In addition, if you run an outdoor access point, hostapd might switch to a channel that is not allowed for outdoor operation during a DFS event, if you haven't defined a list of channels to use.
Anyway, the solution to your issue would be to also configure the option channels and provide a list of channels you'd like to fall back to in case of a DFS event.
10 Likes
Thanks, that was an interesting read. The change in function makes sense in certain scenarios, especially the outdoor AP example you noted. Shame that nobody added this configurable option to Luci, since it seems like a required option now when using DFS channels.
I'll tweak my configs, glad to know it's not a firmware issue.
Thanks for the explanation, I guess this covers my issue as well.
Followup question: it used to be that "auto" channel meant the lowest possible channel per band. Is it still the case or may I now use it with 21.02.0 ?
Yeah, that may likely explain your issue, too.
As for your question regarding auto channel selection: I don't know. I think I've seen some talk about improving auto channel selection somewhere, but I don't know whether that actually materialized. I don't even remember where I read that (whether it was in some OpenWrt context or directly on the hostap mailing list, I have no clue). I don't use auto channel selection, but if you're interested in this, I would just give it another try to see if anything changed.
1 Like
I specify a set of acceptable channels and then set the channel to 'auto.' With 21.02.0 it no longer uses the lowest available channel. I'm not sure how it chooses a channel now, but it may use some sort of quality metric.
From what I've seen they aren't really fallback channels. I think it picks the "best" channel among the provided options based on some criteria. If the "best" channel was a DFS channel and DFS is later detected it will fall back to the next best channel. If that channel is also a DFS channel and it also detects radar on that channel during the listening period it will skip further down the list.
In practice, DFS channels seem to rank highly, probably because they are less utilized. Because of this, auto selection will tend to start with DFS channels (if configured to do so) while falling back to non-DFS channels.
How do I add additional option channels? I searched the forum but couldn't find the answer.
I am using OpenWrt 21.02.0 stable on WRT3200ACM. Everything is working fine. I just want to explore and understand how the auto channel selection works.
option channel 'auto'
option channels '52 36 132 149'
2 Likes
I'm running 21.02.0 on three routers: One Linksys ea8500 and two ea8300 "satellites". The ea8300s use one of their 5GHz radios for backhaul via WDS to the ea8500 and their other 5GHz radio to service clients. (The ea8500 also services ordinary clients on its single 5GHz radio).
Since upgrading to 21.02.0 a few weeks ago I've had an issue that packets randomly stop flowing from the satellites and their connected clients to the ea8500. This happens to both satellites about once every couple days.
After some troubleshooting I found that restarting br-lan on the satellites resolves the issue and gets packets flowing again until the next failure (Forcing reconnection of the WDS client, either by restarting the radio on the satellites or de-authenticating them from the WDS-AP, also resolves the issue). I set up a job on each of them to reboot every morning but this doesn't seem to help hold-off the problem because as often as not packets aren't flowing by the time I wake up an hour or so later.
I'm pretty sure I haven't had any real issues with the ea8500 since the upgrade. This leads me to wonder if its related to the SoC, since, as I recall, the ipq40XX used in the ea8300 has (other) issues with its switch.
Is anyone else seeing similar issues?
So I just need to edit the config/wireless file and not the hostapd, right?
Thank you @anomeome 
1 Like
My comment was in reply to a case in which a specific channel was configured, not 'auto' (or '0'). If you specify a channel to begin with, the channel list is basically a fall back option for DFS. How hostapd or the kernel determine which channel from this list is picked, I never really investigated. I'm satisfied with the observation that "it just works" (at least for me) 
But good to know auto channel selection seems to have become "smarter" or at least more dynamic these days.
1 Like
Yes, you never should or need to edit the hostapd configuration file on OpenWrt. It is automatically generated based on /etc/config/wireless whenever hostapd (re)starts.
So, you add the option to config/wireless and then restart the wifi (or the entire router).
1 Like
Hi all ,
could someone possibly tell me the current state of 21.02 for WRT1900acs devices , I Currently run an ancient build of david502c build .
last time I checked there were issues with client disconnects , is this still the case ? I'm not entirely sure what people believe the issue is , is it something to do with the wifi driver or is this 3200acm devices?
I have a very simple use case , a few port forwards , a couple dozen clients mostly 2.4GHZ, nothing overly complicated.
Ive seen a lot of posts that suggest they are using the master branch without issue is this the current best option?
thanks in advance for any info .
and thanks to the Openwrt team for working so hard to bring us updates.
I use a WRT32X so similar, I recommend just using the latest master snapshots. I found wifi to be less reliable on 21.02, everything is working well for me on master and it also has kernel 5.10, gcc 11, a ton of luci updates, etc. Performance and reliability is excellent, but there is no doubt wifi is aging. SQM cake at 500mbits, USB 3.0 externeal drive read-write at 120 MB/s, adblock, samba 4, etc.
If you much better wifi just get something like the $99 ubiquiti U6-Lite-US access point to have WiFi 6 features with target wake time (better battery life), ofdma (lower latency), mu-mimo (performance/range), wpa3, Single login for all frequencies, etc. Just turn off wifi on your OpenWrt router and plug in an AP. That's the way to go for really good WiFi because OpenWrt doesn't support some of this newer tech very well yet.
2 Likes