OpenWrt 21.02.0 third release candidate

Hi,

The OpenWrt community is proud to announce the third release candidate of the upcoming OpenWrt 21.02 stable version series. It incorporates over 5800 commits since branching the previous OpenWrt 19.07 release and has been under development for about one and a half year.

Changes between OpenWrt 21.02.0-rc2 and 21.02.0-rc3

LuCI

  • LuCI network migration tool now migrates custom bridge MAC addresses.

Software updates

  • Linux kernel updated to version 5.4.124 (from 5.4.119 in v21.02.0-rc2)
  • mac80211 updated to version 5.10.42-1 (from 5.10.34-1 in v21.02.0-rc2)
  • wireless-regdb updated to version 2021.04.21 (from 2020.11.20 in v21.02.0-rc2)

Misc changes

  • opkg: Shows better error message when some dependencies are missing
  • sdk, imagebuilder: json-c, libnl-tiny, libubox, ubus, uci and lua are marked nonshared and will be taken from release build and not package build.

Device support

  • New devices: SERCOMM NA502, Linksys EA8100 v1, Amped Wireless ALLY, Linksys E5600, JCG Q20, cudy WR2100, TP-Link Archer C6U v1 (EU), TP-Link Archer A6 v3, ZyXEL NR7101, ZTE MF283+
  • Device fixes for: Xiaomi Router 3 Pro, HILINK HLK-7628N, WD My Net Wi-Fi Range Extender, ALLNET ALL-WAP02860AC, Senao APs, TP-Link AD7200

Full release notes and upgrade instructions are available at
https://openwrt.org/releases/21.02/notes-21.02.0-rc3

In particular, make sure to read the regressions and known issues before upgrading:
https://openwrt.org/releases/21.02/notes-21.02.0-rc3#known_issues

For a detailed list of all changes since 21.02.0-rc2, refer to
https://openwrt.org/releases/21.02/changelog-21.02.0-rc3

To download the 21.02.0-rc2 images, navigate to:
https://downloads.openwrt.org/releases/21.02.0-rc3/


To stay informed of new OpenWrt releases and security advisories, there
are new channels available:

As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters.

Have fun!

The OpenWrt Community

33 Likes

Mesh Routing

  • olsrd: procd and version update, further fix compiling with glibc
  • babeld: update to 1.10

:wink:

1 Like

Hi,

known issue : since any release > 20.x => DHCPv6 strange behaviour:

  • if leasetime set < 12h then no more DHCPv6 lease given to any client, no more IPV6-PD to any downstream router
  • if downstream router asks for a smaller prefix than the one given to the lan iface from the upstream routeur then (for eg. downstream asks for a /60 when the upstream has a delegated /60 or bigger /61 /62 ...):
    • the downstream router will get, sometimes but not always, a prefix OUTSIDE the delegated scope from the upstream router
    • the downstream router will also get a prefix even from a class not allowed to the upstream LAN interface (outside the ip6assign parameters)

otherwise for me everything else is perfect, thank you for this great job!

regards

3 Likes

Hopefully someone can add support for 64bit odhcpd static hostid. https://github.com/openwrt/odhcpd/issues/27

Have been running RC3 on tplink wdr3600v1 for 24 hours.

So far:

  • upgrade from 19.0.7 retaining settings are OK
  • new config menu of Devices under Network need some time to understand how it works.
  • Lots of new IPv6 config options. RA and DHCPv6 needs time to get started.
  • Wifi Radio seems just refuse to be up with some channel number selection. Sometimes it needs to reboot to get it up again.

Otherwise working fine.

1 Like

relayd(wifi bridge) slow down/up speeds and 2-10% packet loss in mi router 4a gigabit

great job! :grinning:

@rmilecki
You might look into FS#3866 - no network in failsafe
https://bugs.openwrt.org/index.php?do=details&task_id=3866

I think that we are still looking for "ifname" in preinit, although the board.json has been changed to contain "device" instead of "ifname".

Preinit: https://github.com/openwrt/openwrt/blob/ec6293febc244d187e71a6e54f44920be679cde4/package/base-files/files/lib/preinit/10_indicate_preinit#L75

	json_select network
		json_select "lan"
			json_get_vars ifname
		json_select ..
	json_select ..

From /tmp/board.json:

        "network": {
                "lan": {
                        "device": "eth1.1",
                        "protocol": "static"

Above code is from master, but based on forum discussion and the bug report, the same bug is in rc3, as the new network config has been backported to 21.02.

2 Likes

Running great on my WRT32X, ran a few usual tests: DSA working great, SQM Cake maxes my 500/35 Mbit cable with A+ bufferbloat & A+ quality tests, adbock, Samba4 with ntfs-3g driver (it would nice if OpenWrt project would update this driver to the latest from upstream) tested at 120 MB/s on my USB3 external. WiFi 5GHz is good. OpenWrt project should consider shipping with irqbalance because it helps performance. LuCI has made great progress too, very fast.

Here are the packages I install after a clean flash for mvebu if anyone needs:

Summary

opkg update && opkg install irqbalance luci-app-advanced-reboot luci-app-sqm luci-app-adblock luci-app-upnp luci-app-samba4 block-mount kmod-usb-storage kmod-usb-storage-uas kmod-usb-ohci kmod-usb-ohci-pci kmod-usb-uhci kmod-usb3 kmod-ata-marvell-sata ntfs-3g fdisk luci-app-hd-idle luci-app-wireguard iperf3 nano

3 Likes

This might also be the problem why my TP-Link Archer C7's (v2 | v5) could not be accessed via SSH in failsafe mode. Last experienced this bug on 21.02.0-rc.2.

Upgrade from 19.07 with a linksys ea4500:

  • wireless interface not working with wpa3, reversing to wpa2 not working. I had to revert to no encryption to be able to choose wpa2 and be ale able to have wireless working
  • some strange behavior regarding the password after a reset: I was not able to enter with no password. I had to ssh and apply solution for hard reset to be able to regain control...

Thanks for the good work!

Yep.
The default network configuration syntax was changed between rc1 and rc2, but the logic used in the preinit phase (for failsafe) was not updated accordingly.

1 Like

Hi,

Thanks for the new rc release. There has been changes in VLAN support in the various rc's so not sure if my problems are due to those changes or am doing something wrong. If latter please ignore as not related to rc3 (admins feel free to remove my comment in this case). And this is long too, sorry.

So, I have the followings problems. By the way using image:

OpenWrt 21.02.0-rc3, r16172-2aba3e9784
  1. after system upgrade from rc2 without keeping previous config, add more physical ports to factory default 'br-lan' bridge. Save 'General device options' then Save&Apply. Then try to enable VLAN filtering on 'br-lan', add new VLAN ID 1 like this

    Then a new VLAN ID 2 but the moment I press 'Add' eth1:untugged turns to tagged:

Is this a GUI glitch? Anybody has seen this? Or something weird happens my side only?

  1. Now, I try to save the new VLAN filtering config: I press 'Save' something happens as I can see cogwheel but form remains as is, does not go back/up to device form. If I press 'Save' again nothing happens (looks like but see below, point 3). So have to 'Dismiss' this form and back on Device form. Now 'Save & Apply' fails:

    Only choice is 'Dismiss'.

Am I doing something wrong here, cannot create VLAN filtering this way? Should first create new VLAN device then set VLAN filtering?

If I refresh GUI I can see the new VLAN devices created so I guess indeed the problem is that new VLAN devices are not created. Is this a bug or feature?

  1. As I saved twice the VLAN filtering config before it looks like this now:

Also, as can see the untagged ports are shown as tagged although network is:

# /etc/config/network
config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1'
        list ports 'eth2'
        list ports 'eth3'

config interface 'lan'
        option proto 'static'
        option ipaddr '10.0.0.2'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option device 'br-lan'

config bridge-vlan
        option device 'br-lan'
        option vlan '1'
        list ports 'eth1'
        list ports 'eth3:t'

config bridge-vlan
        option device 'br-lan'
        option vlan '2'
        list ports 'eth2'
        list ports 'eth3:t'

No explicit ':' notation means untagged, does not it? Or must use 'ethN:u' and 'ethN:t' format?

  1. I have two of same way configured owrt instances (let's call them R1 & R2) and the plan is to connect them via trunk port (eth3 on both devices) and have two VLANs (id: 1 & 2), assign two interfaces (lan, guest) in their own distinctive firewall zone to each VLAN with different IP subnet (10.0.0.0/24 & 20.0.0.0/24), so both R1&2 has similar config (differences shown inline R1 / R2):
# /etc/config/network
config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1'
        list ports 'eth2'
        list ports 'eth3'

config interface 'lan'
        option proto 'static'
        option ipaddr '10.0.0.1' / option ipaddr '10.0.0.2'
        option netmask '255.255.255.0'
        - / option gateway '10.0.0.1'
        option ip6assign '60'
        option device 'br-lan.1'

config interface 'wan'
        option device 'eth0'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth1'
        option proto 'dhcpv6'

config bridge-vlan
        option device 'br-lan'
        option vlan '1'
        list ports 'eth1'
        list ports 'eth3:t'

config bridge-vlan
        option device 'br-lan'
        option vlan '2'
        list ports 'eth2'
        list ports 'eth3:t'

config interface 'guest'
        option proto 'static'
        option device 'br-lan.2'
        option ipaddr '20.0.0.1' / option ipaddr '20.0.0.2'
        option netmask '255.255.255.0'
        - / option gateway '20.0.0.1'

Looks ok via trunk port connection R1 can be accessed from R2:

# above config generates these routes
root@OpenWrt:/etc/config# ip route
default via 10.0.0.1 dev br-lan.1
10.0.0.0/24 dev br-lan.1 scope link  src 10.0.0.2
20.0.0.0/24 dev br-lan.2 scope link  src 20.0.0.2

# ping from R2 the lan interface of R1
root@OpenWrt:/etc/config# ping -c1 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=64 time=0.381 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.381/0.381/0.381 ms

# ping from R2 the guest interface of R1
root@OpenWrt:/etc/config# ping -c1 20.0.0.1
PING 20.0.0.1 (20.0.0.1): 56 data bytes
64 bytes from 20.0.0.1: seq=0 ttl=64 time=0.446 ms

--- 20.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.446/0.446/0.446 ms

# ping from R2's lan interface the guest interface of R1
root@OpenWrt:/etc/config# ping -c1 -I 10.0.0.2 20.0.0.1
PING 20.0.0.1 (20.0.0.1) from 10.0.0.2: 56 data bytes
64 bytes from 20.0.0.1: seq=0 ttl=64 time=0.328 ms

--- 20.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.328/0.328/0.328 ms

# ping from R2's guest interface to lan interface of R1
root@OpenWrt:/etc/config# ping -c1 -I 20.0.0.2 10.0.0.1
PING 10.0.0.1 (10.0.0.1) from 20.0.0.2: 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=64 time=0.288 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.288/0.288/0.288 ms

Is this legit behavior, should VLAN1 able to talk to VLAN2? Are they not supposed to be distinctive virtual lans segregated from each other? Is this because default route will send traffic through?

root@OpenWrt:/etc/config# ip ro
10.0.0.0/24 dev br-lan.1 scope link  src 10.0.0.2
20.0.0.0/24 dev br-lan.2 scope link  src 20.0.0.2

root@OpenWrt:/etc/config# ping -c1 -I 10.0.0.2 20.0.0.1
PING 20.0.0.1 (20.0.0.1) from 10.0.0.2: 56 data bytes
64 bytes from 20.0.0.1: seq=0 ttl=64 time=0.337 ms

--- 20.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.337/0.337/0.337 ms

No, it is not because of default route. So what am I missing, what is wrong here: different VLAN, different zone, still there is route between the two VLANs??

# /etc/config/firewall
config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'guest'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        list network 'guest'

1 Like

Seems related to this recent fix in LuCI, which does not seem backported to the 21.02 branch yet.

See also:

After Sysupgrade my TP 1043ND v1 is still on RC2 as i can see on the Sysinfo:

I never had this before...any help?

I build my Images with Image Builder and downloaded:

https://downloads.openwrt.org/releases/21.02.0-rc3/targets/ath79/generic/openwrt-imagebuilder-21.02.0-rc3-ath79-generic.Linux-x86_64.tar.xz

Thanks!

Cudy WR1300 upgraded from RC2 to RC3 without any problems. Good work, guys :+1:

Edit: Found out, that my sat-receivers (both with static IPs) could not even pinged from my PC, but they could play videos from the internet (mediathek). Rebooting the Cudy healed that.

Thanks, will look into it. I hope this fix will land in rc3 soon.

My ZyXEL P2812HNU-F1 bricked after sysupgrading from 19.07.0-rc2. Log from serial shows:
NAND read: device 0 offset 0x60000, size 0x200000
2097152 bytes read: OK

## Booting kernel from Legacy Image at 80800000 ...
   Image Name:   MIPS OpenWrt Linux-5.4.124
   Created:      2021-06-13  22:02:19 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    2465658 Bytes = 2.4 MiB
   Load Address: 80002000
   Entry Point:  80002000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!

So I tried to tftp initramfs-kernel.bin, to start clean, but that failed also:

P-2812HNU-F1 # tftpboot initramfs-kernel.bin
ltq_phy: addr 0, link 1, speed 1000, duplex 1
ltq_phy: addr 1, link 0, speed 10, duplex 0
ltq_phy: addr 17, link 0, speed 10, duplex 0
ltq_phy: addr 19, link 0, speed 10, duplex 0
ltq_phy: addr 5, link 0, speed 10, duplex 0
Using ltq-eth device
TFTP from server 192.168.1.2; our IP address is 192.168.1.1
Filename 'initramfs-kernel.bin'.
Load address: 0x81000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##########################################################
         8.7 MiB/s
done
Bytes transferred = 5608429 (5593ed hex)
P-2812HNU-F1 # bootm $fileaddr
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   MIPS OpenWrt Linux-5.4.124
   Created:      2021-06-13  22:02:19 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    5608365 Bytes = 5.3 MiB
   Load Address: 80002000
   Entry Point:  80002000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... LZMA: uncompress or overwrite error 7 - must RESET b

After that the modem reboots, and I'm back in bad CRC.

Reinstalled OpenWrt using the original Scapi uImage-initramfs, which worked, flashed Mafketel's 3MiB 19.07 squasfs, which worked, upgraded to clean 19.07.7, and flashed stock openwrt-21.02.0-rc3-lantiq-xrx200-zyxel_p-2812hnu-f1-squashfs-sysupgrade.bin, which brought me back to the bad CRC:

root@OpenWrt:/tmp# sysupgrade sup
Saving config files...
Commencing upgrade. Closing all shell sessions.
Watchdog handover: fd=3
- watchdog -
killall: telnetd: no process killed
Sending TERM to remaining processes ... netifd odhcpd uhttpd vdsl_cpe_contro ntpd dnsmasq ubusd urngd logd rpcd 
Sending KILL to remaining processes ... 
Switching to ramdisk...
[  122.206005] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" stops
[  122.258365] UBIFS (ubi0:1): un-mount UBI device 0
Performing system upgrade...
Unlocking kernel ...

Writing from <stdin> to kernel ...     
removing ubiblock0_0
[  124.359381] block ubiblock0_0: released
Volume ID 0, size 32 LEBs (4128768 bytes, 3.9 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs", alignment 1
Set volume size to 121411584
Volume ID 1, size 941 LEBs (121411584 bytes, 115.7 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs_data", alignment 1
[  125.651072] UBIFS (ubi0:1): default file-system created
[  125.656386] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 2528
[  125.738588] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "rootfs_data"
[  125.745098] UBIFS (ubi0:1): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[  125.755009] UBIFS (ubi0:1): FS size: 119992320 bytes (114 MiB, 930 LEBs), journal size 6064128 bytes (5 MiB, 47 LEBs)
[  125.765585] UBIFS (ubi0:1): reserved for root: 4952683 bytes (4836 KiB)
[  125.772206] UBIFS (ubi0:1): media format: w4/r0 (latest is w5/r0), UUID 9A794878-A3EB-40EA-BD76-59020A188C5C, small LPT model
[  125.824996] UBIFS (ubi0:1): un-mount UBI device 0
[  125.828419] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" stops
sysupgrade successful
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
[  125.934260] reboot: Res�
ROM VER: 1.0.5
CFG 06
NAND
NAND Read OK

U-Boot SPL 2014 (Dec 08 2014 - 23:28:15)
SPL: initializing NAND flash
SPL: checking U-Boot image
SPL: loading U-Boot to RAM
SPL: decompressing U-Boot with LZO
SPL: jumping to U-Boot


U-Boot 2014 (Dec 08 2014 - 23:28:15) P-2812HNU-F1

Board: ZyXEL P-2812HNU-F1
SoC:   Lantiq VRX288 v1.1
CPU:   500 MHz
IO:    250 MHz
BUS:   250 MHz
BOOT:  NAND
DRAM:  128 MiB
NAND:  128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   ltq-eth
Hit any key to stop autoboot:  0 

NAND read: device 0 offset 0x60000, size 0x200000
 2097152 bytes read: OK
## Booting kernel from Legacy Image at 80800000 ...
   Image Name:   MIPS OpenWrt Linux-5.4.124
   Created:      2021-06-13  22:02:19 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    2465658 Bytes = 2.4 MiB
   Load Address: 80002000
   Entry Point:  80002000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
P-2812HNU-F1 # 

Any ideas?

Did you upgrade from the second release candidate to the third (and keep the second rc configuration), or did you reconfigure from the bottom up?