There is quite a large community of Linksys WRT arm cortex a9/mvebu based routers that are quite frustrated with the issues introduced from OpenWRT 21 that persist in 22. Some but not all can be found in unresolved bug reports from WiFi to VLAN and routing.
Anyone needing a stable build is still running OpenWRT 19 on these models.
Given their popularity for their performance with Fibre Broadband and VPNs, is there anything that we can do to lobby the developers to continue to release security patches for OpenWRT 19?
And please do not tell us to change router. None of the fastest ones can be sourced as easily or as cheaply in Europe. There is no point in building a firmware that runs only on devices that only a few can get. Here is either a WRT32x or a Negear R7800 which isn't as fast and might come with flash memory defects.
{rant warning}
Beside, I have other routers of different make/models (not as fast as a Linksys WRT32x) that now run OpenWRT 22 and I find that the new switch/VLAN configuration is absolutely rubbish. Look at the workarounds one has to go through only to make it work on a Linksys MR8300 (another popular and cheap router in Europe)! Why change something that worked so well for everyone? Beside some cosmetic improvements in Luci, I find that OpenWRT started a steep regression from 21.
This is a FAQ. The upstream Linux kernel rejected OpenWrt's swconfig and opted for DSA, so the OpenWrt options were/are maintain swconfig out of tree forever or get on board with the kernel's choice.
Personally I am not sure whether I prefer one over the other, but clearly they are different enough to make changing a challenge requiring to relearn a few things. Then again that only applies to existing swconfig users...
Regarding your mvebu, maybe try snapshots so you can report success/failure early to bugs could be detected and maybe fixed early on.
If those are the devices using mwlwifi then that is a dead end, since Marvell sold their WLAN division to NXP any development for it has halted and its been pretty much just getting patches from OpenWrt to keep it compiling and that is never going to get fixed.
Too many things are wrong, please see this thread:
WiFi is a major issue. I found issues also with routing when I have more than one WAN (like Fibre + Wireless WAN backup) that I reported, but others could not reproduce. Later I found out by chance that the issue disappears if I don't have kmod-nf-nathelper-extra compiled in, which I need for my VoIP phone. But the fact that my previous reports could not be reproduced frustrated my efforts to try and debug OpenWRT 21/22.
Unless anyone can suggest a different router with same or better specs that can be easily sourced at a similar price in Europe, OpenWRT 19 will remain a reference for a good number of users. I do not see the point to move to OpenWRT 21 and newer if it can run only on not so good routers. For this reason as a minimum we would like security patches for OpenWRT 19.
I think that developers should be aware and do something about it.
Well, but an unsupported reference. OpenWrt was declared EOL, IIRC when OpenWrt22 was released.
Honestly, the most likely way of getting these would be to start backporting stuff from OpenWrt21/22/Snapshots and maintain your own OpenWrt19 LTS version. This is not the answer you want to hear, but I think a realistic one...
But, in your shoes I would try current snapshots as the shift to kernel 5.15 solves some VLAN related issues that plagued OpenWrt21/22 for MVEBU. I am using s turris omnia with OpenWrt21-based TOS6 with kernel 5.15 and I see no issues (however the omnia uses atheros/qualcomm wifi radios so does not suffer from mwlwifi problems).
Interesting, I use a dedicated SIP/VoIP base station in my network that works well without requiring a SIP ALG in the router, so maybe there are alternatives you could use?
That is certainly a valid decision you can make.
But here you try to externalize the cost from your decision above to others... Let's see how well that will work.
Interesting, I use a dedicated SIP/VoIP base station in my network that works well without requiring a SIP ALG in the router, so maybe there are alternatives you could use?
I too use a Grandstream HT802 for my VoIP (I am in Italy and we are bound to VoIP with FTTH and FTTC), but without that kernel module either the phone rings indefinitely when I receive a phone call (ring sequence not respected and continues to ring even when the caller drops the call), or no voice on the other end.
I think this issue is NOT linked to the hardware. It was introduced in OpenWRT 21 and it was never acknowledged, hence it remains unresolved. With this module, compiled in, if I have 2 WANs the first 5-10 pings to the second (WWAN) are lost. Always, for this reason it is tricky to even run MWAN (WAN load balancer) without some workarounds as it would mark the WWAN as down most of the time.
That should be everything needed to keep the SIP session up, the options would be:
forward the SIP/ RTP ports to your SIP pbx
valid choice, given the number of (barely documented) ports and the funny results with multiple concurrent SIP clients not really my personal favourite
regular SIP/ NAT-T keep-alive pings to the ISP servers
works for me with a Frtitz!Box 7430 behind my (non-mvebu) OpenWrt router (25s intervals), also worked with two SIP pbx'es (7430 && 7362sl)
this is described by Grandstream above, it means the SIP session is kept alive (by hole punching through the firewall) from the inside, by the SIP pbx.
SIP ALG
too much 'magic' for my taste, not so nice security implications in the past as well, /pass
openwrt-19.06 is done and dusted, EOL for over half a year already - that's not going to change, not that mvebu (let's not even speak about mwlwifi) has ever been a favourite among OpenWrt developers to begin with (I don't even think any of them even has one of these Linksys WRT1200AC/ WRT1900AC(S)/ WRT3200ACM/ WRT32x devices to begin with). Stable release maintenance is real work, with no fun involved - there is barely enough manpower around to keep two stable release (21.02.x and 22.03.x) branches alive, while also working on master (where all the fun stuff happens for new hardware) and while also preparing for 23.xy.0 (which is supposed to branch of in 4-8 weeks), (re-)adding a fourth branch (no one cares about) is not going to happen.
Your (realistic) options would be to stick to 21.02.x or to make sure that master is in the best possible shape for 23.xy.0 to branch, the (only-) time for that to happen would be right now (well in advance of 23.xy.0). For the wired usage scenarios, this is a realistic approach (also because there are motivated entities caring about this, be it cz.nic, Solidrun, Globalscale and Marvell (via mainline) itself) - the wireless side would be a (very) different story. The best you may hope for, is that everything remains as it is right now, Marvell stopped caring half a decade ago in late 2018, despite there being major interoperability issues, DFS support being utterly broken and no WPA3 support - and NXP declared these chipsets EOL the second they took ownership (nor provide mainline drivers for their 802.11ax designs).
Or to take the cheap escape route of voting with your wallet and going for different hardware, contrary to your assumptions, there are valid alternatives these days. ipq8072a/ ipq8074a, mt7622bv+mt7915 and filogic 830 can be treated as feature complete 1:1 replacements for any device of the Linksys WRT* range, additionally you have very strong contenders on x86_64, rockchip, qoriq, octeon/cavium and wired-only mvebu/ ARMADA (as well as the kind of special Turris Omnia with QCA AC and/or Mediatek AX wireless hardware) on the wired-only side (in combination with cheap 802.11ax APs (ipq807x/ mt7915).
DSA generally works as well and is in use on most of the contemporary targets (ipq806x is ready, but not yet migrated, ipq807x/ ipq60xx is a more different story; mt7621/ mt7622, ipq40xx, lantiq and mvebu have switched already). The only problem with DSA on mvebu for 22.03.x is that no one noticed/ reported these issues when they arose (e.g. by users running master for around a year before 22.03 even branched off), but the first reports only came in October/ November (demonstrating the userbase of this target)… It is (supposedly, I don't have that hardware) fixed for kernel v5.15+ and therefore the next release (until then, 21.02.x remains supported and master an option, which needs testing, before the 23.xy.0 release).
Disclaimer: I'm not an OpenWrt developer nor otherwise a project member and only speak for myself, not the project.
On my turris omnia with its OpenWrt21+Kernel 5.15 hybrid I see no issues with VLANs, and no reports in the turris forum imply that other still see this issue. So switching to >= 5.15 will fix the issue that make OpenWrt22 drop the mvebu platform. I think especially if one has special requirements it seems best to actively test and report success/failure/issues for the main snapshots to keep mvebu alive and well supported. Asking for longer life support for OpenWrt19 does little to make mvebu future-proof, IMHO.
Forwarding ports to HT802 does not work, it leads to random issues and it is un-necessary (with any OpenWRT version).
OpenWRT 19 might be done and dusted for developers, but it is still in production use for me and many others. I am grateful to OpenWRT developers for all their work. I understand it is not fun to maintain code that is considered by them "done and dusted". However they should listen to their very large use base too. Moreover I think that ethically we should get a lot more years of use out of good hardware that otherwise would be condemned to expanding the volume of toxic waste we send off to landfills or even worse get lost overboard in those dodgy containers full of electronic crap that get shipped from the western world to 3rd world countries.
For this reason, because newer OpenWRT versions have unacknowledged and unresolved defects and do not support good old hardware like Linksys WRT series routers, I will continue to advocate for, as a minimum, security patches for OpenWRT 19, that to date remains the best and the most stable OpenWRT version ever released. There are a lot of commercial products out there still running on old versions of the Linux kernel. Why can't OpenWRT acknowledge that less is more and do the same?
Because what you desire takes time and effort to actually accomplish. That time can not be spent on other things. So, if you volunteer your own time to maintain security builts for OpenWrt19 I am sure you will get applause all around.
If however, as it seems, you want to "volunteer" other peoples' time and effort I predict less success and applause.
I suggest buying used x86 hardware as a router. Find something running a Celeron 3xxx series or better. You get the same reuse of otherwise trashed hardware but dramatically better compatibility and better performance.