Or at least some select set -- it doesn't bother me if it doesn't support the video-capture jack and speaker, for example. I put up with the fact that ath79 can't support NAND until 4.19, but that gets fuzzy. My feeling is that there are probably a few that should nix a device from the "Ideal" list, with wireless being pretty high on whatever list one comes up with. Yes, OK that a device doesn't have wireless at all, but not OK if a device has wireless, but it is significantly crippled compared to reasonable expectations.
You didn't get my point. Since Openwrt builds with default configs including Luci for 4MB devices, it will build the same way by build bots. The firmware will work OK, but very few additional packages can be installed. IMHO majority of users are OK with the default package set,
If we have a warning that tiny devices are OK only out of the box without additional software, I see no problem at all.
My workhorse, the ZBT-WE826, is (one of ?) the lowest priced 16/128 routers.
That's not correct. Flow offloading allows almost full Gbit on most of devices. Even very weak ones like tl-1043ndv1 througputs over 500Mbit.
But then you are cheating yourself, flow-offloading in all its technical glory,IMHO really just is a hack that side-steps the normal linux network stack (which is one of the reasons to use Linux as the base kernel to beginn with). Yes, you can do this (if you are willing to tolerate the side-effects of loosing the full network stacks capabilities), but I would not encourage newcomers to go that route at all. I would rather recommend that they buy hardware capable of doing software routing at the desired bandwidth...
Now once the internet link speed exceeds 1 Gbps, there might be no economically sane way to avoid using some sort of offloading, but there are decent devices available that actually allow normal routing up to 1 Gbps (x86 celeron-based or mvebu arm-based boards come to mind here) so that recommending really outdated devices seems counter-intuitive and not doing anybody a favor.
I am not arguing for hiding the fact that with sufficient grit, can-do-spirit, and reduced expectations 4/32 devices can not be made to run recent OpenWrt, but it should be clear that that is a path best travelled by those looking for the adventure of the travel and not those who merely wish to get from point A to point B effortlessly. I guess the opinions differ....
I didn't like the "Ideal" from the beginning, but hey, I'm not the only user of the wiki.
As mentioned further above, it is time for a re-wording.
Hmmm... not sure if I understand you correctly here.
Can you please explain more detailed or give an example?
Not possible to filter via the white filter fields on top of the columns.
Filtering for empty fields can only be done in the datatable definition:
That's the reason why "-" is prefered over a completely empty field. Better to have $something in a field than nothing, because it is easier to filter for $something.
This is where I (and others) think you are wrong.
Bulk of the people trying a custom firmware does so because they want additional functionality. a 4MB device can barely do what it also did with stock firmware. In some cases it can do even less (some devices like MR-3020 have "configuration profiles" you can switch with a physical hardware switch).
This is imho the issue.
I did flash my MR-3020 back to stock firmware for this reason for example. It is able to do more (in a convenient way anyway, of course it can do crazy smart reactive stuff if I don't use LuCi and use scripts and command line, but I don't usually need it to do very smart things)
And what is your point? Remove the support completely because you can't get additional features?
It's a two-fold concern. The first is that a large class of devices that are broadly acknowledged to be poorly supported for an advertised, primary function for must users appears in the "Ideal for OpenWrt" list at all.
Yes, there's some "fine print" there, but we all read fine print so carefully, right?
In the past I've had some problems getting to a device page (which assumes that I know there is such a thing), having to go through the technical details page or search with Google or the like, but it looks like there's a link for it now. However, that link is far, far off the screen to the left. Here for a 1440-wide (laptop) screen
lost between long URLs, and, to someone not very familiar with the ToH,
What is a Device Page and why should I care? This is Ideal for OpenWrt after all.
Perhaps, at some time in the future, the "Ideal for OpenWrt" table will exclude those that don't have whatever we define as "required when present functionality" (to allow, for example, clearly router-only devices) from the "Ideal for OpenWrt" page, and have a big warning icon early in the table for lists that the device appears otherwise.
As you (should) have noticed, this was settled many months ago, and everyone agreed that there is no reason to drop support.
Most of this thread from that point onwards is focusing on filtering these devices in the Table of Hardware or adding warnings in the wiki/Table of Hardware and so on, so that people are discouraged from using them.
I'm just reacting to you that say "no there is no problem" when yes there is a problem.
This ties in with what I said in the PM thread about the same topic, copy-pasting here as it's relevant to this specific case
If we talk about hardware support of the device, factor in this list is how much features of the device are actually good and working. (yes I know this requires more work than just placing a filter for RAM/flash size)
For example, if we know that a wifi router device has unsupported wifi, USB, Sata, or whatever else, or it runs like garbage for some other reason, then this should prevent it from going in the Recommended list even if otherwise it is a 16/128 device. We only want 100% good devices in the Recommended table.
This could be implemented by adding an invisible "Not really Recommended" field in the table, which can be enabled manually for each device we think is problematic enough to require it.
So that the filtered table will show devices with > 16/128 AND no X in the "not really recommended" field, and the "supported" device list will show either devices with > 8/64 OR devices with a X in the "not really recommended" field
And I propose this thing because it's probably easier than finding a way to parse and deal with anything people wrote in "unsupported" or "comments" to do it automatically, plus filtering for wifi chipsets and so on
Yes I know I'm not the one doing the job so I'm probably not really entitled to make requests and all that. Take it as a suggestion.
I'll try to remain in-topic, so, should OpenWrt support devices with only 4 MB flash?
1- Yes, please do it, as long as possible, and please make a (very) clear statement about it. Perhaps it would be easier to make a statement addressed to those (few, I guess) of us that are used to build our own images, that to explain all possible cases to a newcomer who wants to download some cool firmware.
2- Please consider it is still possible to buy new 4/32 hardware. I actually bought four TP-Link WR940N v6.0 last November and I could buy right now some 800 at my usual store. It is an ath79 4/32 device. I think it would be a little bit shocking if a free software distro could not be deployed on new hardware.
3- Please consider that price and features are not always the motive to buy some hardware. I bought those 4/32, ath79 WR940Ns because WR841N v13, which is an 8/64 ramips device, and is 25% cheaper (15 vs 20 € ) has bad wifi.
I knew for sure that ath79 is rock-solid because all our devices (remember, some 50) are ath79 and last year they gave 0 incidences, even if most of them are close to be 7 year-old.
I want them rock-solid and long-lasting because if one of them fails, it could be that I need to drive some kilometers off road to reach the farm where it is deployed, and that is not cheap, neither in time nor money. So I got the WR940Ns, because, in the long run, they cost the less, even if they are 4/32, even if they cost 25% more, even if there are (seemingly) "better deals". Remember, out organization is a not-for-profit.
4- Please consider, before you say that would give so much more for that 20 €, that before buying those WR841N v13s I checked the forum, I saw the concerns about wifi stability and then I saw somebody stating boldly it worked perfectly for him.
Don't get me wrong, I gratefully take your advice about hardware, there could not be better advice, but I always will be cautious and always, when buying new models, at first time, will purchase just a few ones to test them myself.
Perhaps looking for devices that are rock-solid and last more than 6 years (which is quite the double that my LED TV did) is to ask too much, but I don't think so, since it is exactly that those ath79 devices are still doing, while here it does look (sometimes) as if they should be dumped from "day cero".
5- Please don't assume there is any "typical use case" Simply assume there will always be a use case for that "pesky" hardware. While we could look for high throughput in our PtP links, don't look for more that 30 mbps on our PtMP links. So ath79 is still good for us, and I guess it is good for those tens of thousands of freifunk guys, too.
6- AFAIK, what OEMs as TP-Link do, is to put an older kernel, etc, in their firmwares. If they can, I can't understand why OpenWrt community could not. It would be a shame to have to get OEM firmware again, and it does look as it being possible, not just for 4/32 devices, but for 8/64 too, in a not-so-far future.
While I think it could be too late for 4/32, I think something should be done so 8/64 devices can be supported long after they vanished from stores, as it should be with free software. I can only assume this a a matter of interest (or lack of). So if OpenWrt community thinks monetary support is needed, it is legitimate to say it clearly. Perhaps we could open a new thread about this matter.
7- I don't think, in any way, that devices that are perfect for the work, known for being rock-solid, long-lasting and can be purchased new right now, should get dumped. I hope that openwrt community does think the same. If this is not the case, or if there is danger this can not be done, or if there is widespread consense that it is not worth, please make a statement so we can start to look for alternatives.
One major reason is TP link doesn't give a fig about if your router is rooted and part of a botnet and injecting ads and stealing your crypto currency or whatever. OpenWrt does.
Hi @tatel, These are great questions, and I thank you for pulling them all together in one good note.
There's another conversation going on on the forum that bears directly on your questions. The conversation distinguishes between:
- suitability of a device for OpenWrt (especially for people making new purchases)
- support for a particular device (whether people can get help with questions they have on their existing gear)
Your questions deserve a longer answer than I can provide right now. But I can assure you that no one is thinking about removing the ability to use or build OpenWrt on any device that's currently using it.
The current conversation is about how much of our limited developer and volunteer support people's time should go to bringing new versions of OpenWrt to these older, lower-capacity devices.
Thanks again, and I'll get back to you soon.
That's not fineprint:
What is indeed missing: A link to https://openwrt.org/meta/infobox/broadcom_wifi
I added that link now.
Apart from that: The "Unsupported Functions" column exists. For a reason.
That's something that you frequently seem to overlook.
No offense, just noticing.
Always has been there.
From the first revision of https://openwrt.org/toh/views/toh_available_864:
Again, you have the tendency to overlook some information. No offense, just noticing.
Sidenote: In order to avoid people overlooking the unsupported functions, I pulled this datafield out of the "Supported Versions" datatable on the devicepages, triggered by your first mention of "oh, I read that as supported!".
I find that separated "Unsupported functions" a bit ugly, but I rate the clear visibility higher than beauty.
You see, I have taken your overlooking / misreading seriously and tried to make this information clearly visible.
Fully agreed, but then again: We do have an awful lot of data to show, don't we?
We can pull devicepage and dataentry columns more to the front, but then again someone else will complain that other data is not visible... How ever we are doing it, we are doing it wrong for someone.
Get a bigger monitor.
I have 2560 horizontally and can see the full table:
I'm fully aware that not everybody has that much horizontal space available, and that my monitor is not the measure for everybody else.
On some datatables we have this in place:
This and an additional "Use your browsers zoom function to see more of the table" on really broad tables could help.
We could also reduce the font size of datatables in general in order to show more data at once, but then again users are overlooking / misreading information (sounds familiar to you, eh?-). Again, how ever we are doing it, we are doing it wrong for someone.
The Broadcom Wifi warning is present on the devicepages (not 100% sure if we have that on all affected devicepages; feel free to check the devicepages and add the Broadcom wifi infobox if it is missing), together with the "Unsupported functions" data:
If the user is searching for installation instructions (and if there is a devicepage available), he will see the Broadcom warning and can then decide himself if this device is suitable for his needs or not.
Well for the "core" members of the different communitys outthere, we do not recommend 4/32 devices since ~2016 anymore. Because of the flash, but they are running out of ram and cpu power too. Mainly in big domains with a lot of routers talking to each other over batman (only splitting those domains help, at the end producing more work for the admins keeping the infracstructure running). And we had several problems with ram filling bugs that are still in the process (2years!) of being fixed with bountys. So even if you pay devs to help your fleet of devices, we are getting slowly to the point of full madness trying to keep 4/32 alive.
A bit offtopic, to get an idea of how big this matter is to us:
And the link of my local community map, take a look under "Statistiken" to see how much devices with 4/32 we are running: https://karte.freifunk-muensterland.de/map/
Open those links only with a desktop/laptop. Its a bit heavy for mobile devices and i recommend checking the eye symbol on the second one...
I agree to this statement.
Although 4/32 devices and how we show them in the different ToH views are somewhat related, we are slowly drifting away from the real topic (see top of this page).
Oops, I missed the fact freifunk is a mesh community ant that means batman, which, AFAIK, does eat more than a little bit of RAM
That said, it's not 4/32 what really worries us here (but it does). It is the fact that it does look as if 8/64 could get out quite fast, too. We still have not deployed 8/64 devices in production, just four of them for tests, and we already hear that to do really good things we should go 16/128.
Well, I know this will show how much years I have on my back, but when I was in my twenties, computers with 8 MB RAM were the good ones to do pre-impression work on newspapers... so havin go to 128 MB RAM does look as things are going nuts. No offense intended.
Seems pretty fine to me.
Warning, some devices listed here are using Broadcom WiFi chips and have very poor WiFi support
would be non-fine.