This is a release candidate, it is built for testing. Either install the package manually or wait for the final release.
If you want to manually install the package for testing the release candidate, the RC3 packages are available for your archictecture in the sub directory „packages“:
https://downloads.openwrt.org/releases/21.02.0-rc3/targets/
Swapped in a mesh node with it. EA8300. Running well.
Currently using a Newifi 3 D2 and updated to the latest release candidate. It's working fine. Looking forward to the stable release!
I also use Newifi 3 D2 but I cannot success to use ocserv 1.1.3 (openconnect).
The server only return the same sha256 number whatever I use diff. cert. .
Edit : It should be 21.02 use https by default.
How to change login from https to http and disable the cert
How to change login from https to http and disable the cert
Legacy rates option has disappeared from wifi, but may still be needed (for 88w8997 on Espressobin Ultra) !
Because the option legacy rates is removed while wireless is modified with luci, I had to do an UGLY FIX : (adding this to /etc/rc.local)
uci set wireless.radio0.legacy_rates='1'
uci commit
wifi
In the uhttpd config, disable “redirect http to https” should do the trick.
But in mvebu 21.02-rc3 i installed this weekend https isn’t default anymore.
I just tried a RC3 (64bit) image on a Raspberry Pi Model B and it doesn't boot. Snapshot works fine, anyone having a similar issue?
thanks, will try
I assume you meant model 4B? RC3 boots fine here. Make sure you are wiping your data partition, depending on how you're updating you may have a stale/bad config. Try booting while connected to HDMI and see if there's anything interesting there.
And @Pico as well:
Sadly, this seems to be a continuation of the perennial Wifi issues on MT76, but it was shared by ATH9 platforms like the C7 all the way through 19.07.7, so likely a bug in something common.
Fix is simple, create a script and use cron to run it every couple of minutes (I use 1 minute, as I get loud complaints if down for >60 seconds):
NOTE: sscript is for the C7, asjust the 'wlanx' to match your devices 2.4GHz radio
# ------- call to check 2.4 Wifi ----------
# if channel != 8 then
iw dev wlan0 scan trigger freq 2447 flush
#else
# use ch 3 -> 2422
#--------- end check ----------
Got lazy and that's as far as I got, I lock that AP in on ch 11, so it does not change. Just left comments to remind me I'm poking ch8.
That works great on both the Archer C7 and on an MT621, both running 19.07.7. I assume it will continue to work on 21.x
I have noticed that the Radio on my TP-Link CPE610 V1 is running at a lower power level on 21.02 RC3 than it used to. I noticed that in the Bootup messaged that Its Reporting ‘EEPROM regdomain sanitized’ whereas before it reported ‘EEPROM regdomain 0x0’. How do I fix this?
See Log Snippets below
Openwrt 21.02 RC3
[ 10.662123] Loading modules backported from Linux version v5.10.42-0-g65859ec
a4dff
[ 10.669889] Backport generated by backports.git v5.10.42-1-0-gbee5c545
[ 10.743865] xt_time: kernel timezone is -0000
[ 10.763802] urngd: v1.0.2 started.
[ 10.992433] PPP generic driver version 2.4.2
[ 11.005619] NET: Registered protocol family 24
[ 11.135594] ath: EEPROM regdomain sanitized
[ 11.135609] ath: EEPROM regdomain: 0x64
[ 11.135613] ath: EEPROM indicates we should expect a direct regpair map
[ 11.135640] ath: Country alpha2 being used: 00
[ 11.135644] ath: Regpair used: 0x64
[ 11.150472] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 11.153134] ieee80211 phy0: Atheros AR9340 Rev:2 mem=0xb8100000, irq=12
Code Based on 19.07
[ 7.725388] Backport generated by backports.git v4.19.161-1-0-g4bb568fe
[ 7.750243] nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
[ 7.936844] xt_time: kernel timezone is -0000
[ 8.147163] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 8.216578] urngd: v1.0.2 started.
[ 8.454193] ath: EEPROM regdomain: 0x0
[ 8.454205] ath: EEPROM indicates default country code should be used
[ 8.454208] ath: doing EEPROM country->regdmn map search
[ 8.454226] ath: country maps to regdmn code: 0x3a
[ 8.454233] ath: Country alpha2 being used: US
[ 8.454237] ath: Regpair used: 0x3a
[ 8.471263] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 8.473135] ieee80211 phy0: Atheros AR9340 Rev:2 mem=0xb8100000, irq=12
My device is: tp link Archer C7 V5, using "openwrt 21.02.0-rc3" version, using 500m optical fiber broadband. After testing, the download speed is up to 23m / s, which can not reach the full speed of 40m / S. in order to verify this problem, I return to "openwrt 19.07", which can reach the download speed of 40m / s. Hope to pay attention to this problem, thank you!
I was many problems with C7 V2 with RC3. Wlan 2.4 disappered, no internet even network was working and later need do total reinstall. I install later snapshot ( tplink_archer-c7-v2-squashfs-sysupgrade.bin, 30 june) and change correct IP´s with Putty. Then all was fine. Not sure was problem caused by Luci or some bug in RC3. Only problem is now, static leases always trigger lease timer.
edit: RC3 was working one day. Next day was no internet.
WPA3 mix WPA2 not working 5GHz, WPA3 mix WPA2 was working with 2.4Ghz, but not tested much because it disappeared a lot.
edit2: I did´t know. I hope add some info text with GUI static lease time , "infinite" using no lease time roll around.
v21.02.0-rc3: I'd suggest to include wpad-mesh-openssl by default for Archer C7 models (instead of the currently included wpad-mesh-wolfssl). Mesh had problems reconnecting after one of the two routers rebooted (stuck for ~ 24 hours in SAE-AUTH-FAILURE, reason 55 MESH-AUTH-BLOCKED for 300 s). The problem immediately disappeared after switching to wpad-mesh-openssl (which I've also had used without any problems under 19.07.x).
I've tried both RC3 and snapshot on a ZBT-WE826 (32M) (ramips). Both images have a bug with this device when rebooting. "reboot" is acting like "halt" or "poweroff".
The unit is 1000Km away and the only way to recover the access is by asking someone to power-cycle it.
There're other people complaining about the same issue on different architectures.
I'm also running RC3 on a U7628 (16M) (ramips) and it reboots just fine.
Any ideas?
My professional experiences is that not even Cisco is so good that they don’t requires a person on a regular smartphone connected to 4G 1000km away ready to pull the power plug if needed.
You simply have to high expectation on technology.
You completely misread the problem...
You run a RC3 and/or a snapshot release with known reboot problems 1000km away and you don’t like the reboot result?
I don’t really see that technical solution as a smart thing to do if you don’t have any “backup” in place. With these functional terms you demand you should run the super stable 19.7.7 on a device 1000km away.
What did I miss?
Nowadays there is possible to buy these small 4G remote power switches you can put in the wall socket. You can use that for a power reboot.