this is the link http://downloads.openwrt.org/releases/21.02.0/targets/mvebu/cortexa9/openwrt-21.02.0-mvebu-cortexa9-linksys_wrt1900acs-squashfs-factory.img
also when i try to use the upgrade image for my router i get this error instead
the link to the upgrade image is this http://downloads.openwrt.org/releases/21.02.0/targets/mvebu/cortexa9/openwrt-21.02.0-mvebu-cortexa9-linksys_wrt1900acs-squashfs-sysupgrade.bin
The first link "factory" is Definetly the wrong one and you should not use it.
The second link "sysupgrade" is suitable.
You need to check the red box to force upgrade and keep the white box unchecked to not keep settings
With the increased RAM requirements, should I take that to mean that free RAM will be lower in 21.02 vs the last version?
Has anyone taken note of what their free RAM is now and then, assuming the same config?
Well that the old firmware has to judge it could be contributing, but it has some information that it is due to DSA and that it actually is compatible with the device, but not with the old config. So it could have made the error less confusing. At least when I read it when upgrading my e4200v2 also made me check twice. Even when I hit the upgrade button I was not 100% sure it was compatible (could I maybe have picked the wrong file?).
Also at the time of 19.07.8 it was known that this DSA upgrade was coming so they could have prepared, and to be honest I think they did resulting in the above warning.
Anyway, it is not that big of a deal, but more people will doubt if they did it right or will ask here.
Maybe one other thing to note, if possible in a next version also add a warning not to set back the old backup?
Also the message could mention that there is no need to wipe the whole config:
(even better would be a proper migration path of course!)
Is there anyone 802.11r (FT) works in 21.02 release?
I think 802.11r function is broken in 21.02.
My devices:
Clients:
FT never works.
At handshake timing, log says:
daemon.err hostapd: nl80211: kernel reports: key addition failed.
Both [FT over DS] and [FT over Air] are same.
Hi OpenWRT enthusiasts,
I was searching for a couple of hours how to interpret following:
In particular: "install 21.02.0", all guides say from original firmware use the "factory" image (this does not match for me, I have 18.06) and the other solution is to upgrade using sysupgrade which leads to the error message. Therefore I propose to elaborate a bit the install versus sysupgrade.
You message linked to a conversation with the problem: linksys-wrt3200acm-21-02-0-rc1-popup-message
Which proposes following solutions:
sysupgrade -Fn /tmp/openwrt-YOUR_DEVICE-sysupgrade.bin
So if this is confirmed (please confirm), I propose to add it to the documentations about the upgrade information for 21.02.
Thanks ! and special thanks to the OpenWRT contributors doing such a great job !
Hi,
Overall, I notice a big improvement for WiFi for the D-link 860L (mt76): Thanks!
In the logs, I noticed these error messages:
related to 802.11r (?):
Sun Sep 12 21:08:32 2021 daemon.err hostapd: nl80211: kernel reports: key addition failed
Sun Sep 12 21:08:32 2021 daemon.err hostapd: nl80211: NL80211_ATTR_STA_VLAN (addr=12:34:56:78:12:34 ifname=wlan1 vlan_id=0) failed: -2 (No such file or directory)
And this in the kernel log (wifi is working, but this error is always present).
Any idea what could be the cause?
[ 95.733034] ------------[ cut here ]------------
[ 95.742336] WARNING: CPU: 1 PID: 1177 at backports-5.10.42-1/net/mac80211/airtime.c:457 0x867d7080 [mac80211@2bf0297c+0x7d9d0]
[ 95.765100] Modules linked in: ksmbd xt_connlimit pppoe ppp_async nf_conncount iptable_nat xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT wireguard pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_netlink nf_conntrack mt76x2e mt76x2_common mt76x02_lib mt76 mac80211 libchacha20poly1305 libblake2s ipt_REJECT cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_recent xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY slhc sch_cake poly1305_mips nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 libcurve25519_generic libcrc32c libblake2s_generic iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt compat chacha_mips sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact ledtrig_usbport xt_set ip_set_list_set
[ 95.765307] ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ifb ip6_udp_tunnel udp_tunnel tun nls_utf8 sha512_generic sha256_generic libsha256 seqiv jitterentropy_rng drbg md5 md4 kpp hmac ghash_generic gf128mul gcm ecb des_generic libdes ctr cmac ccm arc4 nls_iso8859_1 nls_cp437 vfat fat usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd fsl_mph_dr_of ehci_platform ehci_fsl sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common crc32c_generic
[ 96.082122] CPU: 1 PID: 1177 Comm: mt76-tx phy1 Not tainted 5.4.143 #0
[ 96.095115] Stack : 00000000 80850000 00000000 8007dec4 00000000 00000000 00000000 00000000
[ 96.111755] 00000000 00000000 00000000 00000000 00000000 00000001 85cedc30 39d25c68
[ 96.128388] 85cedcc8 00000000 00000000 00000000 00000038 805eb4e4 746e6961 35206465
[ 96.145018] 00000000 00000004 00000000 000140ca 00000000 85cedc10 00000000 867d7080
[ 96.161642] 00000009 00000014 00000004 00000002 00000001 8035c59c 00000004 80820004
[ 96.178268] ...
[ 96.183130] Call Trace:
[ 96.183146] [<8007dec4>] 0x8007dec4
[ 96.195006] [<805eb4e4>] 0x805eb4e4
[ 96.201980] [<867d7080>] 0x867d7080 [mac80211@2bf0297c+0x7d9d0]
[ 96.213755] [<8035c59c>] 0x8035c59c
[ 96.220730] [<8000b05c>] 0x8000b05c
[ 96.227668] [<8000b064>] 0x8000b064
[ 96.234599] [<805d0e1c>] 0x805d0e1c
[ 96.241527] [<8007a96c>] 0x8007a96c
[ 96.248469] [<8002c140>] 0x8002c140
[ 96.255431] [<867d7080>] 0x867d7080 [mac80211@2bf0297c+0x7d9d0]
[ 96.267208] [<8002c1e8>] 0x8002c1e8
[ 96.274203] [<867d7080>] 0x867d7080 [mac80211@2bf0297c+0x7d9d0]
[ 96.285995] [<867836f0>] 0x867836f0 [mac80211@2bf0297c+0x7d9d0]
[ 96.297776] [<867d7268>] 0x867d7268 [mac80211@2bf0297c+0x7d9d0]
[ 96.309619] [<867d7348>] 0x867d7348 [mac80211@2bf0297c+0x7d9d0]
[ 96.321418] [<8041e234>] 0x8041e234
[ 96.328410] [<866d2a24>] 0x866d2a24 [mt76x02_lib@368671ea+0x9de0]
[ 96.340566] [<86640530>] 0x86640530 [mt76@80b33703+0x96c0]
[ 96.351556] [<86640530>] 0x86640530 [mt76@80b33703+0x96c0]
[ 96.362504] [<866d5004>] 0x866d5004 [mt76x02_lib@368671ea+0x9de0]
[ 96.374643] [<86640530>] 0x86640530 [mt76@80b33703+0x96c0]
[ 96.385614] [<866405d4>] 0x866405d4 [mt76@80b33703+0x96c0]
[ 96.396532] [<8004b484>] 0x8004b484
[ 96.403484] [<805ece7c>] 0x805ece7c
[ 96.410486] [<8004b994>] 0x8004b994
[ 96.417420] [<8004b854>] 0x8004b854
[ 96.424391] [<8004b854>] 0x8004b854
[ 96.431354] [<8004b854>] 0x8004b854
[ 96.438296] [<80006718>] 0x80006718
[ 96.445234]
[ 96.448596] ---[ end trace 8218b8ab2f5d9a8e ]---
Why are you sysupgrading, you will kill the remaining OEM failover partition...
And replace it with a working OpenWrt failover image...
It sounds more like another symptom I had in 19.07 but with the WRT3200ACM.
“Microcuts” as symptom can be caused by a lot of reasons but since Sweden only in general have IPv4 for the short and probably long future I turned of everything with IPv6 in the router and for me all the “microcuts” and “strange lagging symptoms” then disappeared and have never reappeared since then.
This is a subject and symtoms that appears on the forum from time to time, OpenWRT and the DHCP server seems to have trouble handling both IPv4 and IPv6 if anyone of them are unconnected to the world.
But to be honest this fault should be handled as a unique post in the forum and not in this release news of 21.02 since I doubt it has anything to do with 21.02 release. It will just drown in the chatter and disappear in this mega post.
I have found that the ER-X is completely unreliable using openwrt. I thought I had things running well after disabling IPv6 on each device(bridge, etc), things only run well until you reboot. I then enabled allow localhost (or something similar under eth0) which again seemed OK until a reboot.
Needless to say I've gone back to edge os.
When you say “each device” and “eth0”. Are you sure you have done the DSA config right?
What happens after the reboot? Do you loose the configs settings or get firmware reset or what?
Reporting WRT1900ACSv2 successfully running 21.02.0 - First Stable Release upgraded from 21.02.0-rc4 keeping old configuration. Reinstalled the following packages. Up-time Day 19: few minor issues.
opkg update && opkg install irqbalance luci-app-advanced-reboot luci-app-sqm luci-app-samba4 block-mount kmod-usb-storage kmod-usb-storage-uas kmod-usb-ohci kmod-usb-ohci-pci luci-app-hd-idle kmod-usb3 kmod-fs-ext4 nano openvpn-openssl luci-app-openvpn luci-app-statistics luci-app-adblock luci-app-ddns
Below are my WRT1900ACSv2 configurations for improved WiFi performance, kept since rc2:
echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu
Detected Issues:
I don't agree with people here saying not to use factory.bin
Back in the LEDE days I used to use that instead of sysupgrade with no harm.. though I did later switch to using just sysupgrade w/ keep settings.
"With OpenWrt 21.02, the ar71xx has now been removed and users must use ath79 instead. If you are still running with the ar71xx target, it is recommended to reinstall OpenWrt 21.02 from scratch. Users already on the ath79 target can use sysupgrade to upgrade to OpenWrt 21.02."
"Sysupgrade from 18.06 to 21.02 is not supported."
It is not necessary to flash back to OEM firmware and then back to OpenWRT.
It is not necessary to flash to 19.x and then to 21.x.
You can go straight from 18.x to 21.x with the factory.bin firmware.
What do I care if it changes everything? I am not keeping settings for a 18-21 change combined with an ar71xx to ath79 change. This isn't some sort of broadcom device where it uses all sorts of glitchy nvram variables.
Use factory.bin if this applies to you.
No not sure I did my DSA config correct as it's the first I've used it. Found the guide in the forum to figure out my situation as I don't recall seeing anything in there about a vlan tag on the WAN. The only thing I needed to change for DSA config is my WAN is tagged with vlan35, which seemed straight forward.
After reboot no settings are lost and firmware doesn't get rest. My connection goes to crap, can't load this forum, reddit doesn't load or partially loads. Lots of other sites don't work or only partially load. Just a generally flaky internet experience, my pppoe connection stays up though.
Hello to everyone,
I have a WiFi problem whit 21.02.0 installed on EnGenius EMD1 (IPQ4019).
The signal transmitted from the device is strong but it receives very weak signal from the stations.
With previous version 21.01 transmitted signal was also very weak. It was like the device doesn't use the embedded antennas.
Is there any option that could fix the issue with the weak reception?
That's very false, as the upgrade process is not a "Known Working State" until you can actually witness if the resulting upgrade actually works.
Please refrain from "preaching" OpenWrt rather than actually rely on facts : The OEM partition is a "Known Working State" from which to recover from in the event OpenWrt failed to install properly.
That's a fact and keeping the OEM partition is a guarantied way to avoid Bricking the hardware, period.
I love OpenWrt, but in not event would I overwrite the OEM failover, that would just be useless risk taking.
And the one you are currently flashing from is a known working image, and will become the failsafe fallback, should the new one be borked.
Maybe, having put myself in quite dysfunctional state with OpenWrt, I can't particularly vouch upgrading from there as upgrading from "Known Functional State". The failover is now dysfunctional and an upgrade from there is not guarantied to get you out of trouble.
If you are a pro at OpenWrt, then maybe you have a point or wouldn't care less because you can "solder" yourself out of trouble (serial connection), but for many of us, keeping the OEM is the only guarantied way to recover from a mess and start a fresh install.