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.
I get the same error with the imagebuilder configured for Edgerouter 4 with
“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.
I updated my X86_64 router (thanks to the UEFI image !!) with 21.02.0-rc2 and I want to declare a bug (or a strange behaviour) about DHCPv6.
All is working fine if I choose a 12h (or more) lease time.
If I configure a shorter lease time (2m, 15m, 1h or even 11h) no DHCPv6 lease is granted (to any host), only SLAAC is working.
However, I thought that the lease time parameter only concerned DHCPv4 but it seems to also impact DHCPv6 server.
I had to put my old WD N750 back into service under OpenWRT 19.07.7 which does not have this problem of lease time (because 19.07.7 has no X86_64 UEFI capable image to deploy it on my X86_64 router)
For those using WRT1900ACSv2 wanting to run 21.02.0-rc2: Reporting that WiFi, Samba4, OpenVPN, BlockMount, SQM, WPA3, and separate bridge networks (not necessary VLAN) seem to be working extremely well on uptime Day 1. Formally used David 19.07 builds. Briefly experimented with Divested Builds, left for Samba4 support.
5GHz performance significantly improved with irqbalance. Change 'enabled' from '0' to '1' in '/etc/config/irqbalance'. I would argue this performance gain to be essential. Simultaneously disabled 802.11w which was known to provide issues on mwlwifi and enabled SQM, which may be confounding variables.
UPDATE: Also required a patch to fixed high latencies for the mwlwifi driver. Disable tx_amsdu.
Yep same here on my WRT32X, same mvebu platform. Everything running awesome since they applied that fix to samba4. No issues, USB3 read/write at 120MB/s, SQM cake maxing out my 500/35mbits cable modem, adblock, irqbalance added, etc. 1 week uptime.
Upgraded one of our Meraki MR24 access points to 21.02.0-rc2, saving settings. Worked perfectly after first boot, and also on subsequent reboot after LuCI-triggered auto migration of interface and device config in /etc/config/network. Setup includes:
There were a bunch of us on Linksys/mvebu having connectivity issues with rc1 that took a day or two to notice it as it occurred seemingly at random. But hopefully it's fixed in rc2, please report back if you encounter any issues.
I just wanted to let you know that TP Link TL-WR810N v1 works well with RC2. Thank you @hauke for backporting the fix. Free Flash is now running low, but that was expected and it is still OK.
I can confirm RC2 works well with these devices:
TP-Link TL-WR810N v1 (works now, Flash is low but sufficient, I have been warned)
Fritzbox 7320 (USB has power without setting GPIOs, Ethernet not tested, used as a repeater, requires a restart for changes to WiFi settings though)
Ubiquiti UniFi AC LR, no issues whatsoever
TP-Link Archer C2600 v1 (tested 5x devices, all good and no reboots with the scheduler set to performance echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor; echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor)
TP-Link TL-WR1043ND v1 (RAM is now very low, I have been warned, but it still works, opkg update fails though unless adding swap via USB-stick which works but is sloooow)
Even WDS with WPA3-SAE works across different vendors without issues, nice.
I think I'm starting to notice connectivity issues particularly with the 5GHz networks and apple devices. Some incredible lag and difficulty with new websites loading. Trying to read and see if I find an answer, but at least some others indicate it could be related to the wifi driver. The current driver is mwlwifi firmware-88w8864 2020-02-06-a2fd00bb-2.
This fixed the high latencies! I have no idea how to install a patch. I am extremely novice. BUT I was able to place the command in luci > startup > local startup. (Probably could have done nano /etc/rc.local)
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu
There's also a CPU patch in the Divested archives that I haven't yet tried.
[PATCH] ARM Cortex-A9: build the userspace with Thumb-2 instructions
Thumb-2 code is denser than pure ARM, reducing RAM usage and improving performance due to better instruction cache footprint.
The mvebu issues with rc1 was lost connection. I use a Linksys WRT1900ACS v2.
There was a discussion in the rc1 thread where I believe they identified the cause of the connectivity issues. I'm a novice myself so wasn't able to follow the details, just hoping it'll get fixed in a future release.
I have not had any WiFi 5GHz issues on mine. Haven't checked latency as most of my network is hardwired other than a couple iPhones and a ThinkPad X1. I didn't think those WiFi commands were needed anymore at least not on the WRT32X (or WRT3200ACM), but maybe on yours.
rc2 seems to work fine on TP-Link Archer C7 (v2 and v4) and gl-inet AR750. Although I can't get iPhone tethering over usb to work (ipheth driver). I tested on fedora (kernel 5.12.9-300.fc34.x86_64) and it worked fine there. rc2 has 5.4.119, latest upstream is 5.4.124. Not sure if it will be fixed in that version though. Will next rc or final release still have a newer kernel or are we stuck on 5.4.119?