freifunk-berlin / falter-builter Goto Github PK

The following packages are not needed in the backbone images:

luci-i18n-ffwizard-falter-de
luci-i18n-ffwizard-falter-en
luci-i18n-falter-policyrouting-de
luci-i18n-falter-policyrouting-en

simply having these packages cause, at a minimum, the following packages to be installed:

falter-policyrouting
luci-app-falter-policyrouting
luci-app-ffwizard-falter

Currently, builter will download the imagebuilder again, everytime we start a build. This doesn't matter for buildbot, but is really inefficient on generating images locally, i.e. development.

sometimes users try to give a OpenWrt-version into the -v option. Then they get strange errors on an empty var, that cannot be tracked easily. Therefore the cmd-parser should check, if the -v parameter is a valid falter-version.

After the 1.2.0-release we got feedback, that 8MB-devices ran out of flash memory and thus weren't able to store changes anymore. We should reduce the packageset to meet that needs.

1. Fast solution would be, to remove some packets from the package-list. Unfortunately this would reduce the pre-installed functions. I'd propose to start with tools like tmux, etc. Users that need those tools could easily reinstall them via opkg.
2. We could implement the function that we spoke of several times: The buildsystem could use a reduced packagelist for the 8MB devices. Thus we remain the useful tools on most devices.

Are there any further suggestions?

@pmelange @spolack @PolynomialDivision

I'm coming to the conclusion that we need a Falter 1.2.4 release before doing an upgrade to OpenWrt 22.03 (Falter 1.3.0) or 23.05 (Falter 1.4.0). The Autoupdater needs to deal with changes of compat-version and target names, which it currently doesn't. These are two easy changes, but they neccessitate a release before the OpenWrt upgrade, if we don't want to lose devices with regard to autoupdates.

I pulled OpenWifiMap data and looked at nodes updated at in July 2024. There are 256 nodes running the 1.2.3 release, most of which probably have the Autoupdater enabled. This number doesn't include BBB-Configs nodes, which show up as 1.x.y-snapshot (~153 nodes). In total there were 736 updated in July.

First a list of the challenges that need our attention, then a list of tasks for 1.2.4, 1.3.0 and 1.4.0 releases.

Challenges

Direct upgrade

• Ideally we'd go from Falter 1.2.3 (OpenWrt 21.02) directly to 1.4.0, skipping over 1.3.0.
• But OpenWrt doesn't officially support skipping a release during upgrades.
• In practice this might not be a problem if we're very careful about the configuration migrations involved. But there's still the risk of undocumented low-level partitioning changes, for example, and other things.
• Gluon works around this by always regenerating the complete config after an upgrade, based on user config. We'd do this based on ffwizard.json.

DSA migration

• Background: https://openwrt.org/releases/21.02/notes-21.02.0#initial_dsa_support
• The configuration syntax changes were already done in Falter 1.2.0: freifunk-berlin/falter-packages#212
• Affected are all devices that have their compat-version bumped from 1.0 to 1.1
  • Relevant for us in 22.03 are lantiq/xrx200 devices (AVM and TP-Link DSL modems)
  • In 23.05 ipq40xx (Mikrotik and newer Fritzboxes), mpc85xx (TL-WDR4900), and mt7622 (BPi-R64)
• Sysupgrade rejects images with a changed compat-version, which means the Autoupdater must be changed to keep supporting these devices.
• Autoupdater needs to use sysupgrade's --ignore-minor-compat-version option.

Firewall migration

• Background: https://openwrt.org/releases/22.03/notes-22.03.0#firewall4_based_on_nftables
• We need to check that all our firewall rules/actions in UCI are still supported, and also look at the few direct iptables invocations.

Changes of target names

• Many of the old Ubiquiti devices have been moved from ath79/generic to the ath79/tiny target. There are also other targets that have been renamed or refactored.
• Right now Autoupdater first looks at the target name and won't find image files if they're now part of a different target.
• Autoupdater needs to look only at the device profile name (e.g. ubnt_nanostation-m), and not at the target name.

Changes of disk partitions

• Ubiquiti Unifi AC Mesh/Lite/Pro got a partition size increase in 23.05, but can be softbricked by an upgrade if the new image is too large to fit into the old partition. A bigger image can only be used after first flashing a smaller image that supports the big partition.
• We need to make sure that images for these devices are small. In a later release they can be big.

DNS servers degradation

• The upstream DNS servers configuren in Falter have deteriorated over the years.
  • as250.net is broken at L105
  • fdn.fr is often overloaded and times out
  • dns2.digitalcourage is deprecated and shouldn't be used in new installations
• It's pretty bad UX and might even fail the Autoupdater.
• In BBB-Configs we're using only Quad9 for the short term, which has high-performance resolvers in Berlin (L105 + AK36) - context freifunk-berlin/bbb-configs#862 (comment)
• We'll get access to more resolvers in Berlin in the future if we implement DNS-over-TLS.

Tasks

Falter 1.2.4

• buildbot: custom imagebuilder for x86/64 which supports running in a VM (for automated testing)
• buildbot: generate release manifest listing all device profiles and image files
• buildbot: remove backbone variant
• autoupdater: pick changes from 1.3.0 branch
• autoupdater: use sysupgrade --ignore-minor-compat-version
• autoupdater: ignore target name, look only for device profile name (use manifest from buildbot)
• dnsmasq: update DNS upstream servers
• ffwizard: add more freifunk config to ffwizard.json (e.g. swapports, policyrouting, community profile, etc.)
• optional: owm: add more info about board, target, autoupdater

Falter 1.3.0

• firewall: fw3->fw4 migration (config rules, direct iptables invocations)

Falter 1.4.0

• build: small images for unifiac-mesh/pro/lite devices (partition migration)
• optional: ffwizard: reconfigure device config after an upgrade, based on ffwizard.json

buildfalter-script generates the repo-address for the images and includes them via the EXTRA_FILES flag of the imagebuilder. Currently, it omits the router-specific part of the repo line.

# add your custom package feeds here
#
# src/gz example_feed_name http://www.example.com/path/to/files
src/gz openwrt_falter http://buildbot.berlin.freifunk.net/buildbot/feed/master

after "master" there should be additional directories, which include the cpu-instructions set.

my bad

should be ./build_falter packageset/19.07/tunneldigger.txt 19.07 ath79 generic glinet_gl-ar150

Currently we can build a target (and all subtargets) or a target and subtarget. Now it would be great if we could generate images for a particular device as well.

If any of the patches that live under patches/ have already been applied upstream then patch will detect it and ask for user input ("Reversed (or previously applied) patch detected! Assume -R? [n]") effectively preventing the build from continuing until that happens. Note that buildbot is not affected by this (presumably because it closes stdin).
Still it would be nice to use patch -f to prevent this. It'd be even better to check whether a patch has been applied already and skip if it has.

There are shellcheck issues in this repo that should be fixed so the shellcheck github action could be merged.

I think it would be great if there were yet another optional argument to build_falter which takes the subtarget (for example, ./build_falter packageset/tunneldigger.txt 19.07.4 mpc85xx generic to avoid having to build the p1020 and p2020 targets.

after building notunnel falter 1.1.1 and flashing it onto an ubiquiti uap pro (still ar71xx) the wizard does not detect the supported mesh modes properly:

...b/lua/luci/model/cbi/freifunk/assistent/wireless.lua:188: attempt to concatenate local 'meshmode' (a nil value)
stack traceback:
	...b/lua/luci/model/cbi/freifunk/assistent/wireless.lua:188: in function 'callback'
	/usr/lib/lua/luci/model/uci.lua:269: in function 'foreach'
	...b/lua/luci/model/cbi/freifunk/assistent/wireless.lua:137: in function 'write'
	...b/lua/luci/model/cbi/freifunk/assistent/wireless.lua:110: in function 'parse'
	/usr/lib/lua/luci/cbi.lua:248: in function 'parse'
	/usr/lib/lua/luci/cbi.lua:248: in function 'parse'
	/usr/lib/lua/luci/cbi.lua:713: in function 'parse'
	/usr/lib/lua/luci/dispatcher.lua:1491: in function '_form'
	/usr/lib/lua/luci/dispatcher.lua:1026: in function 'dispatch'
	/usr/lib/lua/luci/dispatcher.lua:478: in function </usr/lib/lua/luci/dispatcher.lua:477>

Should the backbone images have the package falter-berlin-tunneldigger? There could possibly be backbone nodes which use bbbdigger, but upon upgrading will no longer be able to connect to the bbb-vpn. Also, there could be nodes which use tunneldigger for the client data, which would cause an update to make the no longer work.

Any opinions?

• Rename master-branch to main
• Set appropriate branch protection

This was decided on the community day February 2024

Currently, the master branch version of footer.htm is downloaded and used. Even though this currently doesn't have any ramification, it may some time in the future. Changing to a URL generated based on the luci used in the generation of the firmware images would be better.

I just have built the whole 19.07.5 ath79 target for future use and when I run builter again to build a certain snapshot image, /firmwares is wiped. This might only be expected behavior to some of us.

To enable the possibility to do some rapid prototyping, it would be really beneficial if a local repo of falter packages could be used.

Perhaps this idea could be extended to allow local repositories of packages from any source.

Packagelists schould be based on the falter-version instead of the OpenWrt-Version. On the mailinglist there got someone a problem, because the packagelist contained packages for a future falter-release which weren't in the current stable. This should be avoided by having lists by version.

https://lists.berlin.freifunk.net/pipermail/berlin/2022-March/052925.html

In order to be able to support upgrading a node which also happens to be connected to the bbbdigger vpn server, the package falter-berlin-tunneldigger needs to be installed. Please add to the package set.

Hey,
since we compile batman, can we please disable it by default?
It is a kernel module, or? I do not want unnecessary cpu load and network load.
Or is that no problem? Further, it could be some security issue, if we span a layer2 over a layer3, if we do not be careful.

I believe that with a script we have the ability to change the default ip address assigned to the lan ports from 192.168.1.1 to 192.168.42.1.

The file which is used to determine the default IP address is /bin/config_generate

we would need to swap line number 103 from

lan) ipad=${ipaddr:-"192.168.1.1"} ;;

to

lan) ipad=${ipaddr:-"192.168.42.1"} ;;

It would be great if the filesname were something like:

freifunk-berlin-falter-v1.1.0-mpc85xx-generic-tl-wdr4900-squashfs-sysupgrade.bin
freifunk-berlin-falter-snapshot-mpc85xx-generic-tl-wdr4900-squashfs-sysupgrade.bin

or

freifunk-berlin-falter-v1.1.0-v19.07.4-mpc85xx-generic-tl-wdr4900-squashfs-sysupgrade.bin
freifunk-berlin-falter-snapshot-snapshot-mpc85xx-generic-tl-wdr4900-squashfs-sysupgrade.bin

During the build-process, the imagebuilder pulls every package, that isn't contained in its self. As we call the same imagebuilder multiple times to build whole target, we download the same packages a lot.

It would decrease buildtime by magnitudes, if we somehow cache the packages locally.

This package is missing from notunnel and backbone. Please add

Devices with only 8MiB flash get more often problems with full flash. We should have a reduced packagelist for them, without i.e.

• tmux
• vnstat
• iperf3
• etc

The buildsystem should automatically detect an 8MiB-Device and omit these packages.

The Falter image generation for beta images should include setting the version string to, for example, 1.1.0-beta5

The upstream commit is:

master: openwrt/luci@d4092b1
21.02: openwrt/luci@e1ccb66
19.07: openwrt/luci@8bd4e78

With this version of modules/luci-base/htdocs/luci-static/resources/network.js when wifi settings are changed, the network configuration no longer gets set incorrectly.

This will require a script similar to modules/luci-base/htdocs/luci-static/resources/network.js

The Readme file needs to be updated. The examplestatement is still using -s generic although it has been removed.

The package lists for snapshot images need to be changed. currently libustream-mbedtls is listed, but fails when making snapshot images.

Maybe it makes sense to have package lists per release target (a subdir for 19.07 and a subdir for snapshot).

So it can be the obvious central place for firmware discussion, which was previously the firmware repo.

OpenWrt 19.07 still has SimultanousMultiProcessing disabled (think OpenWrt 21.02 too),

openwrt/openwrt#3946

this affects: FritzBox 7320/30, 7312.. which have a ~2x400MHz 34Kc CPU.
-> see:https://openwrt.org/docs/techref/hardware/soc/soc.lantiq -> ARX100 "AR9"

In single core mode boxes are pretty slow.
Dual core mode custom builds of OpenWrt 19.07.x / Freifunk Berlin Firmware are working:
-> see: https://wiki.freifunk-cottbus.de/firmware:downloads

workaround:

• wait till openwrt/openwrt#3946 gets merged and backported
• build (SvenRoederer) Freifunk Berlin Firmware + SMP enabled kernel -> https://github.com/SvenRoederer/freifunk-berlin-firmware
• #65 build custom Openwrt-imagebuilder (SMP enabled kernel) and use it for Freifunk-Spalter

It took me a while to notice that weird things are happening because I didn't have patch installed :-) Would be really good to have some sort of error reporting, otherwise I have to 1) notice something is wrong in the first place, and 2) scan the long output for error messages.

I understand set -e is disabled because we do want to ignore some errors from the imagebuilder. Maybe a useful compromise would be to disable set -e only for the imagebuilder call?

Currently, image-generation does not work at target x86. Probably this results in the different structure of x86-imagebuilders from those for regular targets.

For development/adding "new" boxes its sometimes necessary to alter kernel options:

• for example lantiq:xrx200 (O²Box6431) in: /openwrt/target/linux/lantiq/files-4.14/arch/mips/boot/dts/VGV7510KW22.dtsi -> bootargs -> remove: mem=62M vpe1_load_addr=0x83e00000 vpe1_mem=2M maxvpes=1 maxtcs=1 nosmp to enable SMP
• or add/remove kernel modules/packages -> make kernel_menuconfig
• or #64 Openwrt 19.07: lantiq: ar9: xway: kernel: enable SMP support

to get them to working / desired state.

Would be a great benefit for development/testing of Freifunk firmwares, due upstream changes in OpenWrt sometimes get added pretty slow (missing reviews) or are even stalled.

As discussed in freifunk-berlin/falter-packages#344, there might be a new structure for the package feeds. If we do it that way, builter would be needed to adjusted accordingly.

similar to freifunk-berlin/falter-repo_builder#7

There are currently a few PR's in the packages repo which are designed to help steer how the feeds and images are built. In the package "falter-common" the file ./etc/freifunk_release has the variable FREIFUNK_OPENWRT_BASE which can (as of this point in time) the following values:

• 19.07.6
• 19.07.7
• 19.07-SNAPSHOT
• 21.02-SNAPSHOT
• master

These refer directly to the directories on downloads.openwrt.org. In all cases except "master", the files will be found in the "releases" directory. For master, the files will be found in the "snapshots" directoy.

This way, things like -p packageset could be just "tunneldigger" and -v version would no longer be needed.

The following bit of code would probably be better placed somewhere more global in the script.
https://github.com/Freifunk-Spalter/builter/blob/2f713292f3ed2f667b41bf8a4b65d6a3708321ac/build_falter#L268-L271

As discussed at #140, OpenWrt is ratelimiting the dump of ToH, resulting in broken builds.

As a fix, we introduced to host the ToH ourself.

As soon, as we found an upstream solution for this, we want to switch back to the upstream-only ToH.