search

freifunk-berlin / firmware

DEPRECATED: Build system for Berlin firmware. Please user the pinned falter-repos instead
https://berlin.freifunk.net
GNU General Public License v3.0
73 stars 34 forks source link

Using prebuilt OpenWRT stable releases for our Firmware #774

Closed db4rne closed 4 years ago

db4rne commented 4 years ago

I would like to discuss the idea of using prebuilt OpenWRT for our own firmware base instead of building everything ourselves. This ticket is a basis for a discussion, so please discuss.

expected benefit

expected downsides

similar projects doing "it"

open questions to discuss:

pmelange commented 4 years ago

I think this would be great. I will take a better look at the patches and try to figure out if there is a way to get rid of them all

pmelange commented 4 years ago

List of patches in master

~/src/firmware/patches$ find
.
./openwrt
./openwrt/0001-tools-mkimake-fix-handling-of-long-pathnames.patch
./openwrt/1800-mbedtls-accept-rsa-1024.patch
./openwrt/0003-patches-enable-sysupgrade-u-by-default.patch
./openwrt/1001-mac80211_mesh_no_fwding_by_default.patch
./openwrt/1005-hostapd_nolegacy_by_default.patch
./openwrt/1004-openwrt-release_use_configured_revision.patch
./openwrt/0002-tools-u-boot-enlage-max-pathlength-for-mkimage.patch
./openwrt/0004-avoid-underscore-in-6lowpan-package-names.patch
./openwrt/1600-imagebuilder-custom-postinst-script.patch
./openwrt/1700-banner-info.patch
./packages
./packages/luci
./packages/luci/0201-wifi_no_meshfwding_by_default.patch
./packages/luci/0202-split-luci-base_PR2817.patch
./packages/luci/0200-wifi_nolegacy_rates_by_default.patch
./packages/freifunk
./packages/freifunk/0704-policyrouting_ignore_ffuplink.patch
./packages/freifunk/0703-policyrouting_fix_bypass-vpn.patch
./packages/freifunk/0701-luci-freifunk-policyrouting-berlin.patch
./PATCHES.rst

./openwrt/0001-tools-mkimake-fix-handling-of-long-pathnames.patch

This patch is in itself a patch (a patch which makes a patch) to u-boot to support longer command lines. It may be that we need this patch when building from scratch, but if we switch to using the upstream imagebuilder, we may no longer need it.

./openwrt/1800-mbedtls-accept-rsa-1024.patch

This is a patch to mbedtls to make it possible to connect to the old bbb-vpn (based on OpenWRT). But since mbedtls hasn't been working on all platforms, mbedtls is not being used, and instead openssl. Additionally, since the old bbb-vpn server is scheduled to be decomissioned, then this patch is even more so not needed.

./openwrt/0003-patches-enable-sysupgrade-u-by-default.patch

This patch changes the default behaviour of sysupgrade, forcing the newly created -u option. The reason for this change is because as changes are made to the profiles, and especially /etc/config/freifunk, they aren't incorporated because the sysupgrade backup overwrites any new files with the old ones. This creates an upgrade headache.

It is important to note that this patch does not address the issue that changes to the profiles in /etc/config/freifunk will still not be pulled in from upstream, as router-specific settings are stored within.

My proposal is to move the profiles out of /etc/config and into a new folder which is not tracked by sysupgrade, such as /etc/freifunk/profiles. The scripts would need to be changed to match the new location, but in the end, this patch will no longer be necessary. Additionally, /etc/config/freifunk will only store the router-specific setting while /etc/freifunk/profiles/freifunk would always have the up-to-date upstream changes.

./openwrt/1001-mac80211_mesh_no_fwding_by_default.patch

I do not think this patch is necessary. It is only there to prevent users from making a mistake when manually adding an 802.11s mesh interface. I think it breaks the expected behaviour and makes the underlying openwrt documentation incorrect.

./openwrt/1005-hostapd_nolegacy_by_default.patch

This again is a case where the default behaviour of openwrt is different from our implementation. Instead of having this value in /etc/config/wireless, it is hidden away from the user, possibly causing unexpected results.

./openwrt/1004-openwrt-release_use_configured_revision.patch

In this patch, we use %C instead of %R in defining the distribution revision. %R is the "Repository revision ID" while %C is the "Configured release revision code or value of %R, uppercase". I'm not absolutely sure where DISTRIB_REVISION is used in the code, but DISTRIB_DESCRIPTION still uses the value of %C.

The OWM script uses DISTRIB_REVISION. Maybe we can just update the script instead of using the patch.

./openwrt/0002-tools-u-boot-enlage-max-pathlength-for-mkimage.patch

See ./openwrt/0001-tools-mkimake-fix-handling-of-long-pathnames.patch above.

./openwrt/0004-avoid-underscore-in-6lowpan-package-names.patch

This has been integrated upstream in commit (only in master branch) https://github.com/openwrt/openwrt/commit/07e1d88d7beb43a4152460b82976dbe49919b264

Maybe we can try to get it merged into the 19.x branch

./openwrt/1600-imagebuilder-custom-postinst-script.patch

This adds code for a CUSTOM_POSTINST_SCRIPT. It is used in the assemble_firmware.sh script. Maybe there is another way to do this than to use a patch.

./openwrt/1700-banner-info.patch

This modifies the /etc/banner file to have the Freifunk ascii art. It might be better to use the build system as described here: https://openwrt.org/docs/guide-developer/build-system/use-buildsystem#custom_files

./packages/luci/0201-wifi_no_meshfwding_by_default.patch

see ./openwrt/1001-mac80211_mesh_no_fwding_by_default.patch above

./packages/luci/0202-split-luci-base_PR2817.patch

Note, this is only really needed for 4MB devices, which in general are at their EOL. But anyhow, hopefully https://github.com/openwrt/luci/pull/2817 can be merged, resolving the need for this patch.

./packages/luci/0200-wifi_nolegacy_rates_by_default.patch

See ./openwrt/1005-hostapd_nolegacy_by_default.patch

./packages/freifunk/0704-policyrouting_ignore_ffuplink.patch

Maybe we can fix this upstream, thus making this patch unneeded.

./packages/freifunk/0703-policyrouting_fix_bypass-vpn.patch

See ./packages/freifunk/0704-policyrouting_ignore_ffuplink.patch

./packages/freifunk/0701-luci-freifunk-policyrouting-berlin.patch

Perhaps it is better to have a freifunk-berlin specific policyrouting script instead of patching the upstream freifunk script. This would also resolve ./packages/freifunk/0704-policyrouting_ignore_ffuplink.patch and ./packages/freifunk/0703-policyrouting_fix_bypass-vpn.patch

This has only been a quick overview of the patches. I haven't tested anything. There may be mistakes in my assumptions. If so, please mention them.

sarumpaet commented 4 years ago

1600-imagebuilder-custom-postinst-script was handy for deleting unneeded stuff in a quick and maintainable way for 4MB routers. It might be handy again for other things, but something like that should really be/go upstream (it was actually taken from the OpenWrt FAQ...).

There's also https://github.com/freifunk-berlin/firmware/blob/Hedy-1.0.x/patches/001-rt2x00_allow_adhoc_and_ap.patch (without that, Nexxx WT3020 support will be broken I think) but that should go upstream as well.

SvenRoederer commented 4 years ago

just two examples for useful patches:

As @bobster-galore once said: OpenWrt is not Freifunk-Berlin, so their mainstream decisions are not the best for our needs.

sarumpaet commented 4 years ago

One pro side came up in the discussion today: OpenWrt releases include a lot of obscure platforms that we have disabled to speed up our builds. We'd gain support for these platforms without needing to change our build config (or add buildbot targets).

znrR commented 4 years ago

In the meeting on 7.4. we (@db4rne @pmelange @SvenRoederer @Akira25 @znrR @xa-y-ax @sarumpaet )could not agree on if we want to switch to prebuilt OpenWRT or not.

We decided to leave it open for now and discuss further benefits / drawbacks here and want to possible solutions / compromises. We will have a look at the status of that issue in the next meeting.

SvenRoederer commented 4 years ago

There was the argument to use the tools-packages (packages, luci, routing, telephony-feed) compiled by OpenWrt-team. As our releases are based on OpenWrt-stable releases, the user can simply add the OpenWrt-sources and use these packages directly.

SvenRoederer commented 4 years ago

Another situation where building from scratch (at least SDK and imagebuilder): https://github.com/freifunk-berlin/firmware/issues/780#issuecomment-611797593 is handy.

db4rne commented 4 years ago

Another situation where building from scratch (at least SDK and imagebuilder): #780 (comment) is handy.

Let me explain why I disagree: If we would be building from an Imagebuilder-base, there would be nothing stopping pmelange from just building the thing, and then use that imagebuilder instead of, e.g. the snapshot one (in case stable has some assumption that wont work). I don't see how either method to build our firmware should be easier or harder here to do some customization.

SvenRoederer commented 4 years ago

It will be hard to reproduce / to build the imagebuilder that pmelange created himself from some source. Just starting from an precompiled imagebuilder will remove the chance to rebuild with the exact same souce, that was used when creating the imagebuilder.

db4rne commented 4 years ago

I don't understand your point here. What would be so hard about: "I built git repo x, branch y"? I also don't know why you would even need that info? I think we shouldn't include half-done stuff into the firmware at all, so why is it necessary to support something that doesn't even work fully in openwrt yet?

booo commented 4 years ago

The current build process is ridiculous. On every little change we build the toolchain, the SDK, the imagebuilder and then a few images.

We should only build the toolchain if we make changes to the toolchain. Same is true for all the other stuff. Every build step on the build bot can create an artifact e.g. the imagebuilder tar.gz and the next step can consume this artifact. @SvenRoederer added this functionality for the image builder. No we need functionality for the other stuff.

As a first step I suggest you look into building the packages with the SDK. That should be quite easy.

SvenRoederer commented 4 years ago

There have been some discussions on splitting the buildprocess some time ago. As @booo mentioned there are the 4 phases of our build-process:

  1. toolchain (Compiler, libc, kernel, initrd-images)
  2. sdk (binary packages)
  3. imagebuilder (packages kernel and binary packages)
  4. firmware-images build (combining the binaries with the imagebuilder into final sysupgrade.bin and factory.bin)

Currently we can use any prebuilt imagebuilder to generate the final images. In https://github.com/freifunk-berlin/firmware/issues/760#issuecomment-578552989 is a suggestion to setup an prebuilt SDK and use that for building the package-binaries. As seen in the listing above, relying on upstream SDK and imagebuilder will take us the chances to patch the kernel (for additional hardware, individual settings, quick fixes which have not caused an upstream release). So the only missing part is using a prebuilt Toolchain, OpenWrt seems no to provide this. So have to decide:

Based on this decision we can see if need our toolchain or can just start using some SDK.

pmelange commented 4 years ago

Another situation where building from scratch (at least SDK and imagebuilder): #780 (comment) is handy.

I think that being able to prototype is still important, but not for our releases. And for sure, using the SDK provided by our friends at OpenWRT is useful in 99.999% of the cases.

It will be hard to reproduce / to build the imagebuilder that pmelange created himself from some source. Just starting from an precompiled imagebuilder will remove the chance to rebuild with the exact same souce, that was used when creating the imagebuilder.

Reproducibility while prototyping is absolutely not important and is anyhow unreliable. For example, the case described in #780 will never be reproducible because the branch has, after my first test, been rebased/force-pushed. This is also an issue with our own devel branches, which are often rebased/force-pushed.

SvenRoederer commented 4 years ago

I don't understand your point here. What would be so hard about: "I built git repo x, branch y"?

Relying on individually built toolchains, sdks, imagebuilders will remove any chance to ensure the firmware is based on the code that is public avail (on or repo or OpenWrt-repo). So the individual creator might have added accidentally some security issue or even backdoor, which can not be verified by public review.

I also don't know why you would even need that info?

At the end it's mostly about public review and proving the binary is based on the relating source.

I think we shouldn't include half-done stuff into the firmware at all, so why is it necessary to support something that doesn't even work fully in openwrt yet?

Without using "half-done stuff" there still would be no release of our firmware which supports the Ubiquiti ERx-SFP boards. V1.0.x still relies on a patch for Lede-17.01 (https://github.com/freifunk-berlin/firmware/tree/v1.0.5/patches). Same for upstream changes: sometimes to take a lot of time to get things integrated that working for us. As it's not a top-prio for OpenWrt (https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=b81cee86e63d4421072839ec8a3780d8afff9337 took > 6 months)

znrR commented 4 years ago

closed for now, @db4rne picks the topics up at a later point if relevant