That's implies your happy to tradeoff security at the cost of additional development resources.
My preference would be to tradeoff functionality and keep security with minimal development effort just individual or community builds.
1 Like
Trade off security in what way? Only the root user is in use, so if it needs to be run locally to be exploitable then the user would already have full access.
I think everyone understands the concept of different versions with different capabilities. The main problem is that some of the available 4/32 firmwares can't do anything because there is not enough space to save the config.
I think nobody here is asking OpenWrt people to do any work nor taking any legal responsibility nor maintaining anything on their repos. So why just asking about what be need to do bothers you?
Because OpenWrt is a project for an open-source secure firmware that abides to the license terms?
You could basically do your research and start a branch, then if you fall behind in security or violate license terms then that affects your branch but keeps the name of OpenWrt clear of that.
There was already a long discussion about 8/32 Should OpenWrt/LEDE support devices with only 4MB Flash? - #263 by richb-hanover-priv, so I don't really why this separate topic was started in the first place.
I imagine if starting a separate topic was to start a fork then you could have clearly mentioned that.
On separate note, some of posts here severely violated the rules, despite the explicit reminder.
4 Likes
I want to second @tatel's thought, and re-focus the discussion.
This topic was forked from the other 4/32 discussion by people who have dozens/hundreds/thousands of low-capacity devices already in use on their service. I know @tatel has a lot of devices; Freifunk folks have thousands; there are probably others in that same boat.
They are primarily concerned with keeping a secure version of OpenWrt working on their hardware. (Please correct me if I'm wrong.)
-
They are very clear that they have "Difficult" hardware. You won't be able to convince them to abandon the hardware: it's already in service at their customer sites.
-
They have limited demands - they don't need new features or higher performance than what they have today.
-
They are not asking us to change the build facility to accommodate their needs. Nor are they even asking for developers spend additional time making mainline builds work better for their hardware.
They are simply looking for advice so they can continue to serve their own community with OpenWrt.
As forum members, please Be Nice (Rule #12) and only comment if your thoughts will aid them toward their goal. Thanks.
5 Likes
Please stop interrupting discussions with extremely vague righteousness speech about essentially nothing.
Freifunk already have their own "fork" (firmware). If they don't want to follow upstream (OpenWrt in this case) that's their own choice. How that is related in terms of development apart from that they're using OpenWrt as far as OpenWrt's development goles and progress goes?
The solution is pretty clear, stay on older branch/release/* and maintain it yourself and/or make a fork.
Make a sticky and close this discussion once and for all?
The problem I think with this topic is it's directly a request for support (in the sense of time spent considering and solving all the vague numerous problems of 4/32). The community here has basically come to the conclusion that spending time on general support of 4/32 is not a good use of time. So I think @diizzy has the right idea:
Now, after having done this, and gotten to the point where things work for you, or are very close to working, and you need a specific answer to a specific question, like "we need package X but it's currently stripped bare and seems to be functioning wrong, do you think patch Y is what we need to make it work again?" then I think that very specific level of question is likely to get some attention here.
I'm not meaning this in a not-nice way at all, I think it would be not nice to ignore you. I just think you need to understand that even the problem of figuring out what is needed is itself a bunch of time and effort that the developers and user-support people here don't want to spend because we see it as not the most valuable thing we can spend our limited time on, and instead we have allocated that time and effort to what we see as more important: make OpenWrt move forward, support current devices, be secure, and offer many good features for those who are willing to spend $20 or more on hardware.
EDIT: one issue is that almost none of us even have 4/32 hardware, and so even just finding out what goes wrong requires purchasing hardware no-one wants to own, and then spending time installing stuff on it, and then figuring out what goes wrong. Since this is exactly the situation you are in, doing the work of trying the installs, and debugging them with a serial console and coming up with stack backtraces and etc etc etc would be the kind of preliminary work that will be required before anyone can even offer advice.
4 Likes
The community clearly has various differing opinions on this issue. In the end its the people who write the code who decide what they want to spend their time on, but anyone can voice their opinions about what they wish for and there is no single right answer. I enjoy getting as much as possible from cheap hardware. That is why I encourage those with 4/32 routers to build their own firmware instead of just telling them to buy a new one, and why I have contributed a fair amount of tips to the wiki page about saving firmware space. I have also written the beginners guide to building your own firmware wiki page so that anyone can be able to do it and not just those with Linux skills. So no, I don't agree that it is not a good use of time.
I think everyone agrees on what goes wrong. The new versions are too large to fit.
2 Likes
But if you do contortions to make it fit, what breaks? Since there are an infinity of possible contortions, asking in the abstract is impossible to answer.
Which is why I think trying to provide vital security fixes to v17 for a while longer would be preferable.
@tatel appears to be in line with this. As long as a given architecture is being maintained in the development and single release branch, then the vast majority of what would be required is present to allow one to build an image for an under-resourced device. I believe that a significant thing to assist in individuals distributing firmware with confidence would be better license management tooling. His questions, at least as I interpret them are reasonable.
@per, on the other hand seems to be making demands that the OpenWrt project maintain a separate branch and builds. His comments appear to be very much off topic, at least as how I understand the definitions of "What" vs. "who".
On one hand he argues how easy it is, yet on the other he refuses to take the responsibility to do so. On one hand he argues
yet fails to see the contradiction that somehow it magically applies to software and not to hardware.
His demands appear to be clearly in contradiction to "They are not asking us to change the build facility to accommodate their needs. Nor are they even asking for developers spend additional time making mainline builds work better for their hardware."
That sure is a lot of straw men. I am not making demands. I don't even have a 4/32 router, so it doesn't really matter to me what happens. I will be using v19 either way. I am just saying what I think would be the best way to solve it. I think it would be more time consuming to try to make a special version of v19 for each 4/32 router in use to make it fit.
I haven't said it's easy, I have only said that it's not necessary to fix as many security issues as some people have claimed for the firmware to be good enough. I am not refusing to do anything, I just don't have the skills. Your allegation about not seeing that different hardware has different capabilities makes no sense. Why would I suggest to keep an older version that still fits fairly well if I didn't?
Yeah, here in the South-American markets it is actually difficult to get much else than TP-Link hardware. Importing networking gear is terribly expensive here. Amazon/Ebay/NewEgg do not ship to here, so you must pay for a service that receives your goods in the US and then sends it to here. That service bases their tariff on size weight and what they think the package is worth.
Then it arrives at customs and they add a tax of what they think the package is worth as well. And no, the value on your receipt has barely any influence on their opinion.
My friend bought a sound bar for under the TV on Amazon. A Yamaha unit, for 130 USD. When it finally arrived an extra 100 USD was slapped on. That is the cold hard reality here.
People have barely any other option than purchase the TP-Link hardware that is on offer here. Sure, from any other standpoint your advice is valid, But here in South America it is just as useful as Santa Claus, unfortunately.
3 Likes
Out of curiosity are any of the common devices actually 4/32 devices?
When I do this search I find that there are quite a few TP-Link devices with 8/64 or better
It is only 4/32 units that you can buy here.
I fully support keeping the support for people to be able to build for devices like 32/8 which are still very popular and with decent performance. Asking people to throw away their 32MB devices and buy one with 64MB it's a bit of "too much" at the present.
In the other hand I understand the severe limitations of 4MB devices (like people neglecting IPv6 to make it fit) and think these cases are difficult to be kept maintained by developers and should be community-only supported otherwise.
But the main point about this topic I consider should be to keep support for 32/8 devices specially given that 18.06 with newer LuCI has NOT been running well on all of these devices. Therefore despite the release of 19.xx soon I believe 17.xx should be kept maintained at least minimally for bug and security fixes and other major important things so it allows these well spread hardware be used for a while.
I also don't think it imposes any work duplication on developers. Major efforts should of course be kept directed to the current versions.
1 Like
Has been discussed in depth in other threads over a period of years now and your thoughts are not in line with reality.
This thread, in fact, is a response to those threads and how the OpenWrt project can support those individuals and groups with a significant investment in devices with less than 8 MB or flash and/or less than 64 MB of memory that have the skills to build their own firmware to be able to do so for a brief while longer,
Maybe we should share here about "optimization" for 4/32 devices. Like Optimized build LEDE 17.01 / OpenWrt 18.06 / libreCMC for "small devices" TP-LINK WR740N(D) WR741N(D) WR743N(D) WR841N/D) All Versions.
Disable IPv6 or remove iptable if this is internal Access Point
1 Like