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:
- Installed irqbalance. Change 'enabled' from '0' to '1' in '/etc/config/irqbalance'. Essential.
- Enabled SQM. Highly Recommended.
- Disabled 802.11w (previously known to provide issues on mwlwifi). May not be necessary.
- Patched firmware-88w8864 mwlwifi specific high latencies by disabling tx_amsdu. Essential. Add in luci > startup > local startup (nano /etc/rc.local) the following commands:
echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu
Detected Issues:
- Intermittently noticing lag on 5ghz (WPA2/WPA3) with iPhone requiring reconnecting device to network. Does not seem as frequent as in previous iterations, but is unclear. Certainly not as bad with above fixes. iPhone works fine on 2.4ghz.
- Intermittent failure for 5Ghz networks (wlan0) internet connectivity after scheduled reboot.
- daemon.err modprobe: failed to find a module named act_ipt
- daemon.err collectd: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-0/percent-softirq.rrd: opening '/tmp/rrd/OpenWrt/cpu-0/percent-softirq.rrd': No such file or directory
- daemon.err collectd: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-1/percent-interrupt.rrd: opening '/tmp/rrd/OpenWrt/cpu-1/percent-interrupt.rrd': No such file or directory
- kern.err kernel: wlan0: failed to remove key (0, xx.xx.xx.xx.xx.xx) from hardware (-5)
- kern.err kernel: wlan0-1: failed to remove key (0, xx.xx.xx.xx.xx.xx) from hardware (-5)
2 Likes
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.
1 Like
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.
I'm far from preaching. My original post was much more along those lines but I revised it to be less condescending.
However, I believe your concerns arise from a fundamental misunderstanding of how the dual firmware upgrade process operates.
It's your prerogative to take a risk averse stance, but I don't think you fully understand the other side of the coin.
Implying I don't fully understand the other side of the coin without saying what the other side of the coin is, well condescending. I guess I'm not smart enough for you to "understand"... seriously !
My point is that an upgrade from an OpenWrt partition if initiated from a dysfunctional install may also fail, which alleviates the Known Working State to recover from.
Some, including myself, have put themselves in peculiar situations where the current install is now unreliable/unstable/dysfunctional and the only fail safe way back is via the OEM partition and not via upgrading an install not going well at all, no other disrespect inferred otherwise.
I'm sorry the I don't have the ability to "understand"... Some people like myself are just so dumb...
I didn't go into detail because it's been done to death, both on the forum and the wiki.
[OpenWrt Wiki] Linksys WRT AC Series - Dual Firmware Flashing
I can see this has become an emotive issue for you. I'd suggest that if a read of the wiki doesn't allay your concerns that you open another topic for in-depth discussion (as this thread isn't the right place). I'd be happy to not participate further if you think my contributions have been insensitive so far. I don't have anything further to contribute that hasn't been said in the wiki anyway.
1 Like
@SlotTech You have to setup VLAN on DSA-based Switch using "config bridge-vlan" as mentioned at https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial#multiple_networks_using_vlan_tagging .
Neither defining driver-level VLAN (https://openwrt.org/docs/guide-user/network/vlan/switch_configuration#creating_driver-level_vlans) in /etc/config/network for WAN switch port, nor just defining "option device 'wan.35'" in "config interface" section works for DSA-based switch ports.
Below config WORKED in my Netgear R7800 (dumb AP) running @hnyman's DSA build with @ansuel's patches.
config device
option name 'switch0'
option type 'bridge'
list ports 'wan'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config bridge-vlan
option device 'switch0'
option vlan '21'
list ports 'wan:t'
list ports 'lan1:u*'
list ports 'lan3:u*'
list ports 'lan4:u*'
config bridge-vlan
option device 'switch0'
option vlan '22'
list ports 'wan:t'
list ports 'lan2:u*'
config interface 'lan_1'
option device 'switch0.21'
option proto 'dhcp'
option defaultroute '1'
config interface 'lan_2'
option device 'switch0.22'
option proto 'dhcp'
option defaultroute '0'
Below config DID NOT WORK for me
config device
option name 'wan.21'
option type '8021q'
option ifname 'wan'
option vid '21'
config device
option name 'wan.22'
option type '8021q'
option ifname 'wan'
option vid '22'
config device
option name 'bridge_1'
option type 'bridge'
list ports 'wan.21'
list ports 'lan1'
list ports 'lan3'
list ports 'lan4'
config device
option name 'bridge_2'
option type 'bridge'
list ports 'wan.22'
list ports 'lan2'
config interface 'lan_1'
option device 'bridge_1'
option proto 'dhcp'
option defaultroute '1'
config interface 'lan_2'
option device 'bridge_2'
option proto 'dhcp'
option defaultroute '0'
1 Like
isn't this a bit ot? I would move this to a separate discussion
Stunnel isn't working in this version. When it is executed manually it works, but when its launched from init.d script there's a message saying "no more addresses to connect".
don't mislead people
using factory.bin image with openwrt sysupgrade (LuCI) can result in bricking
sysupgrade.bin is the same image format for all devices (at least in a certain target),
factory.bin is different for (most) all device
however some specific devices have a unique upgrade script
in some cases factory.bin and sysupgrade.bin are the same thing
some devices cannot be upgraded via TFTP or other bootloader method, so factory.bin is a one-time-use image
sysupgrade.bin with all boxes unchecked is in (most) all cases the same as a "fresh factory.bin flash"
just say it depends on the device
2 Likes
Do you know who is the authoritative person I should ask in regard to moving an Archer C7 v2 from 18.x to 21.x safely?
The filesize difference is significant. 15 megs vs 5 megs between factory and sysupgrade and there is an architecture change combined with the warning that sysupgrade is not supported and that a "from scratch" install is required. I did not have an issue in the past using factory for incremental x.x.y increment updates.
I suppose I could just play it safe and just flash in 19 ath79 and then flash in 21 but it seems inefficient to do that. Would be good to get clarity on this for this specific device.