I know there is a lot of great and helpful people here, so I do not want to offend anyone. But it is hard to deny, there is a lot of work to be done on the documentation part.
I bought this router recently: Linksys MX4200v1. But this is not a supported device, despite what is written in the wiki. The 24.10.0 software is unusable. The 5 GHz radio had worked at first but it started to work randomly. The 2.4 GHz radio had worked some time but stopped and I couldn't have make it work again, at all. There is a topic on the forum with over 2500 comments. Is this OK for a fully supported device? Great, there are people who care about making it work.
It is not just MX4200. I have another router TP-Link MR600v2. And it is listed as supported. While reading the forum reveals, the device doesn't work well.
Descriptions for them are misleading. How many such devices exist on the list of supported devices?
My points is: if the device does not work flawlessly then it is not a supported device. The fact, someone successfully uploaded the newest software is not and should not be enough. There should be some categories for routers: fully supported, partial, under development. Perhaps, you should have some kind of automated tests to be able check how the given OpenWrt version works on routers.
I think it is not about: „make the routers work“ but rather about adding notes to Wiki if problems are known - and this could be done by everyone. Current a lot of device wiki pages read as everything is A-Okay.
And as a note to myself, I will add more stuff to the Wiki for devices I own
@frollic I was thinking about some basic tests, like a simple app or script, working on a PC, checking connection capabilities, with some different parameters or something like that. Nothing too complex. But to be honest, I have no idea, how they should work.
No offence, but I have doubts whether there is really 2k supported devices. The current list is about 2770 devices. After filtering with 16 MB Flash, 64 MB RAM and AC wifi it lowers to 673. And how many of them are really supported and fully operational!? Don't answer, please.
@kusmi Yes, exactly. The best idea would be to add some categories and improve wiki pages. There will be always routers with some issues.
I also believe, some work optimization could make everything better. There is more and more devices. And keeping all of them supported is probably an impossible task. Perhaps, focusing on some main-stream devices would be a better idea?
Even if you reduce the list to ipq40xx/ ipq50xx/ ipq60xx/ ipq806x/ ipq807x, mt7621+mt7915DBDC, filogic devices, to name the targets with the most recent activity -and I'm omitting the big and vibrant mt7621 target here, as that's harder to distinguish between ac and ax- we would be talking about ~230 devices, which are recent enough that we should expect them to 'work' (and again, that ignores mt7621 and ath79, both of which are huge and in common use). How do you imagine to keep track of these?
first buy them
if we assume an average cost of 50 EUR device (it's more), you'd look at a cost of 11'500 EUR up front (add shipping, handling, disassembley/ preparation/ mounting, etc. you're quickly adding a factor of *3-*5)
to power them 24/7
if we assume a ~5 watt average power consumption (in practice you can triple that for many recent ax devices), that's ~4000 EUR/ year (assuming European/ German electricity prices) just to power them, nothing else
if you want a test farm, you need remote power and serial console access, which is a considerable expense as well
you need some location to physically mount these devices, with electricity, network connectivity (fast internet connection, static IPs, many switches), cooling(!), compliance with safety (fire!) regulations, and on-site remote hands
some orchestration to
remote power on/off
remote serial logging
testing procedures (and you'll find quite some difficulties to do meaningful automated testing for this, simulated ethernet environments (think huge managed switches, fast servers to push some simulated load), all that in an environment that is extremely hostile to wireless connectivity, so testing that will be a different dimension 'fun' (regulatory compliance issues aside))
decent log parsing, which would be a whole software project on its own, to spot failures in the first place
remote power/ logging/ console facilities will be a whole hard- and software project by itself, as well as a fulltime job to prepare the devices for mounting (shuck, solder serial console access, remote reset, etc. pp.=
have developers at hand to actually look into the failures (which includes shipping them the failing device back- and forth or buying a new one for them to work on, keep in mind that some failures may require special reflashing procedures/ soldering, etc.)
…keep in mind that OpenWrt is a volunteer project, with zero employees, every developer contributing their own free time - and paying for their own toys (ranging from the actual devices they work on, to all the supporting gear they need - and that's a lot, from soldering equipment to spi-nor flashers, serial- and JTAG, spare flash chips, a whole zoo of measuring equipment, fast computers to actually build stuff regularly, new/ expensive networking cards to keep up, etc. pp.).
So even for just the aforementioned ~230 devices, this is unworkable.
Device support is as good as the developers and irregular contributors can make it to be.
Testing is as good as its regular users keep track of it and keep testing development snapshots.
Documentation is as good as its users keep up with the wiki.
If you want warranties, you'll need to turn to the vendor who received your money already - and maybe make them sign a SLA with you.
--
to be very clear, I'm not an OpenWrt developer or project member, I have no commit rights or other kinds of short circuit access. I'm just a voice in the shadows and volunteering my time to assist keeping the forum civil.
In some respect, I support your opinion. At least, regarding some more detailed classification/documentation of "supported device". Example: For small hotspot systems, I often used the ZBT WE826 to be the workhorse. Reliable, supported, really cheap. However, the WE826 also can be equipped with an LTE modem. And here the fun starts. Having seen "modem hangs" during production usage, this does not really hurt a single install at home, in case, it just happens one a week. Power cycle the router, and everything fine. Now think about remote installation, or volume installs. In case of 7 remote installs, you have the chance to go out once a day for a power cycle. Simple statistics. However, there is a method to eliminate this problem, using programmatic power cycle, which is possible on some other devices. But unfortunately, on the WE826, the pwr (and reset, probably) are hard wired. To save some money, of course. Thus, to use the WE826 with modem is a bit risky. Although supported.
In addition, there are a bunch of devices not listed in the ToH - because nobody cared to create a wiki page. It's not required to do so in order to add support for a device.
Just a few recent examples (granted, snapshot only, but still):
Cudy M1200v1
ZyXEL LTE7490
Longdata APS256
IMHO the following changes could at least improve the situation:
Indication if a device is available to the core developer team and thus has something like "gold support"
Mandatory creation of tech data page if support for a new device is added
To be honest, I did not immediately create tech data pages for all devices I contributed. This should be fixed now, though.
First of all, I completely understand, that amount of devices is no joke. Given we only live 27500 days on average. So hats off. But I also understand the other side of that coin.
Is there a way to connect serial over the net ?
So new devices can be offered e.g. set online by the end-user ?
Because that would shift most of the cost to the end-user
Agreed, but it might have another angle, if its an already supported device, it might make remote support an option. Not saying it should be free though.
unless you live in some parts of Asia, Africa and perhaps South America, where supported hw is hard to find, it'll be cheaper to simply buy a new device.
Like ssh?
Real serial over the network would involve e.g. an esp8266 connecting to serial (open device & soldering) and serving access to another router, possible, but unlikely to become a hit (also consider availability, trust and time zones).
While this might sound great, I'd be wary in practice:
developers come and go, at least in terms of activity - so what use is this label if the developer in question is in a low activity phase (work taking its toll, family, etc.)
developers tend to have many devices, having a device does not equal using it regularly, nor testing it actively - and interests in particular devices may fade slowly/ unnoticed
quite a lot of device additions are not done by formal OpenWrt developers, this does not mean that these devices have a worse support status (often to the contrary, as these irregular contributors might have less other things on their hands and may be more focussed on their smaller set of devices)
most real issue aren't specific to a single device, many devices of a common (sub-)target are somewhat similar, e.g. the relatively unpopular nbg6817 is effectively equivalent to the very popular r7800. Almost all bugs and features apply likewise.
how would these labels reflect the slow shift from RaLink < Atheros ~= QCA < Mediatek (for >= (mt7621 && mt7915)) - and what role are econet and airoha playing
at least to me, such a label also comes with a questionable odor (bribing?)
I feel the further a person is from development in general, and open source development in particular, the more entitlement they have. I find it wild you'd expect flawless support, considering some devices don't work properly even with the manufacturer firmware, that you paid for. And supported is doing a lot of work here. Nobody is trying to mislead you. This is a volunteer-run project, as @slh mentioned: nobody owes it to anybody to support anything. If it brakes, and nobody has interest in fixing it, that's it. You get exactly what you pay for.
If you're not happy with the state of support for some device, you're free to make a PR with improvements. And if somebody has time and interest to look into it, considering you did all the leg work to follow all the unwritten rules, guidelines and general etiquette, and it doesn't look like it will incur unnecessary maintenance burden, it might get it merged. Same goes for any documentation and testing. If your device requires upstream (e.g. kernel) changes, well, good luck with that.
And if you don't have the skills to contribute, at the very least appreciate other people's time and effort they put in for free and don't make undue demands.
I completely agree with your points, it was definitely not completely thought through.
In addition, though, the same can happen for community-supported devices: I for myself contributed support for devices that I used for some time, but replaced them by newer devices and sold the original device. These devices are still listed as supported, but I do not have any means to improve it or to fix things. I always considered this acceptable, as "the community" is now more or less supporting it.
Agreed. Unfortunately, your correct comment is not public knowledge. Where "open source" or"supported" are easily misinterpreted Even with some folk,who should better know. I still remember my head shaking, when many years ago I read about Munich starting to switch from M$ to open source. My comment simply was, they do not know what they are doing.
No one is mentioning the evolution of 'supported' devices.
OpenWrt does not 'support' devices like it is a service.
Someone likes a router and they either know how to work it or they convince a bunch of people to buy it and work on it with them.
Other than one (pardon the pun) exception OpenWrt does not make these routers.
But it is not hard to either ask what is good today (we all know its a moving target, we tolerate the weekly topic "what is best this week") or search and limit the results to recent threads.
The first line seemed to suggest an obligation without the context and understanding of OpenWrt being a project for hobbyists and that leashing them with new 'standards' could very well just be enough to dissuade a new project.
Typically, open-source software displays its status: version and whether it is stable, testing or under development. For example: Linux distros, like Ubuntu, Debian and others. What is really missing here is the status of the given version and the given router.
I know what open-source software involves: unpaid time of volunteers. I don't expect the 2700 devices to work flawlessly. My expectation is to see the status of the device to know in advance whether I could use the device in a home/production environment or this is just a device needing additional work.
On every device's page, there should be information whether the device is still maintained. And it should be verified, let say every few months.
Off-topic
I clearly see, there is a management problem. The more routers you have, the more your effort is watered down and there are more frustrated users. Having 25-50 (perhaps 70-100) fully supported devices is far better than having over 2700 devices with an unknown status. I am not saying, working on other devices should be forbidden, but there should be a way to distinguish working devices with the ones which still require some work.
Also, there could be a better selection process. The step with giving up support with lower specs (8 MB) was a step in the right direction. People more knowledgeable about routers, than me, should create the selection criteria. But they could be like: no support for devices without a USB port, at least 3 Ethernet ports, unlocked firmware upload. If the manufacturer makes trouble to change the firmware, then why to waste time? There also could be the market availability criteria (the UK, the EU, the US, other markets). Another criteria: does the device contain some unusual features or design quirks? I am pretty sure, applying such criteria would quickly and significantly decrease the list size...
Limiting the number of supported devices could speed up the whole process and the overall quality would be better. It would be a far more comfortable position if 5 or 10 volunteers worked on a single device, than when a single device is supported by a 0.375 volunteer a year.
Which distro precisely shows compatibility status between any given version and my specific laptop? I'm particularly interested in the ones that are going to be flawless. And I'm excluding anything completely custom on purpose to make a point.
Same as the above, plus my previous post. And there's a unique opportunity for you to volunteer and solve this. Just pick a few devices and test every conceivable scenario. Don't forget about reg domains, DFS, EEE, DSA, compatibility with different client devices, various upstream hardware, radio emissions, beamforming, working in congested environments, throughput, both wired and wireless, USB and interference, VPN performance, mesh, encryption performance, any and all non-default packages, long term stability of all of the above, and so on, and so forth.
I feel like you are ignoring the whole thread of counter points and arguing with a straw man. I clearly see, either you're being purposefully obtuse, or you genuinely can't grasp why volunteers do what they do and how management is the last thing that is needed: this is not a random corpo where you can barge in and tell people what they should do to show a pretty burn down chart at the end of the sprint.
And I'm flabbergasted, you think you know how to run a ~20 year old project, better than the people who are doing it.
