Not sure how the name plays into this, but those are not the only things to consider, for example if you have modified /etc/firewall.user.
My suggestion would be to backup current config, force flash, do not keep settings. Take a backup of the OOTB configuration. Reconcile and merge requisite differences, then reload config. But, each to their own.
OK I will need some more guidance before jumping in 
Glad I stopped sooner rather than later.
OOTB config: after flashing and not keeping settings, this will by my OOTB? I will then have something to fall back on if I do stuff wrong..
I think doing everything from scrach will be faster than looking for differences as you say, it's mostly firewall, wlan, dnscrypt-proxy, adblock, banip, dynamic dns and wireguard I will have to do over.
Thanks for your fast service
An old post, if you flash from partition is good there should not be any issues. Yes, if you flash an image without keeping setting you will have the OOTB defaults. You can always get back to this with firstboot.
The reason this may be important is there is a difference in the way /etc/config/network looks on a mamba compared to any of the others.
It's only an example. I've tried with many ports: 90 , 91 and others. None worked. I'm very confused....
How are you testing if the port is open?
Are you making sure to be connecting from a device outside your network?
Are you sure your ISP modem is bridged or in DMZ mode?
Are you sure the destination port is truly listening?
@frootloobs
If you start fresh and document your changes now you will have easier upgrades in the future.
Just write down somewhere all the changes you make.
or use uci show before and after configured to get the changes.
About "port forwarding not working"
I've compared the configs between davidc502 and your build and I don't see any big differences.
The only big difference is that in davidc502 (openwrt 12xxx) the interfaces LAN and WAN are setup as 'bridge'. In yours build not. Can be this the problem ?
This evening I will start to make some check using tcpdump and I will check if it's a firewall issue or something else.
Best regards.
New builds are up with revised 5.10 patches from @rsalvaterra and the DSA/FDB fix patchset updated for 5.10 thanks to DENG Qingfang.
They do not contain WireGuard, until PR3885 is ironed out.
Please test them.
I've got both my units running it with no issue so far.
For those building, I suggest you drop all patches, and apply the 20 from here.
You can choose 5.4 or 5.10 under Global build settings > Use the testing kernel version.
Have fun!
Waiting on my current Compile run and then i will simply rm -rf ~/openwrt/ and re-run my setup script.
As i completely forgot how to drop all patches like a moron be it for the git am or patch -p runs.
Will also be using the O2 patch but not thumbs going to see which one cause the segfault on certain programs.
Thanks, I will have to do that. Would be nice to have a complete build and just install it, but I understand that it's not that easy to make everyone happy
Hi everyone, just wonder why the "push" for kernel 5.10... As of right now it's projected to be EOL in 2022, unlike 5.4 which goes till 2025
Does it have some special features that makes it way better (in the context of the mvebu target of course)? Any other considerations?
TIA
5.10 is the next LTS, support till 2026 supposedly; although there is some conflicting info.
ipq807x and even more ipq60xx, ipq50xx, bcm4908 and realtek (rtl838x/ rtl93xx) need newer kernels, so do modern Rockchip and Allwinner/ sunxi SBCs; ath79 (as a new upstream linux target) and ag71xx would strongly profit from a resync with upstream and mt7622 is actively developed. For all 802.11ax devices you really want newer kernels, likewise ARMv8/ ARM64 (which form the basis for all newly released routers, as well as the existings Marvell ARMADA 3720 and 8040, SOCs to stay within the mvebu target) in general is actively developed (a lot of security improvements are happening here and for x86_64 in the aftermath of meltdown/ spectre and the lessons learned from those). Updates for mtd (NAND and spi-nor flash) are always in demand, so are wireless updates (admittedly, those come via backports - but the less you have to backport, the better), wireguard wants kernel v5.8 (keeping the out-of-tree module maintained is hard and gets increasingly harder), exFAT wants kernel v5.4, Paragon's new ntfs3 driver is still to be merged mainline and wants the newest kernel you can get. Many RPi4 users already desperately want updated rtl8153 drivers (which OpenWrt 21.02.x won't be able to provide because of kernel v5.4 (v5.9 is needed for those) for their second/ addon USB3 ethernet cards - the same story goes for 2.5GBASE-T/ 5GBASE-T and 10GBASE-T PCIe cards. DSA drivers are under active upstream (mainline-) development for (at least-) lantiq and ramips, the bigger the version skew between OpenWrt and mainline, the harder it gets to maintain (both upstream in mainline linux and downstream in OpenWrt).
…and all that is before even looking at USB devices (5g, ethernet, …).
Sticking to older kernels should never be considered to be an option, it makes it harder for everyone involved and makes future upgrades even more difficult. If upstream kernel maintenance ceases to exist in 2022 (which is unlikely, at least the upcoming Debian 11 'bullseye' will have to maintain kernel v5.10 until ~2024 (and they have opted to take over upstream LTS kernel maintenance for that purpose at least twice before)), that would just be more of a reason to ship the next OpenWrt version with the then-current LTS kernel.
Thanks @anomeome and @slh for explaining it! As far as performance, do you know how 5.10 compares with 5.4 - ie any optimization and / or performance improvement in 5.10?
And who do we have to thank (aside from @SkewedZeppelin of course) that mvebu is still supported under 5.10 - ie does Marvell still provide code to merge in upstream Linux?
TIA
Hi
I am currently using stock OpenWrt 19.07.2 - Should upgrade to latest version but perhaps I should test out this build while at it. I am not a very experienced OpenWRT user though and might need some hints. I do not plan on keeping any of my existing config. It is not much config to keep.
Did not plan building my own images so plan on using the already built images from this is still the recommended place to get them?
I noticed some noise about the move to kernel 5.10 but from my understanding is there no official mvebu support there only some initial commits upstream witch left me confused. The latest custom images are with Linux 5.4.x or are they with bleeding edge 5.10?
Cheers
Forgot this, sorry: My hardware is Linksys WRT1900ACS v2
@wally_walrus
Performance is likely unchanged.
As for who to thank, that is just the OpenWrt developers, the Linux kernel maintainers, the communities, and everyone in-between.
For these specific devices you can thank Rui Salvaterra for the 5.10 bringup.
And DENG Qingfang for backporting the DSA/FDB fixes from Vladimir Oltean and Tobias Waldekranz.
I've not done all that much, just try to bring it all together and make it usable.
place to get them
divested.dev
is still very much the correct link, at least for my unoffical builds.
only some initial commits upstream
The patches have already been accepted upstream, they should hopefully be merged soon.
The latest custom images are with Linux 5.4.x or are they with bleeding edge 5.10?
Builds with both are available.
20210221-00-RESIZED is currently 5.4.
20210222-00-RESIZED-5.10 is 5.10, as implied.
You can also check their corresponding configs: CONFIG_LINUX_5_
Its also noted in the changelog.
My hardware is Linksys WRT1900ACS v2
You can just flash a sysupgrade from LuCI with keep settings unchecked and force checked.
@SkewedZeppelin Thank you so much for your swift reply!
Tested with LuCi as you suggested - Downloaded
divested-wrt-snapshot-r15882+11-4b37e3bc2b-mvebu-cortexa9-linksys_wrt1900acs-squashfs-sysupgrade.bin
On validation I got:
Device linksys,shelby not supported by this image Supported devices: linksys,wrt1900acs armada-385-linksys-shelby linksys,shelby - Image version mismatch: image 1.1, device 1.0. Please wipe config during upgrade (force required) or reinstall. Reason: Config cannot be migrated from swconfig to DSA Image check failed.
The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform.
I stopped there. Lost my nerve forcing this update without checking with you first. This should be the right firmware?
@steinmb
Yes that is correct.
You are running an old version.
These devices received a name change, and the DSA migration happened.
keep settings unchecked and force checked and you will be good.
Great, thank you.
Yes. You should restart from scratch. "Force" install without your config. Start from the beginning.
steinmb; how did it play out for you? I'm thinking about upgrading from davids and I got the same hardware as you. I have a dumb ap connected with cable, its providing wifi in a part of my home. Will this work on first boot after sysupgrading? Wifi is turned off on the router, but should be useable from my dumb ap?
edit: I can answer myself because I just upgraded without keeping config and forcing to the latest 5.10 version. Dumb AP came back in a minute or so I'm a happy man so far!