@hauke , please fix a typo. An a link to the changelog would be nice here.
It is there...
1 Like
OpenWrt 22.03.0-rc4 works fine on both my routers:
Linksys E8450 (UBI)
Netgear WNDR3700 v4
Thanks to all the folks putting in the time to make this a great alternative to oem firmware. It is much appreciated.
One comment. Since this is going to be production firmware, it would be great to document the "fw_setenv bootcmd run boot_ubi" command a lot better. Lots of people aren't going to be sitting next to their router 24/7 and are going to be annoyed if they have to drive home or to wherever the firmware is installed in order to reboot it. I understand the need for good backtraces but perhaps this can be done in a way that doesn't prevent normal unattended operation.
4 Likes
I might give it a try on my WRT3200ACM. Can't be worse 
1 Like
Bugreport:
To try it out i installed https://downloads.openwrt.org/releases/22.03.0-rc4/targets/lantiq/xrx200/openwrt-22.03.0-rc4-lantiq-xrx200-tplink_tdw8970-squashfs-sysupgrade.bin to a router running an older openwrt image on a vectoring line.
After installation i of course have to add the VDSL-vectoring firmware because the preinstalled in the image does not support vectoring. I scp the latest vr9-B-dsl.bin extracted from a FRITZ.Box_7490-07.29.image and that broke the system. The storage of the device was after copy of file full. I was not able to save any settings any more. Vectoring still not working. I checked if the file was fine. No, only about 400KiB storage was free after installation. But the vectoring firmware is 887,6KiB big and scp a oversize file causes the system to not be able to save the settings.
I think this should not be a situation the regular users should get into.
The only way out of this is to compile a openwrt image from source and not include the non-vectoring firmware but include instead the vectoring firmware into a image to be able to use the new vectoring functionality.
While certainly a problem for you, this isn't a 'bug' of this release. The -rc works just fine as is and has enough space to hold configuration files, just not enough to hold a ~900 KB additional firmware blob (it would work just fine with the default non-vectoring blob on a non-vectoring line) - which is not surprising for a device with 8 MB total flash size.
You can probably squeeze your vectoring blob in using imagebuilder, but at some point it will outgrow its 8 MB flash - the only 'solution' to fix this would be stopping to build images for this device and consider no longer supportable.
1 Like
What is the current status of vectoring capable xrx200 firmware with redistribution capability? At some point Intel should stop to care about the xrx200 licenses because the hardware drops out of the supported/produced hardware by intel/lantiq.
It would be a huge benefit for all xrx200 users and would also kind of fix the problem that regular users cant add the vectoring image to a openwrt release.
There is no license to (re-)distribute vectoring capable firmwares for lantiq. Intel indeed 'doesn't care' anymore, as they sold (ex-)lantiq to MaxLinear, who don't grant you a redistribution license either.
1 Like
Just flashed mine with one from the Image Builder. Didn't brick. My config is as a dumb AP w/ mesh, 12 VLANs, GRE tunnels to other APs.
I do note that surprisingly(?) c7 is still using swconfig. I saved configs and it works fine. One saved file that I don't change but has changed since 21.x is etc/shinit. IDK if it makes a difference, but I've been updating my devices with the one from 22.03.0-rc4 while keeping the other configs.
Devices I've tried:
- tplink_archer-c7: Up 30 minutes
- glinet_gl-ar300m16: Up 30 minutes
- glinet_gl-ar150: Up 8 hours
- ubnt_unifiac-lite: Up 57 hours
- ubnt_unifi: Up 50 hours
All are running as dumb APs w/ VLANs, 4 WiFi SSIDs per radio. They seem fine except the glinet_gl-ar300m16 has Luci issues, but that's probably my fault. Still debugging what's in my custom image.
Hi, i am trying to upgrade, linksys EA4500 from (OpenWrt 21.02.3 r16554-1d4dea6d4f / LuCI openwrt-21.02 branch git-22.083.69138-0a0ce2a) to latest (openwrt-22.03.0-rc4-kirkwood-linksys_ea4500-squashfs-sysupgrade) using sysupgrade.
i am getting following error message
pls advice, how i could upgrade my device?
thanks
Alright, more up to date logs with the disconnect events.
Mon Jun 20 21:55:11 2022 daemon.notice hostapd: wlan1: STA [wifi client mac address] IEEE 802.11: did not acknowledge authentication response
Mon Jun 20 21:55:11 2022 daemon.notice hostapd: wlan1: STA [wifi client mac address] IEEE 802.11: did not acknowledge authentication response
Mon Jun 20 21:55:15 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] IEEE 802.11: associated (aid 2)
Mon Jun 20 21:55:15 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED [wifi client mac address]
Mon Jun 20 21:55:15 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] WPA: pairwise key handshake completed (RSN)
Mon Jun 20 21:55:15 2022 daemon.notice hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED [wifi client mac address]
Mon Jun 20 21:57:03 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED [wifi client mac address]
Mon Jun 20 21:57:07 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] IEEE 802.11: authenticated
Mon Jun 20 21:57:07 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] IEEE 802.11: associated (aid 2)
Mon Jun 20 21:57:07 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED [wifi client mac address]
Mon Jun 20 21:57:07 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] WPA: pairwise key handshake completed (RSN)
Mon Jun 20 21:57:07 2022 daemon.notice hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED [wifi client mac address]
Client is a Fedora Linux 36 Silverblue laptop with the MT7921 RZ608. Kernel is currently 5.18.5-200.fc36.x86_64 on the laptop.
EDIT: more logs, after a reboot of the EAP615 and the laptop.
Mon Jun 20 22:47:07 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] IEEE 802.11: associated (aid 2)
Mon Jun 20 22:47:07 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED [wifi client mac address]
Mon Jun 20 22:47:07 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] WPA: pairwise key handshake completed (RSN)
Mon Jun 20 22:47:07 2022 daemon.notice hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED [wifi client mac address]
Mon Jun 20 22:52:16 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED [wifi client mac address]
Mon Jun 20 22:52:20 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] IEEE 802.11: authenticated
Mon Jun 20 22:52:20 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] IEEE 802.11: associated (aid 2)
Mon Jun 20 22:52:21 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] IEEE 802.11: associated (aid 2)
Mon Jun 20 22:52:25 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] IEEE 802.11: authenticated
Mon Jun 20 22:52:25 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] IEEE 802.11: associated (aid 2)
Mon Jun 20 22:52:25 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED [wifi client mac address]
Mon Jun 20 22:52:25 2022 daemon.info hostapd: wlan1: STA [wifi client mac address] WPA: pairwise key handshake completed (RSN)
Mon Jun 20 22:52:25 2022 daemon.notice hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED [wifi client mac address]
Updated my WRT3200ACM using Attended Sysupgrade today. From 21.03 to 22.03.0-rc4 with only a few problems:
- package crowdsec-firewall-bouncer is missing. After removing package from the list the image could be build and installed without problems.
- iptables rules are still in custom script and will be applied to firewall, but position of rules is not applied (I assume, nftables handles this differently).
Using flowoffloading worked without problems during test. I go back to 21.03 until crowdsec packages are available.
I know more devices are likely to come on 22.03.0-rc4 but has my TP-Link TL-WDR4900 v1 finally reached the end of the road. Is there a list of devices that will be EOL with this upgrade?
The TP-Link TL-WDR4900 v1 is not "EOL". It have a powerfull CPU, 16MiB ROM and 128MiB RAM and can run wifi without any closed source software thanks to two ath9k compatible wifi chips build in.
The partition table set in the bootloader of the device have a preconfigured small size. In general its been tried by OpenWrt to not require a bootloader upgrade or repartition (one possible solution). Until some developer find some time to deal with the compilation issue, you have to build your image yourself for this great TL-WDR4900.
You have to change one line to build a working image like reported here:
The patch that have disabled the automatic compilation of the image is this one: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=d69bf6601e5bff897781361f2718513d4dd8efd8
Thats why you find precompiled images here: https://downloads.openwrt.org/releases/21.02.3/targets/mpc85xx/p1010/
but not here
https://downloads.openwrt.org/releases/22.03.0-rc4/targets/mpc85xx/p1010/
1 Like
Chances for the tl-wdr4900 to be fixed and image generation enabled again are not good.
- this device is rather exotic, so not many have it to begin with (and even less of those have the experience to work on it)
- as mentioned, after several attempts to extend the limits, the kernel size limits are now a hard brick wall
- pushing the limits (e.g. by using an intermediate bootloader) would require serious original development (this device remains exotic/ rare, while the SOC is powerful, its wireless is outdated in the face of 802.11ac and 802.11ax)
I wouldn't bet any penny on this getting fixed for 22.03.x - nor for anything beyond that.
You might be able to recover by manually deleting files from the overlay directory or call the firstboot application (which will rest the router to the original state)? That however is not going to help the main issue, unless after that exercise overlay is large enough for you 900KB firmware blob.
Or if you are fine with repeating this after every reboot you could try to store the firmware blob only on /tmp which is backed up by ram, but will be wiped on every reboot. (Not sure whether it is possibly to easily change the DSL firmware on a running system though).
But from another poster this home build won't yet boot or will need a lot more work to boot?
Why so negative? You just have to set CONFIG_KERNEL_CC_OPTIMIZE_FOR_SIZE=y and its building the image again like reported in the forum post.
Is this something that is now allowed by the most OpenWrt developers? Some years ago a requirement to install OpenWrt to first have to install a custom bootloader was kind of a nogo.
802.11ac and 802.11ax are outdated in the face of ability to run with OpenSource software and not forcing the people to have to install some closed source software. The most people install OpenWrt because its open. Its even named like that 'Open'Wrt. Having to install any kind of closed source software is a step backwards.
This have already happened with other powerfull PowerPC based devices like the Netgear WNDR4700. It have 128MiB of NAND ROM sorage, but because of its OEM configured size for the kernel the default OpenWrt images was not working any more on it. This was then fixed with this commit: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c555b524c7e55f54aea69d11113bc36326aabafe
Tested with the new supported TP-Link RE305 v3. So far, so good. Great work, thank you!
Was seeing similar, especially with smart home devices. Added this to /etc/config/wireless
option disassoc_low_ack '0'
Then restarted wpad.
In my case the AP was expecting a response seemingly faster than the smart home devices could respond, so it would then drop them and it would cycle over and over. With the above change they finish their ack and things are all quiet.
I should add that goes in the wifi-iface section so
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option encryption 'sae-mixed'
option key 'blanked'
option ssid 'blanked'
option disassoc_low_ack '0'
option ieee80211w '0'
1 Like