even with WED disabled I had a mobile phone in my WiFi which got dropped out of WiFi for a minute or two.
Connectivity got re-established with no manual interaction.
I have grepped logread on one of the interesting MAC addresses:
Sun Oct 8 18:46:26 2023 daemon.info dawn: Client 8C:XX:XX:XX:XX17: Kicking due to low active data transfer: RX rate 2.000000 below 6 limit
Sun Oct 8 18:46:27 2023 daemon.notice hostapd: wl0-ap1: AP-STA-DISCONNECTED 8c:xx:xx:xx:xx:17
Sun Oct 8 18:46:27 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: disassociated due to inactivity
Sun Oct 8 18:46:28 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Oct 8 18:46:29 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: authenticated
Sun Oct 8 18:46:29 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: associated (aid 1)
Sun Oct 8 18:46:29 2023 daemon.notice hostapd: wl0-ap1: AP-STA-CONNECTED 8c:xx:xx:xx:xx:17 auth_alg=open
Sun Oct 8 18:46:29 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 RADIUS: starting accounting session 28021A0C52F7A5B0
Sun Oct 8 18:46:29 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 WPA: pairwise key handshake completed (RSN)
Sun Oct 8 18:46:29 2023 daemon.notice hostapd: wl0-ap1: EAPOL-4WAY-HS-COMPLETED 8c:xx:xx:xx:xx:17
Sun Oct 8 18:46:57 2023 daemon.info dawn: Client 8C:XX:XX:XX:XX:17: Kicking due to low active data transfer: RX rate 2.000000 below 6 limit
Sun Oct 8 18:46:58 2023 daemon.notice hostapd: wl0-ap1: AP-STA-DISCONNECTED 8c:xx:xx:xx:xx:17
Sun Oct 8 18:46:58 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: disassociated due to inactivity
Sun Oct 8 18:46:59 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Oct 8 18:46:59 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: authenticated
Sun Oct 8 18:46:59 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: associated (aid 1)
Sun Oct 8 18:46:59 2023 daemon.notice hostapd: wl0-ap1: AP-STA-CONNECTED 8c:xx:xx:xx:xx:17 auth_alg=open
Sun Oct 8 18:46:59 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 RADIUS: starting accounting session 3FA54E91EA1445BD
Sun Oct 8 18:46:59 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 WPA: pairwise key handshake completed (RSN)
Sun Oct 8 18:46:59 2023 daemon.notice hostapd: wl0-ap1: EAPOL-4WAY-HS-COMPLETED 8c:xx:xx:xx:xx:17
Sun Oct 8 18:47:28 2023 daemon.info dawn: Client 8C:XX:XX:XX:XX:17: Kicking due to low active data transfer: RX rate 2.000000 below 6 limit
Sun Oct 8 18:47:29 2023 daemon.notice hostapd: wl0-ap1: AP-STA-DISCONNECTED 8c:xx:xx:xx:xx:17
Sun Oct 8 18:47:29 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: disassociated due to inactivity
Sun Oct 8 18:47:30 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Oct 8 18:47:30 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: authenticated
Sun Oct 8 18:47:30 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: associated (aid 1)
Sun Oct 8 18:47:30 2023 daemon.notice hostapd: wl0-ap1: AP-STA-CONNECTED 8c:xx:xx:xx:xx:17 auth_alg=open
Sun Oct 8 18:47:30 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 RADIUS: starting accounting session EB200FAA26A6B02B
Sun Oct 8 18:47:30 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 WPA: pairwise key handshake completed (RSN)
Sun Oct 8 18:47:30 2023 daemon.notice hostapd: wl0-ap1: EAPOL-4WAY-HS-COMPLETED 8c:xx:xx:xx:xx:17
Sun Oct 8 18:47:30 2023 daemon.notice hostapd: wl0-ap1: AP-STA-DISCONNECTED 8c:xx:xx:xx:xx:17
Sun Oct 8 18:47:31 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: disassociated
Sun Oct 8 18:47:32 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Oct 8 18:47:32 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: authenticated
Sun Oct 8 18:47:32 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: associated (aid 1)
Sun Oct 8 18:47:32 2023 daemon.notice hostapd: wl0-ap1: AP-STA-CONNECTED 8c:xx:xx:xx:xx:17 auth_alg=open
Sun Oct 8 18:47:32 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 RADIUS: starting accounting session BB6347E327BD966C
Sun Oct 8 18:47:32 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 WPA: pairwise key handshake completed (RSN)
Sun Oct 8 18:47:32 2023 daemon.notice hostapd: wl0-ap1: EAPOL-4WAY-HS-COMPLETED 8c:xx:xx:xx:xx:17
Sun Oct 8 18:47:58 2023 daemon.info dawn: Client 8C:XX:XX:XX:XX:17: Kicking due to low active data transfer: RX rate 2.000000 below 6 limit
Sun Oct 8 18:47:59 2023 daemon.notice hostapd: wl0-ap1: AP-STA-DISCONNECTED 8c:xx:xx:xx:xx:17
Sun Oct 8 18:47:59 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: disassociated due to inactivity
Sun Oct 8 18:48:00 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Oct 8 18:48:00 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: authenticated
Sun Oct 8 18:48:00 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 IEEE 802.11: associated (aid 1)
Sun Oct 8 18:48:00 2023 daemon.notice hostapd: wl0-ap1: AP-STA-CONNECTED 8c:xx:xx:xx:xx:17 auth_alg=open
Sun Oct 8 18:48:00 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 RADIUS: starting accounting session B4354EF255B4A2D2
Sun Oct 8 18:48:00 2023 daemon.info hostapd: wl0-ap1: STA 8c:xx:xx:xx:xx:17 WPA: pairwise key handshake completed (RSN)
Sun Oct 8 18:48:00 2023 daemon.notice hostapd: wl0-ap1: EAPOL-4WAY-HS-COMPLETED 8c:xx:xx:xx:xx:17
This could be related to DAWN.
Obviously it is not clear to me which component is responsible. @PolynomialDivision this is off of a checkout from 2023-09-30: OpennWrt SNAPSHOT r24056-86dadeba48 / LuCI Master git-23.272.64820-607e9bb
Would you mind publishing your configs, incl. the wireless config? I'm having some trouble with both usteer and DAWN and want to see if something is misconfigured on my end.
Specifically I have some trouble with my HomePods continuously disconnecting on a 6 minute cycle (even during use connected to my Apple TV). In fact both usteer and DAWN seems to be kicking off every device from the network on that 6 minute interval...
I've had severe stability problems with SNAPSHOT build over last couple of months. Every four days or so device was becoming completely unresponsive and required physical restart to get it up and running again.
I tried different radio firmwares and so, but it didn't make any difference regarding this particular problem.
In effort to stay updated I flashed build r23995-ce7209bd21 which crashed on me in the similar way = device just became unresponsive in about three days.
Then I decided to turn off WED after crash and give it a shot.
Percieved Wifi and routing performance didn't change for me at all with WED disabled. I still observe excellent performance:
850Mbps+ iperf3 WIFI <-> Ethernet
around 1Gbit fast.com benchmark.
For the most important part now:
It's been running 12 days stable! No problems in kernel log either.
Yes, WED has stability issue at the moment. My E8450 has been up more than 30 days since I disabled WED. I still have hardware flow-offload enabled tho.
I use mine as dumb APs (but with half a dozen VLANs), so WED and HW offloading doesn't do much for me. Same experience though, they're rock stable, and aside from the biweekly update, I never need to touch them.
This type of issue:
regular crash around 4 day mark which I observe with WED on
would mean in my field of exprertise (which is Kotlin/Swift native mobile development)
that current WED code causes a memory leak in the MCU.
I'm in no way experienced in kernel/driver/mcu development, so it's just a wild guess.
Same here. My RT3200 has been running over a month on SNAPSHOT as a dumb AP with several WiFi interfaces on several vlans. No WED.
No complaints beyond UNII-1 max txpower still being hobbled to 23 dBm despite the RT3200 having been certified to 27 dBm on UNII-1 by the FCC. Aside from that, it has been rock solid and stable.
Apologies for the delay! Been a busy week and lost track of time. sigh
Below is my current Usteer config that is running on each of my three RT3200s (AP mode). Couple things to keep in mind as anyone looks at this:
I have done some extensive AP signal/SNR testing (using NetSpot) within my particular home to address dead spots and AP overlap. Just slapping this config into place on your device and calling it a day will do you a disservice. You must take some basic steps to tune your AP radio channels and power to get the right overlap within your space.
We all have our "ecosystems" of choice. My family's is Apple. Yours may be Google or Amazon, or something else. The settings I configured in my Usteer config are tweaked based on Apple's specs for wireless operation (read: roaming) of their devices and software. Heavily Android or you name it else platforms may work better with some of the settings tweaked to their specifications. TLDR; non-Apple mileage may vary.
With my little disclaimer out of the way, here you go:
Here's my wireless config. Keep in mind I have a matching SSID name for primary 2.4Ghz/5Ghz, matching SSID name for guest 2.4Ghz/5Ghz, and an IoT SSID on 2.4Ghz only.
Probably goes without saying, but I'll say it anyway... This is just one of three wireless configs. Each of my RT3200s has a similar config, but the radio configurations have channel, power, and BSS color variations that are unique to each AP.
For anyone interested in some nitty-gritty details, take a look here at some of the interesting discoveries I found around Apple's handling of 802.11k:
All I learned from that thread is that some did not want to take the time to carefully read and understand what I wrote, including reading the FCC report. The RT3200 was testified and certified by the FCC for at least 27 dbM on UNII-1 and UNII-3, including antenna gain. If there were issues with legal limits, the FCC would not have certified it.
Unfortunately I'm in a veeeery mixed household (personal devices are mainly Apple, but I also have a bunch of Google Nest/Home devices, Android TV, and due to my job, a number of Android phones). It's a bummer Netspot is so expensive
Same here I see that our configs mostly match, main differences are that I've set up the NAS ID and mobility domain fields - plus I use local PMK generation.
I'll try your usteer settings though and will report back in a few days if it brought any changes, positive or negative.
The RT3200 has been working perfectly, as long as I stay away from using 'AX' and fast transition.
The 802.11r never seemed to work with mostly Apple devices.
I use the 2.4 and 5 GHz network with the same SSID. I have wed enabled now and WPA2-WPA3 mixed mode.
5 GHz network uses the 80MHz AC mode.
This works very reliable in 22.03.5
The moment I make the switch to 'AX', I see this in the log:
Sun Oct 8 19:22:41 2023 kern.err kernel: [660062.100713] mt7915e 0000:01:00.0: Message 000026ed (seq 13) timeout
Sun Oct 8 19:23:01 2023 kern.err kernel: [660082.580463] mt7915e 0000:01:00.0: Message 00005aed (seq 14) timeout
Sun Oct 8 19:23:22 2023 kern.err kernel: [660103.060206] mt7915e 0000:01:00.0: Message 00005aed (seq 15) timeout
Sun Oct 8 19:23:42 2023 kern.err kernel: [660123.539992] mt7915e 0000:01:00.0: Message 000026ed (seq 1) timeout
Sun Oct 8 19:24:03 2023 kern.err kernel: [660144.019767] mt7915e 0000:01:00.0: Message 00005aed (seq 2) timeout
Sun Oct 8 19:24:23 2023 kern.err kernel: [660164.499538] mt7915e 0000:01:00.0: Message 0000aded (seq 3) timeout
Sun Oct 8 19:24:44 2023 kern.err kernel: [660184.979286] mt7915e 0000:01:00.0: Message 0000aded (seq 4) timeout
Sun Oct 8 19:25:04 2023 kern.err kernel: [660205.459040] mt7915e 0000:01:00.0: Message 000025ed (seq 5) timeout
Sun Oct 8 19:25:25 2023 kern.err kernel: [660225.938815] mt7915e 0000:01:00.0: Message 000025ed (seq 6) timeout
Followed by:
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.014248] ------------[ cut here ]------------
Sun Oct 8 19:41:07 2023 kern.warn kernel: [661168.018966] WARNING: CPU: 1 PID: 21509 at 0xffffffc008ba7af8 [mac80211@0000000080a2274c+0x79000]
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.027827] Modules linked in: ksmbd asn1_decoder pppoe ppp_async wireguard pppox ppp_generic nft_redir nft_nat nft_masq nft_flow_offload nft_fib_inet nft_ct nft_chain_nat nf_nat nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet nf_flow_table nf_conntrack_netlink nf_conntrack mt7915e mt7615e mt7615_common mt76_connac_lib mt76 mac80211 libchacha20poly1305 ipt_REJECT ftdi_sio chacha_neon cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY usbserial slhc sch_cake poly1305_neon nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_quota nft_objref nft_numgen nft_log nft_limit nft_hash nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_counter nf_tables nf_reject_ipv6 nf_reject_ipv4 nf_log_ipv6 nf_log_ipv4 nf_log_common nf_defrag_ipv6 nf_defrag_ipv4 libcurve25519_generic libcrc32c libchacha iptable_mangle iptable_filter ipt_ECN ip_tables hwmon crc_ccitt compat sch_tbf
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.027998] sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact xt_set x_tables ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ipmac ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ifb ip6_udp_tunnel udp_tunnel oid_registry vfat fat nls_utf8 nls_iso8859_1 nls_cp437 sha512_generic seqiv md5 md4 des_generic libdes uhci_hcd ohci_platform ohci_hcd usb_storage leds_gpio fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug [last unloaded: ksmbd]
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.180660] CPU: 1 PID: 21509 Comm: kworker/u4:2 Tainted: G S 5.10.176 #0
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.188827] Hardware name: Linksys E8450 (UBI) (DT)
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.193798] Workqueue: phy1 0xffffffc008ba6290 [mac80211@0000000080a2274c+0x79000]
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.201450] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.207536] pc : 0xffffffc008ba7af8 [mac80211@0000000080a2274c+0x79000]
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.214228] lr : 0xffffffc008ba79a4 [mac80211@0000000080a2274c+0x79000]
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.220919] sp : ffffffc012513c90
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.224311] x29: ffffffc012513c90 x28: ffffffc010adf010
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.229703] x27: ffffff8006391000 x26: 0000000000000000
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.235094] x25: ffffffc010adf000 x24: ffffff80027511a0
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.240486] x23: ffffff80099300e8 x22: ffffffc008ba65f8
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.245878] x21: 0000000000000001 x20: ffffff800785b600
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.251270] x19: ffffff8006391000 x18: 00001bf59b0dac5d
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.256661] x17: 0000000000000006 x16: ffffffc0108285d8
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.262052] x15: 0000000000000003 x14: 0000000000000d7e
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.267443] x13: 0000000000000370 x12: 00000000e0ccdeeb
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.272835] x11: 0000000000000000 x10: 000000000000008a
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.278226] x9 : 0000000000000001 x8 : 0000000000000000
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.283618] x7 : 0000000000000004 x6 : 0000000000000000
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.289010] x5 : 000000000000002a x4 : 0000000000000000
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.294402] x3 : ffffff8000cc8b40 x2 : 0000000000000000
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.299793] x1 : ffffff8000cc8b40 x0 : 00000000ffffff92
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.305186] Call trace:
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.307713] 0xffffffc008ba7af8 [mac80211@0000000080a2274c+0x79000]
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.314058] 0xffffffc008ba65f8 [mac80211@0000000080a2274c+0x79000]
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.320402] 0xffffffc010045774
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.323620] 0xffffffc010045a88
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.326839] 0xffffffc01004c840
Sun Oct 8 19:41:07 2023 kern.debug kernel: [661168.330058] 0xffffffc010005f68
Sun Oct 8 19:41:07 2023 kern.warn kernel: [661168.333277] ---[ end trace 205fca1d88bcb705 ]---
type or paste code here
Users may experience stability issues as this is a relatively new feature
I would try switching WED off if you have issues with WED enabled.
Don’t configure WPA2-WPA3 mixed mode. I suggest to instead have two SSIDs: one for strictly WPA3 sae for devices with current software and another pure WPA2 SSID for backwards compatibility for older devices that are not WPA3 compatible. You can choose the radio for these SSIDs.
The stability problems with WPA2-WPA3 mixed mode are well known:
My RT3200 has been OK with 802.11r (the other AP in our home is a Reyee RG E5 with similiar MT7622/7915 hardware) and the same SSID's on 2.4 and 5 GHz connected to common VLANs. Granted only my son has an Apple device (iphone), but there have been no complaints. I do not use WPA2/WPA3 mixed mode or WED, which could be why I don't have issues. As odrt wrote above, hopefully dropping WPA2/WPA3 mixed mode helps.
I don't understand exactly what "switch to AX" means in your context, but the mt7915e timeout error you are seeing is suspiciously close to what I (and others) have experienced with the mt76 driver. It is currently believed to be due to a regression in WED code:
I have been running my RT3200s in 5Ghz@HE80 mode for two years now without any issue with AX or 802.11r, specifically. But all three of them have the MCU reset timeout crash after several hours of uptime when WED is enabled.
Anyone else seeing reduced speeds on the new official 23.05 release?
I'm on AX, channel 100, with 160Mhz, and I'm seeing a noticeable drop in speeds.
On 23.05-rc3, I was able to get pretty insane speeds (~930 Mbps, both directions) over wifi, but with this release, I'm seeing a max of around 860Mbps down and ~375Mbps up, measured using the same device (Intel AX 211) that I used to measure ~930Mbps with, from the same distance. Interestingly, my iPhone is getting ~630Mbps both directions.
The slowdown happens even when using the performance CPU governor. It's the same with ondemand as well.
I measured the speeds using OpenSpeedTest running on a NAS (connected via gigabit ethernet), as well as iperf3 (on the same NAS), and I'm getting consistent results.
Edit: This is with WED disabled, in both 23.05-RC3 and the official 23.05.