Future of 432 devices with well developed drivers against new unsupported 5GHz devices

For Developers
1

Hi guys,

I have a serious question about how developing is ongoing.

In one hand we have no new devices with fully working drivers. In some devices there are no 5 GHz drivers are working in others there is no Mesh-networking-support in others there are no drivers for Modem, Broadcom chipsets etc etc...

So to be honest, there is no device to fit most needs of users.

In the other hand there are more or less well developed devices like WR841. There is a lot of work around that device, but is struggeling like hundreds of other devices to get an update to Openwrt 18.06 with a few features.

My opinion is there are 5 Major needs:

These needs are:

  1. wireguard (to have a fast, modern, simple and secure connection to your home network)
  2. mesh-networks (wifi)
  3. low power consumption (That's the major point for the "old" 432 devices)
  4. highest possible througput like I read with "Flow offload" / HW NAT (more than 40 MBit/s - 50 MBit/s, like the original FW often achieve around 80 MBit/s which is in my opinion still ok atm under the major focus).
  5. USB-Function for Print-Server/NAS/external Wifi-Extensions or to build a low power stand alone internet radio for example.

Nearly every device of the 7xx, 8xx, 9xx series of TP-Link are such 432-devices and have in my opinion good reasons to keep alive.

So what can we do?

In my opinion we should care and deliver good descriptions how to upgrade these devices with "Extroot", maybe with FTP, NFS and Samba/Cifs share vor /overload-Partition AND deliver a how to upgrade the devices from 4 MB flash to 16 MB and the RAM from 32 MB to at least 64 MB.

Why? The Flash and RAM is cheap. You get a flash and RAM together for under 2$, maybe 1$. See my links. These are really low end investments. - The only annoying thing is about to buy a programmer for programming the flash. - Maybe we will find a good solution to use already the socket of the WR841 etc. device or how to programm with cheap laying around tools. There are also ready-made PCB on ebay for Arduino (around 3$) with soldered inputs to easily programm the flash-chips Flash-PCB

In the end it should be still possible to use the Chef Imagebuilder to be able to quickly and easiely compile images.

I have 2x 841, 1x 740, 1x Mr3420v1, 1x wa730rev2 and thougt about upgrading them all with some new flash and RAM from here:
RAM and 16 MB Winbond-Flash.

I also already read this about upgrading Flash to 16MB: Flash-Upgrade

So I wanna start a quick and easy installation guide and need your help to collect all the information together.

What are your opinions about the future development?

I also here for example for EasyBox904 there are problems while it's now necessary to change from JFFS to other File-Systems... - I don't know why, but another good example that there is no new and especially no "ALL-IN-ONE" device which has a good support for the necessary major focus and needs.

2

RAM is an issue, 32Mbyte is small by todays standard and most wont bother with resoldering ram and flash-chips. Most of these devices are only fast ethernet and usually have very old wifi chipsets with limited support and performance.

There are several decent devices available such as the one below if you want something "cheap" and "decent" without paying import tax etc if you're in Europe.
https://www.idealo.de/preisvergleich/OffersOfProduct/5641514_-dual-band-gigabit-router-1200-strong.html

You can also find good ones in US/NA for instance.

1 Like
3

"Opinions?"

Plenty of devices with sufficient resources starting at under US$20 / 18€

Kill it now. No more direct support of any device (platform architecture, yes, board-specific changes no) that has less than 8 MB of flash and 64 MB of RAM. Only support the ath79 platform and kill the ar71xx that it replaces (same devices/boards, different code). No devices added that have less than 128 MB of RAM.

No more builds of any device with less 8 MB of flash or less than 64 MB of RAM -- build-it-yourself only.

"Opinions?"

On a 4/32 device that is so under-resourced that it can barely boot a kernel and minimal network services, are you kidding?

5 Likes
4

No good idea!

Very often horrible support of 5GHz and new MediaThek chipsets. 1000 of workarounds that ususally don't work. Usually a lot of more power consumption especially because the new devices have 1GBE-Ports with no Green (100MBit/s) Mode to save energy.

I'm sorry, but please show me a device that really fit to all 5 Points I showed above! Especially if you always consider a WR841-Powerconsuption you won't find another device which can especially for mesh-networks with many nodes a better result!

So please consider this points instead of trying to die all relevant chats about a good solution.

Soldering is by the way for many "Developers" not the biggest issue if you compare the coding shit disasters with drivers in newer devices at the moment. :wink:

5

GL.iNet AR300M-Lite at under US$18

Power consumption measured by me at under 1.5 W total.

6

Both are available; but probably won't fit or run on a 4/32 device; especially the Wireguard software.

Power savings...on an older device...?

Newer ones are usually designed to be more efficient.

You are kidding???

Again, software likely won't fit, and the throughput I/O would be horrible.

1 Like
7

or we might just nuke down whole kernel 4.x series and stick to 3.18 to make a stable OpenWrt release that will also work fine on 4/32. there hasn't been stable release since 12.09 AA. everything else is just pretending things are working with an excuses open drivers can't perform the same as proprietary ones. week or two after 'final' release you have .01 or .02 releases which prove enough how serious 'final' release is...

8

I've been using (compiling my own snapshots) in "production" for years now and experienced very few bumps. That includes Atheros and the newer QCA MIPS SoCs, Mediatek MT7621 (ethernet mainly, wifi is so-so), Marvell Kirkwood and mvebu ARM (mwl has actually worked just fine for me), Octeon Cavium (MIPS64).

1 Like
9

...additionally I think you need to keep in mind that you're not paying for a product meaning that the software might not be as "polished" (polished being debatable depending on who you ask) in all places but how about looking at it the other way around. The vendor firmware lacks something or in some areas otherwise you wouldn't normally look for alternatives just because.

10

@jeff: Thanks for your comment and your work to messure power consumption. Can your device also fit to point 4. highest possible througput like I read with "Flow offload" / HW NAT (more than 40 MBit/s - 50 MBit/s, like the original FW often achieve around 80 MBit/s which is in my opinion still ok atm under the major focus)?

I guess "Flow offload" / HW NAT and also the mesh-point feature of the wifi-drivers are usually the k.o. criterium as I got within the last month during the tries and investments for my electronic trash collection of new and old devices at home. :wink:

So I would suggest, that we maybe could discuss here real solutions about my topic and explain how it is possible to get more space in the old devices. - For sure there are a lot of other users that are really interested in still continuing running the devices for a while until we have real replacements with all fully working functions.

They also suggested about votes of users which devices they are still running and I know the same as you know that the amount of 432-users are 100% the biggest amount of users.

@lleachii: Wireguard is running fine also with Luci on LEDE 17.xx builds! There are enough ready images to download or just create within 2 Minutes your own in the Chef-Online-Imagebuilder I mentioned!

Also newer devices should be designed to be more efficent, but take the real consumptions and consider the driver issues atm! It's just frustrating to always get informations about: This devices doesn't work because it is "Broadcom" or other unsupported but very often used vendors.

That annoys not just me. Or also show me a real working "ALL-IN-ONE" device. - No chance in my eyes at the moment.

So what is the best solution atm. In my eyes, use your ISP-orginal-devices as a Modem on WAN-Port of an mid-aged OpenWrt-Hardware and if you need wifi througput, take a third OEM-device with working drivers for their WIFI.

11

FYI: Strong seems to be a rebrand mark of MTC hardware. In USA exist HooToo and should be exactly the same. Would be great if someone could verify it.

Salu2

12

I have one of those gl-inet devices. I haven't pushed it hard, but I'd be surprised if it couldn't do the full 100Mbps routing without any flow offload (now SQM is a different story)

There are 14 versions of the TL-WR841nd (https://openwrt.org/toh/tp-link/tl-wr841nd) so let's assume you're talking about one of the older ones, like the v7 or something, it's a 400MHz AR7241-AH1A chip from 2010 or so. Compare this to the gl-inet a QCA9531 at 650MHz. So if you are able to push nearly 100Mbps on the old device, undoubtedly you're going to do it even better on the GL-iNet

1 Like
13
  • But you won't get a lot of throughput depending on CPU
  • If you disable WiFi or live in a rural area, entropy may be too slow to bring up WG in a reasonable time
  • Also, my point was only regarding flash space
14

@lleachii: I have more than 25 MBit/s with this old devices and can't test higher bitrates because of my upload into the internet is not faster. - So even if this is the limit, I can't reach more with newer devices and I think most people are satisfied with 25 MBit/s upload and have also no faster Internet-Connection :wink:

1 Like
15

In my opinion all the fancy hardware offload features are bad work-arounds for operating a router with too weak a CPU for the intended use-case. Now at 10Gbps and above we might have no alternative, but even a lovely wndr3700v2 will happily do traffic shaping at around the request 70-80 Mbps rates, something currently incompatible with hardware offloads AFAICT. IMHO operating 4/32 devices should be restricted to use-case where they are not out of their league, like dumb AP or similar. This will put decent and stable wifi drivers/hardware to good use and avoid most of the issues from overtaxing the limited resources of these devices.

4 Likes
16

Understanding just what OpenWrt is may help to alleviate the panic around 4/32 devices and explain why they are no longer viable for "general use".

OpenWrt is a Linux distro, not a complete, from-scratch firmware.

Like any other distro, you start with the Linux kernel sources and upstream application software sources. They are, within reason, what they are and are and aren't drastically modified.

OpenWrt makes some high-level choices related to balancing image size and performance against resources in its selection of packages to use. For example, busybox, dropbear, and dnsmasq are "lighter" than their full-featured counterparts that you'd find in something like Debian.

In some cases, OpenWrt-maintained or OpenWrt-supported alternatives are used for core OS funcrtions. For example, procd and ubus are sufficient to meet the needs of most all-in-one router users and are much "lighter" than, for example, systemd and dbus.

There are also "generic" functions, such as the binaries from hostap that are required to get the functionality from wireless devices that users of all-in-one routers expect.

These are "fixed costs" that are common to every install.

Once down to a platform -- a specific SoC, for example, the kernel needs to be configured to be able to boot and run generic devices, like Ethernet, switches, wireless chips themselves, LEDs, switches, ... At the platform level, basic decisions about the kernel configuration are made and the kernel configuration, at least as far as I understand, is common to all boards on the platform. Discontinuing support for a specific 4/32 board that uses, for example, a common SoC, doesn't impact this at all. If, for example, a QCA9331 is supported by the ath79 platform, it doesn't matter if it is a 4/32 board or a 16/128 board.

At the board level, someone needs to define how the components are "wired up". With the exception of x86 architecture, there usually isn't a general way for the kernel to discover this on its own. For example, "If you twiddle GPIO 20, the red LED goes on and off", or "There's a generic SPI NOR flash on GPIOs 17, 18, 34, and 45." Older kernels defined this in C, current kernels use a "Device Tree" to define it. Once defined, it's good until the manufacturer makes a change in the board. Here, if the DTS (Device Tree Source) exists, discontinuing ongoing support for 4/32 devices won't remove this and you'll still be able to build OpenWrt for the board.

So, what if it doesn't fit into flash?

You need to decide what you can remove. The "tiny" target variant makes some generally acceptable changes for most users to trim kernel size, such as, as I understand it removing debug symbols.

Now what?

For me, go ahead and kill everything related to PPPoE and the like. My modem supplies direct connectivity. By my choice won't work for anyone that has an ISP that uses PPPoE. You may only have IPv4 connectivity, but what happens if you strip IPv6 for a user that only has IPv6-based transport? I could care less about LuCI, but many users find LuCI a huge value to them.

These are personal choices, and it's impossible to have a "one size fits all" kernel / set of packages on flash-constrained devices that can get a device up and running for all users. It's also unreasonable for the OpenWrt project to create ten or twenty variants for each use case of these under-resourced devices.

What happens when the device crashes because it only has 32 MB of RAM?

Again, you need to strip out functionality, a personal decision.

Removing explicit support of 4/32 devices doesn't mean that they can't be configured and built by individuals or organizations that want to use these existing devices in ways that acknowledge their hardware limitations. Yes, if you've got a new 4/32 device, well, you may have to port it yourself and shouldn't expect that the port be accepted by the OpenWrt project. Then again, as @suppenkasper0815 notes, the cost of hardware components are so low that you've bought a "race to the bottom" device, rather than a better-informed choice at a similar price. This is a messaging issue that is being addressed.

Edit: This is nothing new. I go back to the original WRT54G and the release of the variant that dropped to 2 MB of flash and 4 MB of RAM only ran VX works. The issue of 4/32 devices becoming unsupportable has been in "public" discussion here for two years. "You can't say you haven't been forewarned."

5 Likes
17

In my experience with QCA SoCs, any decent, 750-MHz class, single-core, MIPS-based all-in-one router can handle 100 Mbps, usually including SQM of moderate complexity, such as "piece of cake". I would imagine that the comparable MTK SoCs have similar performance, but don't have any personal experience with them.

In both cases, this is assuming you haven't loaded the router down with all kinds of non-router functionality. This is primarily due to the limited processing power of MIPS-based SoCs at a given clock speed and will limit the device no matter if 4/32 or 16/128. If anything, a 4/32 device is more likely to have a 350-MHz class SoC, which will struggle with 100 Mbps.

1 Like
18

Not supported anymore, thats mean security vulnerabilities. 3.16 will follow next year. This is the best way to build a botnet...

Im using around 15 different devices and they are stable. Only serious things happening for me is the hardware dying here and there and its surely not OpenWrt's fault. Bugs happens (like in any software), you cant blame folks working for free for you.

Say thank you to the manufacturer doing a terrible job. The linux community is just trying to fix a mess here.

Sometime stuff need to be patched after software beeing roled out on a massive scale. A piece of software is NEVER truly finished and bug free. Some releases has been rolled out because of big security vulnerabilities.

2 Likes
19

This is further complicated by trying to support hundreds of devices, many of which aren't in the hands of a developer to test, especially those with limited resources.

Microsoft doesn't try to support 8-bit, 16-bit, 80x86, or even Pentium and Pentium II processors, or devices with insufficient disk or RAM. Apple no longer supports PowerPC CPUs, or 32-bit processors. Yes, you can do something with that hardware, but they no longer meet current, reasonable consumer expectations around functionality and performance. Even Debian, as an example of a mainstream Linux-based distro, has minimum requirements.

2 Likes
20

Well i can tell you that 32 gb for a nacked Win10 is surely not enough :smiley: I had fun recently on devices with small ssd....

If im not wrong debian dropped support for a lot of cpus 3 years ago because of kernel changes happening back then.