Any hints in the system log?
What protocol do you use with the cable connection?
My fiber use DHCP client mode to get IP from ISP.
Same.
Here's the relevant portion of the log (I x'd out the IP partially). It looks normal, I guess, with the possible exception of the "Failed to send" line. I'd have to reboot several times hoping not to get an IP change in order to know if that's expected.
Longtime OpenWRT user. Dunno if this is related to some of the bugs mentioned here on the list & forum comments; maybe someone has ideas on this.
MikroTik RB760iGS (hEX S) flashed with this firmware. Three devices: one worked right off the bat; the other two required multiple config resets to get the WAN to correctly ARP on IPv4 traffic (IPv6 traffic seemed fine on the WAN interface; doesn't seem to pass to LAN on default config though). Also noticing a random reboot occurring at least once every 24 hours on all three devices. Only extra software added is netdata, nano, and tcpdump (for debugging); supporting 20+ machines on each router.
Edit: turns out at least two of the devices haven't rebooted in 2-3 days now; that's good I guess.
I upgraded my WRT 1900ACS 2 from v19 to this version. Unfortunately I didn't read about using the factory image instead of sysupgrade until afterwards. It seemed to work fine using the sysupgrade but I installed the factory image afterwards just in case. That one seems to work fine as well. Anyone know if this can come back to bite me later? If so, how do I know and how do I fix it?
The factory image was only needed for wrt1900ac (v1) and WRT32x, where the kernel size changed (and sysupgrade would not have worked). WRT1900ACS2 should be fine.
1 Like
Archer A7 (=C7=AC 1750).
I upgraded from 21.02.0 using the web interface, "keeping configuration" as I like to do.
When the router reloaded/rebooted, it seemed like it was working, but there was no way to connect to it - via cable or wireless. The lights were flashing "as if" it was working, but no IPs were being issued when trying to connect. (DHCP problem?). However, even if I "forced" an IP by just entering it (on my usual subnet which is 192.168.1.x) it would not respond on 192.168.1.1, nor 192.168.0.1, nor anything.
I tried to "reset to default" by holding the button while the router was booting, or after it had booted, and could not for the life of me figure out how to do that (does that even work?! doesn't seem like it). So I had to go the annoying tftp way. I flashed the original firmware, then openwrt again (just to wipe the config) and that worked.
I also had a configuration backup from 21.02.0 as a tar.gz. Restoring that again made the router non-responsive in the exact same way as above. So using tftp I wiped it again to stock, then openwrt (people are correct, the .bin is not accepted via the official firmware, you have to tftp it now which still works), and then configured the entire router manually again >.< ... which works perfectly fine.
I don't know what the problem is with the configuration. If I upload it I'll have to scrub it of passwords, so maybe I'll do it later, but just FYI something is bad with the "configuration migration" from 21.02.0->21.02.1. Not sure what.
The only "unusual" thing I use is luci-app-ddns (with ipv6 and ipv4 forwarders from afraid.org) which works fine now again after being reconfigured manually. Other than vnstat2, everything else is regular.
Anyway, kind of an annoying experience, but I guess I'll be ready with tftp in case this happens again...
software/hardware flow offloading seemed to be working at first and I got excited, but after a few minutes, the connection died as it does with 21.02.x .
I really hope that gets fixed, because I don't really use the "advanced/qos" features of the firewall, so I don't care if they work, and I'm losing peak download speed performance because of offloading. Not a really huge deal, because I only occasionally burst that much through the router, but please prioritize fixing that.
Thanks
Please start a new thread for this, if you're actually looking into trying to debug this. The usual reason for this behaviour would be runtime-installed packages (missing in the new sysupgrade image) and configuration changes which hard-depend on them, e.g. bash (and setting bash as root's login shell) would be a primary example for this, ddns not really (for that you'd just lack ddns support, until you reinstall the corresponding packages) - special configurations around alternative dhcpd implementations, httpds or special networking packages necessary for bringing up lan could be in a similar category.
I don't want to try to debug it really. I just wanted to report that the upgrade "did not go smoothly" for whatever reason. Now that it's working, I'll wait for the next release...
I have noticed that DDNS obviously doesn't work until the package(s) have been reinstalled, but previously I didn't have an issue with upgrades doing them the exact same way.
Anyway, thanks.
I think the larger point that @slh is making here is that you may have made configuration changes that rely on user-installed packages (which are not part of the standard image). And if those changes and user-installed packages affect critical router functions, the router may be unable to complete booting or unable to start key services.
In that situation, the problem is not technically a bug. In those cases (and I think this is an uncommon situation), the sequence of operations should be to make a backup, take inventory of the critical packages that were not part of the standard image, upgrade without keeping settings, then reinstall the key packages and finally restore the backup. Alternatively, you could try the "attended sysupgrade" that attempts to do all of this for you.
Finally, I'll point out that simply stating that the upgrade did not go smoothly without any debugging information doesn't really serve much purpose with respect to improving the experience the next time. That's like if someone critiqued a piece of your work -- something you really care about -- and simply said "it kinda sucks" -- that doesn't really help. Instead, if they give you details about what does and does not work (and why), you could go back and fix/improve things. Right now, you've basically just said that the process sucks. But if if really is a problem with the upgrade itself (and not specific to your installed packages/configurations) and you can't give the dev team information about why things failed and how to reproduce the issue, you'll almost certainly see the same issues when the next upgrade happens.
5 Likes
The reality of things is I already spent an hour+ debugging what is wrong with the upgrade and looking up how to (try to unsuccessfully) reset the config, do tftp, rewrite 2 times, manually reconfigure, etc. because it's not something I do all the time.
For me, this is something unusual that has happened for the first time in several releases (started using Openwrt around 18.x I think?) using the same upgrade process. I don't know if you want to label it a "bug" or a "change" or "what happened to me."
I fully realize everyone here is a volunteer, and that my post contributes nothing other than "there's some unknown and unknowable problem" but I think it's better than silence which is interpreted as "all OK."
If I see the exact problem recur, I might put some time into tracing it, but unfortunately this is where it ends for me this time.
You likely will. When you have time, or when you make an attempt an upgrade in the future, you should plan to spend some time debugging your issue and documenting your findings and repro steps.
When comparing most of the recent major releases, the update from 19.07 > 21.02 has been more significant in terms of changes to the syntax and under-the hood operating methods than were present in previous upgrades (i.e. 18.06 > 19.07, or 17.01 > 18.06). While it is always considered best practice to not keep settings and start with a default install (using your backup as a reference to then rebuild your configuration manually), it is often possible to keep your configuration across a single major release jump. But, sometimes that doesn't work for various reasons, and 21.02 has, as I said before, major changes that may mean that direct upgrades while keeping settings may not work properly (also note that upgrading from 18.06 is not supported).
Until sufficient detail and evidence is presented, currently it fits in the "what happened to you" category. With more information, maybe we could say it is a change of significance (but actually expected behavior, even if not desired), or possibly a bug if you can demonstrate that something is expected to work (at the level of the code or designed behaviors) but doesn't.
I found it most system stable and time effective to take the time to do a uci code setup script and then always start with fresh config files every single update no matter if it is minor or major.
Yes that script had to be rewritten for 21.02, especially the network part. But that is a rather small job to do in one script in comparison to do equivalent of almost 900 lines of uci code manually in LuCi every update instead of run the script that takes 2seconds and a reboot.
And to some extent it is possible to write the script so it works with many routers just by choosing definitions in the bash code.
And the script is also easy copied so it can be used as a base for a AP instead of routers.
2 Likes
You have a good point with UCI scripting and how useful and flexible it can be. But I was really more targeted on the fact that upgrades don't always work properly when someone keeps settings (and the UCI scripts may also not work across versions). But beyond all of that, it is also critically important that any reported issues are accompanied by details to help determine if there is a bug, or if the user has a specific edge case that requires a bit of preparation to ensure a smooth transition.
Yeah, this. I've been using the uci script approach for years for all those reasons. Yes, occasionally even the script breaks from a change ,but you get an immediate error and not just a silent misconfig discrepancy. Ans you always start with latest and (well, not always, maybe) greatest from default perspective.
Rewriting for 21.xx took me more time since I had to work out the DSA and changes for my specific setup and didn't have a lot of examples to follow at the time. But I got it going after a few hours.
1 Like
I use his scripts and just modify them for instant reset up from clean reinstall.
Its consistent. makes sure i don't forget any thing and as you say its copy it over and 30sec to run vs hunting in all the luci menus to change stuff.
3 Likes
I actually think it was that example I used for start inspiration.
Most of the uci code I needed for my specific setup I actually got from luci itself simply by doing the actual settings but only hitting save instead of save & apply. Then the uci code could be inspected and copied to my script from the little blue box in top of luci that indicates settings to be applied.
But after a while you probably will get the hang of it and more or less free write the code in the script.
When I installed 21.02.1 I actually also implemented the adblocker and banip setup in the script since they are uci compatible.
And for the crown on top of it I actually did after some trial and errors manage to get the script to write the root crontab.
Is Hardware NAT not working for mt7621 in 21.02.x releases? Any plans / directions here?
1 Like
Migration to the 5.10 kernel, nftables and firewall4, all in the 22.xx release goals, are needed before offloading (without breaking ipv6) returns. See the discussion under firewall4 here: Release goals for 22.xx
4 Likes
I was playing around on 21.02.1 and saw this in log
Sun Nov 21 03:31:18 2021 daemon.notice hostapd: nl80211: deinit ifname=wlan1 disabled_11b_rates=0
Sun Nov 21 03:31:18 2021 daemon.notice hostapd: nl80211: Failed to remove interface wlan1 from bridge br-lan: Invalid argument
supposedly in 21.02, 802.11b legacy rates are disabled by default. Does this suggest that setting is not working? or are these messages bogus