I've been recommending to anyone who would listen that their next router be an x86 box. One reason is that weve seen a bunch of people having trouble with high speed connections doing NAT and SQM/QoS on consumer routers. But also people keep finding weird bugs in consumer router hardware and drivers, lag spikes, reboots, strange wifi instability, etc. X86 has a lot more eyes and ears fixing bugs. Most people think it is too expensive, but a $300 x86 router and smart switch and enterprise AP set up will last 10 years and handle 1-3Gbps if you bond NICs, plus you'll never brick it, and you can use the hardware for additional tasks. I figure, lifetime costs including time spent debugging are probably minimized with this set up. Certainly features are maximized. And running OEM firmware on Enterprise AP gear on your LAN to get good wireless performance is much lower risk due to more frequent upgrades and not WAN facing.
As far as I'm concerned its the only way to go, along with a cable or dsl modem in bridge mode if needed.
We are unsure of the particular exploit used in any given case, but most devices targeted, particularly in older versions, have known public exploits or default credentials that make compromise relatively straightforward.<
"... default credentials..." for shure can not be fixed by kernel upgrade.
"... have known public exploits ..." also might be well known vulnerabilties of bash etc.
Nothing to do about just doing a kernel upgrade, too.
A backport of newest kernel patch might be a possibility, too.
How do you come to the conclusion that it would be easy? Did you work on the mt76 code base? So far I've indeed seen very few contributions to it, besides the work pioneered by @nbd in the beginning. Writing wireless kernel drivers from scratch, with limited to completely not existing access to data sheets is not trivial. I myself couldn't do it so I wouldn't even dare to judge the complexity of the task - are you a kernel driver developer?
You could use the SDK to rebuild squid with all features included given that your device is large enough to accomodate it. I do understand that you might not want that or are not able to do that, in this case OpenWrt simply isn't suitable for your use case I guess. I wonder which OEM device allows installing an "uncrippled" squid though.
This issue has been discussed in great depth. You would have similar issues on your desktop distro if neither a battery backed RTC nor connectivity at boot are present. Its not fair to compare heavily limited devices with hard software constraints to general purpose distributions.
[quote="reinerotto, post:19, topic:25785"]
May be, somebody else would also like to have one of these functionalities, but there is no simple doc available, how to properly implement it into openwrt. So I keep the "dirty hack" for myself, instead of polishing and publication.[/quote]
Publishing an unpolished RFC patch would probably already help a lot in getting your changes in shape for inclusion or to gather feedback required to reach the best possible solution.
Sorry, but you quoted (and interpreted wrong) me without considering its context, which was "... roll-up my own sleeves and get going at tackling them myself ...". I also did not write it to be easy, just the opposite.
Yes, I was a driver developer, too, in my youth. On another OS, but to write device-drivers to interface a SIE... PLC or BigBlue process interfaces to another brands hardware was a similar job, so I have some idea about what it takes. Including serious re-engineering, using an oscilloscope for the timing of signals or hardware-line anlyzer for data capture of the comms. And, finally, regarding docs/egoless programming: The finest programs had comments for almost every line of code. Which (also) were lot of different device drivers, written in assembler. Still running today, but because of age, now as VMs under Windows.
This dramatically worse performance is not related to OpenWrt's use of newer software though, its related to the fact that vanilla OpenWrt uses a FOSS wifi driver written from scratch instead of the proprietary vendor blob. There never was an official, vanilla OpenWrt release for the MiWiFi 3 in 2016, just forked OEM versions with closed source driver binaries.
The worse performance is also not primarily related to the age of the device or the length of OpenWrt support time window, it is related to the availability and choice of drivers for the platform.
Using proprietary drivers in OpenWrt is usually not possible for various reasons, with the main problem being the lack of stable ABIs which would require custom tailored kernel trees for many different classes of devices, ultimately leading to scalability concerns.
So what I want to clarify here is: it is not as if these mt7620 SoCs were perfectly supported in 2016 and then suddenly heavily regressed in 2017 and 2018 just because we updated kernels or userland components. The fact is that there's been an OpenWrt based OEM firmware using proprietary drivers in 2016 and that OpenWrt started building target support from scratch in 2017 and 2018. This is an important difference because we're talking about re-implementing (partly reverse-engineering) target support to eventually reach near feature and performance parity with the OEM firmware.
The ultimate motivation for this is to have FOSS code supporting the device well enough for regular use, the project goal is not to simply cobble together and repack binary artifacts with another gui and a package manager.
There are firmware projects pursuing such an approach, like for example Tomato or - to some extend - DD-Wrt which are usually perceived as user friendly and performant. But these properties come at the expense of limited possibilities, possibilities which might not even be relevant to the ordinary user but are relevant for large chunks of the OpenWrt contributor base, such as being able to implement custom kernel code (think CoDel, CAKE, Batman Adv, the entire Bufferbloat research, ...), being able to modify the wireless drivers or the wireless stack (Airtime fairness, custom rate control algorithms, custom wifi protocols, ...), being able to exchange the userland and so on.