Significantly slower performances on 1 year old device

Maybe... is this is how Openwrt development works now? We will see how the project will end up...

For the average user it is probably cheaper and more reliable to buy a Netgear's Nighthawk router. The R7000 came out in 2013 and Netgear have been keep it updated until now. A few people I know are still happy with it. I think Netgear here figured out what people want and keep their resources under control. They rarely have multiple hardware versions and keep updated their devices, including the old ones.

You can still find it for $100. Considering how much time I spent here, it definitely a lot cheaper for me. I just thought I could help other people and help to make things better... Should I look to another project?

I have to agree to Camicia. For me, it makes no sense to try to do an upgrade to a new LEDE/openwrt-version, when the actual one still has serious flaws, but known flaws, at least. Good example is the MT76-driver. A new version of openwrt also includes newer package versions, which sometimes also show up with new issues.
I would prefere to see the available resources better to be invested in stabilizing the actual version, instead of chasing the next one. Which usually also brings some new openwrt-specific surprises, made even worse by the lack of documentation. I.e. what all this ubus-stuff is doing behind the scenes, or netifd, is some kind of black (?) magic for me.
Regarding security: I think, that this argument is too far stretched. To be victim nowadays, it really needs concentrated effort of the attacker. How likely is a consumer device to be the target ?

Feel free to contribute in that. Openwrt is a community effort. YOU are part of the "available resources". You could backport the necessary security patches and package versions to the old release branch(es). Devs would like to have more help there.

Sure. the difference is that you and other customers actually pay Netgear for the devices. Openwrt is just a community of enthusiast hobbyists, and nobody is paying anybody. So, people tend to focus on interesting topics instead of old releases.

Not quite sure how you meant to make it easier. The OEM vendors want to keep those closed-source drivers proprietary, so they have not released the source code. YOU could try talking the OEM vendors into releasing the source code of their proprietary drivers, but so far nobody has succeeded in that.

And even worse, the current "open source" wifi drivers all include some closed source "firmware" component eventhough the main part of the driver is open-source. (Especially ath10k and mvebu/mwlwifi, and to some extent also mediatek, while the old ath9k in ar71xx was completely opensource) That decreases the opensourceness of the current wifi drivers all the time.

I wonder if as the owner of the router you could extract the driver from the original firmware and upload it to the installed version of Openwrt. I think the licenses are different and not all of them can allowed the owner to do it. I also know that the driver may need some features available on other parts of the original firmware. When I wrote "make easier to use a proprietary drivers" I meant, where it is possible, make it easier to the owner to replace the opensource driver with the OEM's one.

Different kernel versions, different compilers, etc. Sadly not possible.

The OEMs make the public part of the sources available on their sites, but the proprietary parts they only provide as blobs.

Well... It does not have to be a concentrated effort of the attacker. Because of spread vulnerabilities the bad guys can scan a range of addresses and attack all the vulnerable devices. It is usually completely automated. It is a actually a pretty BIG problem with ton of devices being exploited.

In the best case you end up having a slow connection because the CPU of the router is use to mine some crypto or your bandwidth is used for the exploiter's plans (i.e. DoS attacks, VPN their traffic for unlawful actions, ad click frauds, etc). In the worst case scenario, (1) images are stolen from the IP cameras or conversation being listen from devices with microphones. (2) it can facilitate installation of malware. Ex: DNS resolving to links that redirect to download of malware, show you specific fraudulent ads.Push you to fish sites etc (3) activity on the router and mac addresses can be used to find out how valuable the devices in your house are, your street address can be reveled and traffic patterns can tells the bad guys if you are home or not and used to plan when to come to visit for a burglary.

I leave you with some links to where to start:

As much as we all would like this to be different, in a volunteer project everybody is free to scratch their own itches. As everybody else I have a pet theory at what feature/bug all development should happen ATM :wink:
I also realize that the way to make this happen (my features/bugs being tackled) is to roll-up my own sleeves and get going at tackling them myself (I am confident though that if I should have questions on the way the main developers will be quite responsive with comments and helpful advice). In a volunteer project there is a single resource once can directly influence, one's own time and effort.

This is unfortunately not true if you look at all the bot nets that constitute out of buggy routers or internet-of-(broken)-things devices all of these where/are consumer devices. See

Devices left unpatched (kernel and user space) are actively exploited, so not-upgrading is not really an option; unless wifi-performance trumps network security. But even in that case you are better off using a fully patched device as the border router and only use the proprietary firmware device as "dumb" AP, which significantly reduces the exposed attack surface from the internet. From my limited experience only a few vendors actually do reasonably responsive and long-term firmware maintenance to be considered candidates for border security devices. Now, if you assume your internal network to be as insecure as say the WLAN in a Cafe and keep all end devices patched up and secure by them selves (as one probably should) the security of the border device gets somewhat less important, but still even in that case having one's router participate in a bot-net seems undesirable, no?

P.S.: Just saw that I am coming late to the party, basically says everything in more detail...


Yes: have the SoC manufacturer make them available for the newer (but still upstream supported) kernels OpenWrt uses.

You brush away the arguments people raise here about community and limited manpower, yet you squarely ignore the crucial problem at the heart of your conundrum. You draw the wrong conclusions based on the limited information (and thus skewed perspective) you have. Don't get me wrong - thats completely human. But you're pointing fingers at the wrong people.

You bought a device - no doubt in good faith - that was probably advertised in some way by the manufacturer as 'OpenWrt based', and are now finding out how much marketing speak that really was. @slh punctured that marketing speak eloquently and concisely.

TP-Link had a good reputation for being OpenWrt friendly (past tense; FCC regulations turned that around). MediaTek wanted to collaborate on a FOSS driver for an 802.11ac chip (unlike other manufacturers), which is what gave birth to mt76. Point fingers at MediaTek for not helping out with further driver development. Their MT7615 3x3 AC chip e.g. is completely unsupported at this point. I am not aware of any corporate contributions to the mt76 driver. It would benefit them as well, but they only think about their wallet. Not about their customers.

The 'OpenWrt' mutilation that runs as stock firmware on your TP-Link is by now full of holes, probably, and chances are it used an old kernel, and even if it was once LTS, it has been deprecated by now and has its share of bugs and security holes. Yet at this point, you expect OpenWrt to pick up the slack for the manufacturer, then complain about manpower and priorities. Isn't that a bit weird?

I get your frustration, but you're barking up the wrong tree.


I guess I did not intro well the question in the original post. The core issue here is not: "I bought a device with Chaos Calmer I want to run v 18 on it". The matter is: Why a pretty significant number of devices get supported only on one or two versions of Openwrt before becoming unsupported or unstable on new versions? And what can we do to extend support?

It sounds that regarding some Mediatek firmwares for their SoC, the answer is: they have never been really supported because the drivers are not open source. But except reverse engineering the original firmware, there is very little that can be done.

At the same time for other devices, it is also clear that long term device support has openly not been a priority for the Openwrt team

Where can you find it for $100? Believe me, I had a long search for a r7000 and such a price has never popped up.

It looks like MediaTek collaborated or offered resources for initial MT7612E driver development (and maybe others, but it looks like MT7602E e.g. is pretty much a rebadged Ralink 802.11bgn chip) and they stopped caring about it pretty quickly. I'm pretty happy with my MT7621 device myself, but I'm only using the 5 GHz.

Yes, but this is not my point. I was referring to the notion, that kernel upgrades for openwrt are required to enhance security. Which is correct, strictly speaking, but to take advantage of such a kernel level vulnerabilty needs a highly sophisticated attack, very unlikely to be done against a consumer device. Pratically all your links refere to hard coded paswwords, or bugs in layered software, like bash, for example. Or vulnerabilities in Windows apps, which can easily exploited, as you explained, but not to be prevented using kernel upgrade of openwrt.

This is rather unrealistic. Simply because of lack of LOT of special knowledge. In case, it would be so easy to fix the deficiencies of the MT76 driver, instead of simply filing so many complaints, why is it not done already ? So many lazy guys around, only complaining ?
Besides, I can fix some things myself, i.e. to activate a feature of the original package, i.e. squid, which I can use in LINUX easily, but not in openwrt, as the functionality is crippled by the package maintainer. Or to fix earlier setting of correct system time during startup, not to let wireguard complain.
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.
Which even is unpleasant, because in the very past we had one basic principle in coding: Egoless programming.
But we also had another principle: Software without docs does not exist.

While I agree with many of your points about packages, I have to disagree vehemently with

As just one recent, widespread exploit,

Though the vector of the above attack is not clear, remember that the TCP/IP stack is generally managed by the kernel/Linux code.

1 Like

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.

1 Like

Which specific devices are you talking about?

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.

Sorry for misinterpreting your response then, I did not mean to intentionally misquote you.