OpenWrt 21.02.0 second release candidate

I replaced the luci-app-samba4 package from the new 6/3 snapshot, also installed the new snapshot on my other parition to compare them. Finally I reinstalled rc1 and it's now broken on there too. They were using the same packages after running opkg update. Regardless it's definitely still broken across the board in LuCI the commit (81f4181) that fixed it on 5/31 doesn't seem to be applied.

EDIT: not sure if someone high up read this, but the new luci-app-samba4 package is out and it's fixed :smiley:

on GL Inet AR300M the wan interface counters are reset/wrapped after 4G. Is this expected behaviour?

RX bytes:782349638 (746.1 MiB) TX bytes:1859207343 (1.7 GiB)

Sitll can't install siproxd because the librt package is still missing in the repository...


Please add it. Thanks!

Thx for the hint. Sometimes I changed from wpad to wpad-mesh-openssl. I found it´s not nessecary.
The access point is now running with rc2 and all desired packages

I have updated from 19.07.7 to 21.02rc2 and the third radio (phy2/wlan2) is not coming up.
Just wondering if there's a package missing or something else? This is what I get:

kern.info kernel: [ 2130.775646] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0xb1 error, result=0x1
kern.info kernel: [ 2130.782649] mwifiex_sdio mmc0:0001:1: Failed to start the BSS
kern.info kernel: [ 2130.788432] mwifiex_sdio mmc0:0001:1: Failed to start AP
1 Like

WD My Net N750 works fine after the initial flash but goes infinite bootloop if you reboot/coldreboot it. Maybe some issues with squashfs or nand read/write which were mentioned at [PATCH] SQUASHFS: data probably corrupt. Fortunately you can use emergency flash to go back..

Could you get VHT 160 mhz working?

I have not tried. I do not have any 160mhz clients.

I try prepering image
make image PROFILE=linksys_ea7500-v2 PACKAGES="luci adblock luci-app-adblock"
but I recived

Collected errors:
 * pkg_hash_fetch_best_installation_candidate: Packages for libiwinfo20210106 found, but incompatible with the architectures configured
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci:
 * 	libubus20210215
 * opkg_install_cmd: Cannot install package luci.
make[2]: *** [Makefile:167: package_install] Error 255
make[1]: *** [Makefile:122: _call_image] Error 2
make: *** [Makefile:240: image] Error 2

what the reason of that?

1 Like
1 Like

Hi guys, I'm super happy for the progress on the DSA thing but you should really consider renaming the DSA switch ports to something meaningful like "swethX", or "swportX", or "dsaportX", or "dsaethX" or whatever different from "lanX".

The use of lanX creates enormous ambiguity with the l3 interface names and makes difficult to explain advanced switch configuration scenarios where the switch ports are not being used for "lan" purposes.

For instance, it's far better to have a "wan" l3 interface on l2 device "eth4" and a "lan" l3 interface on l2 bridge of ports "sweth0/1/2/3". This seems quite consitent to me.

Does anyone know if this release fixes the bug in the last rc that caused Linksys devices to randomly lose connectivity (that was introduced in rc1)?

One side of the coin is the business class units. For example the painted port numbers on the chassi on EdgeRouter4 is eth0-eth3 (WAN doesn’t even exist, use whatever port you want). And these ports where given the names LAN0-LAN3 in OpenWRT.

But on the other side of the coin we have the trillions of home use devices that has the chassi port names WAN (camouflaged LAN0) and LAN1 to LANn.

I guess if the firmware would call these port anything else than LANn or WAN as it says on the chassi. Guess how many trillions of notations it would be on this forum about the wrong name then?

And “LAN” is LocalAreaNetwork, it isn’t even a connector port. It is a complete network system. So it shouldn’t have been painted on the routers in the first place in the 90’.

RC2 is working without issues for two days now on my Archer C7 v4 (I am only using it as AP).
Great job.

Those home devices use LAN or WAN labels on sockets depending on the hardcoded feature that socket is intended for in their stock firmwares. For instance, there are devices where such label would show as "LAN4/WAN" on a dual-feature socket because the firmware supports assigning that same switch port to WAN or LAN networks depending on settings. We will end up configuring a wan interface on lan4 device in openwrt 21, which makes no sense.

If we really intend to use the names printed on the actual RJ45 sockets (which is bad IMHO), then we should use the exact same labels (ie. LAN1, WAN, SFP, LAN4/WAN and so on. However, this doesn't work on home devices where the same switch port is assigned to both an RJ45 socket and an SFP one in mutual exclusion. There are other devices/SoCs where the same "LAN4/WAN" labeled RJ45 socket is dynamically wired either to the switch or to a dedicated eth SoC port in mutual exclusion, and this same socket will be referred as either lan4 or eth1 respectively in openwrt 21, which is weird at least.

Also, if switch ports use socket labels as names then the non-switch ethernet ports should do the same.

In my opinion one thing is the actual socket, another different one is the switch/SoC port names, that's why ethX and swethX is both consistent and unambigous.

On the left side is my original network config from 17.07.7 and on the right side the new not working config (after open menu "interface" in 21.02_rc2).

I used the newest snapshot from today: openwrt-21.02-snapshot-r16130-1b27d89d40-ath79-generic-tplink_archer-c7-v2-squashfs-sysupgrade.bin

Uwe

I get the same error with the imagebuilder configured for Edgerouter 4 with

libiwinfo20210106

“found but wrong architecture”.

And this is with only the luci package as add-on package.
I tried first with all of my standard packages with the same fault.
I tried a standard build without any packages add-ons at all and it worked.
So the fault is concentrated to the luci package.

The Kernel docs calls them "swpX" which is nice too
DSA Architecture — The Linux Kernel documentation

It is not LuCI itself, but the underlying iwlinfo (libiwinfo) which can't find the correct libubus.

I am proposing (for master) a more permanent fix for the problem with

Not maybe luci itself but luci or anything else with luci in its name isn’t installing on rc2 so this is very much a partymood cooler for the rc2 release.