You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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
DSA migration
--ignore-minor-compat-version
option.Firewall migration
Changes of target names
Changes of disk partitions
DNS servers degradation
Tasks
Falter 1.2.4
Falter 1.3.0
Falter 1.4.0
The text was updated successfully, but these errors were encountered: