New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Building 4MB Images #626
Comments
dropping IPv6-support is really a bad idea, as this is the network-protocol of the time / future. |
there is also freifunk-berlin/buildbot#47 pending |
We could also look into using luasrcdiet to reduce the size of the lua source code. http://luasrcdiet.luaforge.net/ The luci code currently uses this. |
See #283 (comment) Remove/rework qos, then Migration and OWM are tiny and get compressed to almost nothing in the image anyways. |
@sarumpaet The tunnel-berlin-openvpn version we could work around by reimplementing the sven-ola hack on the server side (anybody know where to find this hack?). But I'm not sure how to do that with tunneldigger (but it could surely be possible). I don't think it would be possible with no-tunnel. Additionally, how would it work with OLSRd? The daemon added the following rule on my router (backbone image): |
@SvenRoederer |
Probably olsrd is using netlink directly to setup netfilter-rules. |
@pmelange NAT is set up via fw3, not via iptables (since a long time). See #283 (comment) . |
I just played around a bit with a test router. I successfully removed qos-scripts, iptables, ip6tables, iptables-mod-ipopt, and iptables-mod-conntrack-extra. After reboot, everything seems to be working fine with the uplink (tunneldigger). Then I reconfigued to mesh with the Backbone. This also works fine. I can reach all nodes on the Backbone and also reach the internet. As another test, I set up two nodes, both without the above packages. The non-uplink node properly forwards to the internet trough the uplink node. I find this a viable solution. One thing that surprised me is that when I run I have an issue with simple-tc. Yes, it's in gluon and we could/should use it. But where did it come from? The source code seems to come out of nowhere. It might be better to find the original source. Here is the initial commit in gluon freifunk-gluon/packages@48cddbb#diff-804469766ebbca672fc17773e7f97e67 Also, the copyright states that we need to reproduce it, with all terms and conditions somewhere. Where should the copyright be posted? |
Adding simple-tc to the uplink node was quite painless. The one thing I dislike is that runs via hoplug and doesn't put any log entries out. It would be nice to be able to reload simple-tc by running something (e.g. /etc/init.d/simple-tc restat). Also, it might be a good idea to have it set up with ucitrack to reload itself. |
I have created a branch which uses simple-tc instead of qos-scripts. Here are the changes to firmware-packages The changes to the firmware repo I still have only locally. I can push them if it interests anybody. Here are the packages which should be installed (no-tunnel):
but still it's too big:
The entire buildlog is available (for the first device only) if anyone wants it. How can we get the 4MB images working again? Anyone have any other ideas? |
I just realized that since I used an imagebuilder from another build, I am also pulling in opkg. (I origionally added luci-app-opkg as a dependant of luci-mod-freifunk-ui) That is over 50k that would be saved. I'm going to work on getting this.... |
I have built, but not yet tested the no-tunnel and tunneldigger images. The backbone image is still too big (by 181K). opkg was still in the old 4MB devices. But still, that's not a lot of savings. Should we drop opkg and batman? |
I tried the tunneldigger version of the 4MB image with simple-tc. There isn't enough room leftover to configure the device. |
OLSRd is dependant on iptables |
I assume, we don't need this section at all in our setup |
@pmelange Again, see #283 (comment) . The commit referenced there added NAT for tnl_+ (wildcard!) devices which should cover OLSRd SmartGateway. If it doesn't work (it did back then I think), we could also simply disable SmartGW on 4MB devices (don't quite a few people routinely disable SmartGW anyways as it seems not to be too stable?). |
I think spending time to scrape off more and more just to accommodate a bigger kernel is not time well spent. https://openwrt.org/supported_devices/432_warning I don't plan on submitting the branch to change to simple-tc in the comment above as a PR. |
@pmelange you spoke about interest for support on the ML, but for long time there's no activity. |
**Do not merge until the firmware is based on OpenWRT 19.x** **freifunk-berlin/firmware-packages#158 needs to be merged first** The comment from the upstream commit is: Add a new luci-app-opkg which is a feature-complete replacement for the builtin opkg functionality of luci-mod-system using mostly client side JavaScript to reduce the amount of server side processing. luci-app-opkg is not added to the 4MB devices. See #626 The upstream commit in openwrt/luci is openwrt/luci@aa2e0e2 The freifunk-berlin issue is #621
I think, while it is sustainable, it is also fun to make use of old hardware. And as we know, there is plenty of spare 4/32 routers around. My suggestion for viable 4MB image compilation is -dropping uhttpd and luci Do you think this is feasible? |
@kls0e Feel free to start with such project. I suggest to use lua for the code, so we can refactor common-code to reuse it from the web-wizard. |
@kls0e @Akira25 let me mention the wizard2. As far as I remember, only the backend (https://github.com/freifunk-berlin/firmware-packages/tree/master/utils/freifunk-berlin-wizard-backend) needs to be present on the router and the frontend can run on a separate machine. |
Yes, the new wizard was supposed to open a way to drop uhttpd and luci, among other things. Not sure what's missing to switch over to it at last.
I'm all for supporting 4MB ROM devices, but it's really not as urgent as it used to be. Currently there are less than 50 such devices active; only 32MB RAM will always be a problem; and, if you really want to, replacing the flash chip on these devices is relatively easy and quick to do (replacing the RAM is also possible but much more hassle). But by all means, do play a bit with the source. @kls0e |
At the moment you can consider wizard2 as dead. There was no further development since 2017 and no interest by the community using it. |
I checked the sizes of the binaries and lighttpd seems much larger than uhttpd (and it's dependencies). The depending packages of uhttpd are used by other packages anyway, so it's only the binaries size added to the image. |
@SvenRoederer If all you want to serve is one static HTML file you can as well do @andibraeu I don't quite understand. Clearly there is some interest in the new wizard, visible for example in this thread? I for my part certainly like the idea. The wizard's status, however, is totally unclear to me, i.e., how to get a build with it, what's working, what's not working, what are blockers. |
To be honest, I don't know anymore what would be needed to get it running. The last commit is more than 2 years ago. There were a lot of things missing, e.g. status pages. I think the frontend framework will also be outdated, ... I'm not sure, too, if it works with latest OpenWRT releases. And I don't have time to dig deeper into it. |
@sarumpaet please check branch https://github.com/freifunk-berlin/firmware/commits/lede-wizard, which I kept to show the packages to build the new wizard. This branch should still create correct images (of the past state) |
some Ideas from Freifunk Weimar: https://pretalx.35c3oio.freifunk.space/media/freifunk-4mb.pdf |
The new target ar71xx-tiny (issue #514) and Images "default4MB" too big (issue #314) have not really been resolved. It seems that, from the mailing list, there is still interest in supporting 4MB models.
There has recently been some work on the openwrt and luci repos to make things smaller again (like luci-mod-admin-mini). It might also be possible to remove some other dependencies.
For example, I don't know if we need the following:
kmod-gpio-button-hotplug
luci-app-owm
luci-app-owm-cmd
luci-lib-luaneightbl
Other possibilities are:
Reducing the number of community profiles installed by default on the router
Using luci-theme-openwrt instead of bootstrap (saves 4K)
https://openwrt.org/docs/guide-user/luci/luci.themes
Dropping migration for 4MB devices
freifunk-berlin-migration
No longer having the OLSR status pages
luci-app-olsr
luci-app-olsr-services
olsrd-mod-jsoninfo
Using lighthttp instead of uhttp.
Dropping IPv6 support?
ip6tables
kmod-nf-conntrack6
kmod-nf-ipt6
kmod-nf-reject6
kmod-udptunnel6
odhcpd-ipv6only
libip6tc
I'm sure that if we, as a community, put our heads together, we will come up with a solution.
The text was updated successfully, but these errors were encountered: