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!
yes, choose other platform, use OEM drivers (with limitations) or forget about stability.
Bro, at the RC4 I have same issuel at my MT7621
Was a little bit hesitant flashing to the newer version, but hey rc4 , successfully flashed: Archer C7 v2 v19.07 -> 21.02 rc4, running wireguard, automigratition to the newer networkconfiguration went fluently. Keep up the good work!
Another developer pushed a lot of awesome changes into DAWN:
I think the changes are very promising.
(They are not included in the current openwrt/master, 21.02.)
fwiw, are you using the grey DSL socket on your HH5A?
If answer is No, you need to disable dsl_control to stop the random reboots.
hi bill, thanks for the reply
yes I am using the grey DSL socket. It's in France, tbh it's been a disappointment, I was getting 98mb with the orange router and this one has gone down to 82mb so I might revert to the old router
fwiw, if your ISP supports vectoring, try different Lantiq firmwares?
The firmware supplied for free by Lantiq, and distributed with LEDE/OpenWrt is over 4 years old and does not support vectoring as far as I'm aware.
I think there is another much longer thread on same subject, but I don't have a link for it.
Regarding the random reboots, have you tried a different power adapter?