With the device having two partitions, keeping 19.x on one and 21.x on the other and flipping between is a pretty simple way to test things.
1 Like
OK am having horrible wifi problems on my 10 year old desktop. It does wifi via Azurewave AW-NE785H mini PCIe card. On pings to the router I get horrible packet loss, some times it can't connect at all, wpa says things like CTRL-EVENT-BEACON-LOSS CTRL-EVENT-BEACON-CHANGE init=BEACON_HINT type=UNKNOWN. The wifi was fine before updating to 21.02; and every other device can connect to 21.02 fine.
Anyone any idea of what changed with wifi that would make a 10 year old card very erratic? It was fine on 19.07 ...
what is the router? Is that the 10 year old desktop with the Azurewave AW-NE785H mini PCIe card - presumably running OpenWRT
Or is the "router" something else, that is running OpenWRT? If so, what is it? Without knowing the specifics of the router, the answer is a pineapple
Oops yes - the router is TP-Link TD-W8970 v1 running openwrt 21.02 (so an lantiq xrx200 device). As though all other machines can talk to the router fine, I'm assuming its a problem with the 10 year old desk top talking to a 21.02 router.
If I had to guess didn't 21.02 change to wolf SSL, so wondering if its something like this. I'll dig some more when I get home.
You haven't used WPA3 at all, have you?
Yes - tried it. But only arch could do it, via wpa-supplicant. So then switched back to wpa2/wpa3 joint, and now am back to just wpa2. Its a different set up between wpa2 and wpa3 on arch, so I've set the desk top back to doing just wpa2.
What about 802.11r 802.11w and KRACK - all disabled?
Have you tried another WiFi card to eliminate that possibility, or even just reseat and clean?
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.