Significantly slower performances on 1 year old device

I noticed some devices like the https://wikidevi.com/wiki/Xiaomi_MiWiFi_3 were originally released with a modified version of Chaos Calmer in 2016 and being able to work at full WIFI speed.
The https://wikidevi.com/wiki/TP-LINK_Archer_C5_v4.x was actually released at the beginning on 2018 an it is using the same MediaTek MT7620A chip.

However those devices have dramatically worse performances on Lede and OpenWrt 18.06.1.

I am aware that even on laptop, in general, as new software come out it is more resource hungry and it does not work as well.

However at the end of 2018 Mojive can still run on a 2012 MacBookPro quite well. An iPhone 5S released in 2013 can still run the latest iOS 12 quite well.

Why some routers that are just 1-2 years old cannot run on a newer version of Openwrt? What is the bottle neck? Is it the new kernel that is too resource hungry? Is the CPU or the RAM the main bottleneck? Can we just disable some features to make the device run fast on the latest kernel version? Is it necessary to update the kernel so often assuming an old version is still being maintained?
Should not OpenWrt embrace the LTS strategy that some Linux distributions are using?

Exactly this part is incorrect. Those devices have been released with their OEM firmware, which is based on the SOC vendor's SDK - which in turn might be loosely based on Chaos Calmer, albeit with the essential bits and pieces replaced (ancient kernel, proprietary wireless drivers). The result is not OpenWrt at all.

Yes, with newer software the minimum hardware requirements are slowly rising, look at https://openwrt.org/supported_devices/432_warning for a rough idea, but we're talking about 4 MB flash or 32 MB RAM being the cut-off there - and the writing has been on the wall for these devices for quite a while before that already, but at some point you do hit the cliff (no longer enough storage for the overlay, opkg, uhttpd or kernel running out of RAM).

Btw., may 2015 versus june 2018 isn't merely a year, but three years - longer than the complete life cycle of many consumer devices these days.

Ok... thanks for being more specific. What I meant is that there has an Openwrt base. The proprietary wireless drivers make a huge difference, I know. I actually I wonder if something could be done to make easier to use a proprietary drivers for those that want to. At the moment, it seems that using propretary drivers is hardly an option.

Thank you for providing that link. I like the suggestions of multiple configurations:

  • Full ⇒ allows for running gui, has working opkg and plenty of space to allow packages
  • Medium ⇒ allows for running gui, has working opkg and at least enough space for setting up extroot
  • Small ⇒ bootable images can be built when either sacrificing gui or opkg while still having configuration persistence
  • Micro ⇒ only choice are heavily tailored custom images that require special measures like pre-shipped configuration, NFS mounts, preconfigured extroot etc.

My feeling is that most of the devices will be able to work fine and serve well their users without upgrading to the latest and the greatest version of kernel and some packages. The problem are the unpatched vulnerabilities.

In fact, from the messages here on the forum, it is pretty clear that people keep using the devices with these vulnerabilities. Some people are aware of them and ignore them. Others do not even understand they are there. As long as the parts that Openwrt is based on are maintained and patched (for example the specific Kernel version used), it would be great if that version of Openwrt can still be maintained. Usually older versions receive less updates and are more stable. Even from a maintenance point of view are not usually a lot of work.
It would be great if Openwrt in general could receive more frequent updates. Automatically or with just the push of button in LEDE.

I also enquired about this on Support and updates on Openwrt .

There are many thinks that would be nice but there are limited resources, it makes sense to spend resources on modern inexpensive devices compared to obsolete older devices not still available in the market.

What if you have longer support for devices and at the same time the need of less resources?
In my humble opinion, for example, it would be possible to provide longer support for devices, more frequent releases reducing the time necessary to do this.

The way to get people to spend their time and resources in the way that you want them to is very simple: pay them to work on your project.

2 Likes

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 http://blog.netlab.360.com/bcmpupnp_hunter-a-100k-botnet-turns-home-routers-to-email-spammers-en/
and https://blog.trendmicro.com/trendlabs-security-intelligence/reigning-king-ip-camera-botnets-challengers/.

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, https://forum.openwrt.org/t/significantly-slower-performances-on-1-year-old-device/25785/12?u=moeller0 basically says everything in more detail...

2 Likes

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.

3 Likes

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