so anyone can test this with mediatek chipset that is getting memory leak? so far its still happening no matter what firmware version it is.
tested on Xiaomi Router 4a 100M, memory usage gets higher and higher as time passes by even if the router is basically idling with 1 connected wifi device just constantly pinging the router until it basically stops responding. Same issue with Newifi 3 D2, as well as Xiaomi Router 4a Gigabit Edition. Only rebooting this routers can fix this memory leaks.
Everything was working fine on my TP-Link Archer C7 v5 after the upgrade. Few hours later, the wireless became disabled and I cannot enable it even after a reboot.
No issue on my router (xiaomi 4a gig) with openwrt 21.02-rc3
Thank you for the release candidate 4. I'll make an ImageBuilder's image with ath10k-non-ct drivers and test it on my Archer C7 v2|5's.
On my kernel log for my TP-Link Archer C2600 still getting this:
[11133.736780] ath10k_pci 0000:01:00.0: htt tx: fixing invalid VHT TX rate code 0xff
Made some changes to my previous setup.
- Added a 4GB RPI4 + TPLink UE300 as my main router, running 21.02.0-rc4.
- Upgraded both of my Archer C7 v4 units from 19.07.8 to 21.02.0-rc4, interface migration went well (took two steps in LuCI), turned my previously main router into another dumb AP and made some tweaks to its switch VLAN port config, so far so good.
Had some 5GHz related instability in 21.02.0-rc1 that's gone now.
With more CPU power and memory available, I then set up Unbound + adblock on the RPI4 as to have redundant DNS alongside my RPI3 running Pihole + Unbound + Home Assistant, same blocklists. Couldn't be happier with the upgrade. I'm now free to upgrade to a faster connection in the future.
I'll look into setting up 802.11k,v + DAWN up next now that I'm off 19.07 for proper roaming and band steering
That's actually a beast setup, potentially faster SoC than any of our all-in-one routers (even mvebu). What are you using for WiFi AP though just the C7? I'd like to read about a good WiFi 6 AP paired with a Pi4.
Yes, just my C7s as APs with the RPI4 doing all the heavy lifting. Not using any dedicated switch for the Pi, just the C7's included 5 port gigabit switches. Once you set up the VLANs as required for your needs and a trunk port on each C7 to link it all up, it all works seamlessly.
They make for great APs. Never had a problem with them. Both are overclocked to 1GHz on the CPU, with heatsinks, for a little more grunt. I'm currently on a 50/50mbps FTTH connection, could upgrade to the 300/300mbps service next. We'll see.
For sure these faster connections have outgrown what the single core MIPS CPU in these devices can do if you want all the bells and whistles (SQM...), it was time for an upgrade.
Love the RPI4, couldn't get one until now, but sure had a few ideas pop up in my mind back when it was released and made a thread about it
The Pi4 would love some WiFi 6 APs though. Doesn't break a sweat handling a gigabit connection... SQM or not, encryption or not, it doesn't care. Doesn't need offloading of any kind. Powerful little thing. You had to go x86 at higher power for such feats.
For each new device, someone benevolent need to study the hardware, booting and partitioning, find drivers (etc). It requires a lot of skills and time. This is done when a volunteer choose to do this, for example when (s)he buy or borrow the device.
My BT Home Hub 5A doesn't appear to be too happy, it's totally rebooted itself a few times since upgrade yesterday.....last one was 30 minutes ago
if you like the Pi4. Ever consider this? NanoPi R4S rk3399 4G is a great new OpenWrt device Its nice little toy and with dual ethernet you can make it your primary router (just need a ethernet switch for rest of your lan.) I run seperate ubiquiti wifi APs because they give far better performance than onboard wifi.
The same in my TP-LINK EAP225-Outdoor v1
This problem is as old as mt76 driver; will not be fixed.
Was not aware of that. Thanks for the heads up.
Will avoid MT7615N routers w/ OpenWrt combos in the future.
So I hesitated to press 'Force Upgrade' and [ Continue ]
on my Netgear WNDR3700v5 when I saw this scary warning:
Device wndr3700v5 not supported by this image Supported devices: netgear,wndr3700-v5 wndr3700v5 - Image version mismatch: image 1.1, device 1.0. Please wipe config during upgrade (force required) or reinstall. Reason: Config cannot be migrated from swconfig to DSA Image check failed.
The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform.
Select 'Force upgrade' to flash the image even if the image format check fails. Use only if you are sure that the firmware is correct and meant for your device!
Am pretty sure that I have downloaded the correct image from here:
Can someone confirm that it is safe for me to proceed to force install this image?
p.s. current system status from Overview page:
MediaTek MT7621 ver:1 eco:3
OpenWrt 19.07.3 r11063-85e04e9f46 / LuCI openwrt-19.07 branch git-20.136.49537-fb2f363
same model + same revision + (same country) + sysupgrade = ok (with dont keep settings)
Thanks. I looked on the forums and there's a lot re: "mt76" drivers. Is there a fix or solution?
Well, installed DAWN + luci-app-dawn on both APs, got 802.11k enabled on top of 802.11r. Both DAWN instances are talking to each other and seeing each AP's respective SSIDs and connected clients.
Particularly there is one unique main/home SSID for both 2.4GHz and 5GHz radios on each AP. In that setup with all 4 radios on the same SSID, roaming is definitely improved, its now seamless with no reconnections and my 5GHz devices stay on the 5GHz band on that SSID. Love it!
What's concerning is that setting
bss_transition 1 turns off and disables the radio where it was configured. People had this issue as far back as May 2020.
ieee80211v 1 was removed by October 2020, leaving us with the 802.11v settings themselves to configure, so that commit didn't break anything.
Hmm, this is weird.
@mercygroundabyss I'm aware of the NanoPi R4S, but it's not available where I live and it's difficult to source. There is definitely an appeal for two onboard gigabit NICs!
The Pi4, and LAN -> USB adapters on the other hand, are readily available.
Turns out to enable 802.11v, you have to replace the included ath10k firmware with the full-htt version. Once that was done, setting bss_transition '1' doesn't permanently turn off the radio.
Didn't find this information anywhere, so I'm leaving this here for future reference.
got mine there. got the 4gb version with metal case.
NanoPi R4S (friendlyarm.com) also sell it if u in usa.
I've already added support for the devices and images have been available in the snapshot builds for some time now. I was asking about having the changes merged to the 21.02.0 branch!