.github/filters.yml

@@ -17,6 +17,16 @@
     "targets/generic",
     "targets/targets.mk"
   ],
+  "ath79-mikrotik": [
+    "targets/ath79-mikrotik",
+    "modules",
+    "Makefile",
+    "patches/**",
+    "scripts/**",
+    "targets/generic",
+    "targets/targets.mk",
+    "targets/mikrotik.inc"
+  ],
   "bcm27xx-bcm2708": [
     "targets/bcm27xx-bcm2708",
     "modules",

.github/workflows/backport.yml

@@ -12,7 +12,7 @@ jobs:
         with:
           ref: ${{ github.event.pull_request.head.sha }}
       - name: Create backport PRs
-        uses: zeebe-io/backport-action@v0.0.7
+        uses: zeebe-io/backport-action@v0.0.8
         with:
           # Config README: https://github.com/zeebe-io/backport-action#backport-action
           github_token: ${{ secrets.GITHUB_TOKEN }}

.luacheckrc

@@ -25,6 +25,7 @@ files["package/**/check_site.lua"] = {
 		"extend",
 		"in_domain",
 		"in_site",
+		"value",
 		"need",
 		"need_alphanumeric_key",
 		"need_array",

contrib/ci/minimal-site/site.conf

@@ -93,7 +93,6 @@
 
   mesh_vpn = {
     -- enabled = true,
-    mtu = 1312,
 
     fastd = {
       -- Refer to https://fastd.readthedocs.io/en/latest/ to better understand
@@ -101,6 +100,7 @@
 
       -- List of crypto-methods to use.
       methods = {'salsa2012+umac'},
+      mtu = 1312,
       -- configurable = true,
       -- syslog_level = 'warn',
 
@@ -145,7 +145,7 @@
         -- Have multiple maintainers sign your build and only
         -- accept it when a sufficient number of them have
         -- signed it.
-        good_signatures = 2,
+        good_signatures = 0,
 
         -- List of public keys of maintainers.
         pubkeys = {

contrib/push_pkg.sh

@@ -127,7 +127,7 @@ while [ $# -gt 0 ]; do
 
 		# shellcheck disable=SC2029
 		if [ -n "$filename" ]; then
-			scp -P "${ssh_port}" "$feed/$filename" "root@${BL}${ssh_host}${BR}:/tmp/${filename}"
+			scp -O -P "${ssh_port}" "$feed/$filename" "root@${BL}${ssh_host}${BR}:/tmp/${filename}"
 			ssh -p "${ssh_port}" "root@${ssh_host}" "
 				set -e
 				echo Running opkg:

docs/conf.py

@@ -58,7 +58,7 @@ master_doc = 'index'
 #
 # This is also used if you do content translation via gettext catalogs.
 # Usually you set "language" from the command line for these cases.
-language = None
+language = 'en'
 
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.

docs/features/vpn.rst

@@ -33,12 +33,12 @@ no security.
 Tunneldigger's primary drawback is the lack of IPv6 support.
 It also provides less configurability than fastd.
 
-mesh-vpn-wireguard (experimental)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+mesh-vpn-wireguard
+~~~~~~~~~~~~~~~~~~
 
-Wireguard is a new tunneling software that offers modern encryption
-methods and is implemented in the kernel, resulting in high throughput.
-It is implemented in Gluon using the *wgpeerselector* tool.
+WireGuard is an encrypted in-kernel tunneling protocol that
+provides encrypted transmission and at the same time offers
+high throughput.
 
 fastd
 ^^^^^
@@ -119,3 +119,50 @@ The resulting firmware will allow users to choose between secure (encrypted) and
 
 To confirm whether the correct cipher is being used, the log output
 of fastd can be checked using ``logread``.
+
+WireGuard
+^^^^^^^^^
+
+In order to support WireGuard in Gluon, a few technologies are glued together.
+
+**VXLAN:** As Gluon typically relies on batman-adv, the Mesh VPN has to provide
+OSI Layer 2 transport. But WireGuard is an OSI Layer 3 tunneling protocol, so
+additional technology is necessary here. For this, we use VXLAN. In short, VXLAN
+is a well-known technology to encapsulate ethernet packages into IP packages.
+You can think of it as kind of similar to VLAN, but on a different layer. Here,
+we use VXLAN to transport batman-adv traffic over WireGuard.
+
+**wgpeerselector**: To connect all gluon nodes to each other, it is common to
+create a topology where each gluon node is connected to one of the available
+gateways via Mesh VPN respectively. To achieve this, the gluon node should be
+able to select a random gateway to connect to. But such "random selection of a
+peer" is not implemented in WireGuard by default. WireGuard only knows static
+peers. Therefore the *wgpeerselector* has been developed. It randomly selects a
+gateway, tries to establish a connection, and if it fails, tries to connect
+to the next gateway. This approach has several advantages, such as load
+balancing VPN connection attempts and avoiding problems with offline gateways.
+More information about the wgpeerselector and its algorithm can be found
+`here <https://github.com/freifunk-gluon/packages/blob/master/net/wgpeerselector/README.md>`__.
+
+On the gluon node both VXLAN and the wgpeerselector are well integrated and no
+explicit configuation of those tools is necessary, once the general WireGuard
+support has been configured.
+
+Attention must by paid to time synchronization. As WireGuard
+performs checks on timestamps in order to avoid replay attacks, time must
+be synchronized before the Mesh VPN connection is established. This means that
+the NTP servers specified in your site.conf must be publicly available (and not
+only through the mesh). Be aware that if you fail this, you may not directly see
+negative effects. Only when a previously connected node reboots the effect
+comes into play, as the gateway still knows about the old timestamp of the gluon
+node.
+
+Gateway / Supernode Configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+On the gateway side, a software called *wireguard-vxlan-glue* is necessary. It
+is a small daemon that dynamically adds and removes forwarding rules for VXLAN
+interfaces, so traffic is sent correctly into the WireGuard interface. Thereby
+the forwarding rules are only installed if a client is connected, so
+unnecessary traffic in the kernel is avoided. The source can be found
+`here <https://github.com/freifunkh/wireguard-vxlan-glue/>`__.

docs/index.rst

@@ -14,6 +14,7 @@ Several Freifunk communities in Germany use Gluon as the foundation of their Fre
    user/supported_devices
    user/x86
    user/faq
+   user/mtu
 
 .. toctree::
    :caption: Features

docs/multidomain-site-example/site.conf

@@ -20,10 +20,10 @@
   },
 
   mesh_vpn = {
-    mtu = 1312,
 
     fastd = {
       methods = {'salsa2012+umac'},
+      mtu = 1312,
     },
 
     bandwidth_limit = {

docs/site-example/site.conf

@@ -105,7 +105,6 @@
 
   mesh_vpn = {
     -- enabled = true,
-    mtu = 1312,
 
     fastd = {
       -- Refer to https://fastd.readthedocs.io/en/latest/ to better understand
@@ -113,6 +112,7 @@
 
       -- List of crypto-methods to use.
       methods = {'salsa2012+umac'},
+      mtu = 1312,
       -- configurable = true,
       -- syslog_level = 'warn',
 

docs/user/faq.rst

@@ -25,84 +25,3 @@ interface. This DNS server must be announced in router advertisements (using
 on *batman-adv*. If your mesh does not have global IPv6 connectivity, you can setup
 your *radvd* not to announce a default route by setting the *default lifetime* to 0;
 in this case, the *radvd* is only used to announce the DNS server.
-
-.. _faq-mtu:
-
-What is a good MTU on the mesh-vpn?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Setting the MTU on the transport interface requires careful consideration, as
-setting it too low will cause excessive fragmentation and setting it too high
-may leave peers with a broken tunnel due to packet loss.
-
-Consider these key values:
-
-- Payload: Allow for the transport of IPv6 packets, by adhering to the minimum MTU
-  of 1280 Byte specified in RFC 2460
-  - and configure `MSS clamping`_ accordingly,
-  - and announce your link MTU via Router Advertisements and DHCP
-
-  .. _MSS clamping: https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-mss.html
-
-- Encapsulation: Account for the overhead created by the configured mesh protocol
-  encapsulating the payload, which is up to 32 Byte (14 Byte Ethernet + 18 Byte
-  batadv).
-
-- PMTU: What MTU does the path between your gateway and each of its peers support?
-
-For reference, the complete MTU stack looks like this:
-
-.. image:: mtu-diagram_v5.png
-
-Minimum MTU
------------
-
-Calculate the minimum transport MTU by adding the encapsulation overhead to the
-minimum payload MTU required. This is the lowest recommended value, since going
-lower would cause unnecessary fragmentation for clients which respect the announced
-link MTU.
-
-Example: Our network currently uses batman-adv v15, it therefore requires up
-to 32 Bytes of encapsulation overhead on top of the minimal link MTU required for
-transporting IPv6.::
-
-  \        1312              1294          1280                                 0
-   \---------+-----------------+-------------+----------------------------------+
-    \TAP     |    batadv v15   |   Ethernet  |            Payload               |
-     \-------+-----------------+-------------+----------------------------------+
-      \      ^
-             |
-
-          MTU_LOW = 1280 Byte + 14 Byte + 18 Byte = 1312 Byte
-
-Maximum MTU
------------
-
-Calculating the maximum transport MTU is interesting, because it increases the
-throughput, by allowing larger payloads to be transported, but also more difficult
-as you have to take into account the tunneling overhead and each peers PMTU, which
-varies between providers.
-The underlying reasons are mostly PPPoE, Tunneling and IPv6 transition technologies
-like DS-Lite.
-
-Example: The peer with the smallest MTU on your network is behind DS-Lite and can
-transport IPv4 packets up to 1436 Bytes in size. Your tunnel uses IPv4 (20 Byte),
-UDP (8 Byte), Fastd (24 byte) and you require TAP (14 Byte) for Layer 2 (Ethernet)
-Tunneling.::
-
-  1436                1416     1408                    1384          1370    \
-    +-------------------+--------+-----------------------+-------------+------\
-    |        IP         |  UDP   |         Fastd         |     TAP     |    bat\
-    +-------------------+--------+-----------------------+-------------+--------\
-                                                                       ^         \
-                                                                       |
-
-       MTU_HIGH = 1436 Byte - 20 Byte - 8 Byte - 24 Byte - 14 Byte = 1370 Byte
-
-Conclusion
-----------
-
-Determining the maximum MTU can be a tedious process, especially since the PMTU
-of peers could change at any time. The general recommendation for maximized
-compatibility is therefore the minimum MTU of 1312 Byte, which works well with
-both IPv4 and IPv6.

docs/user/mtu.rst

+MTU for Mesh-VPN
+================
+
+What is a good MTU on the mesh-vpn?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Setting the MTU on the transport interface requires careful consideration, as
+setting it too low will cause excessive fragmentation and setting it too high
+may leave peers with a broken tunnel due to packet loss.
+
+Consider these key values:
+
+- Payload: Allow for the transport of IPv6 packets, by adhering to the minimum MTU
+  of 1280 Byte specified in RFC 2460
+  - and configure `MSS clamping`_ accordingly,
+  - and announce your link MTU via Router Advertisements and DHCP
+
+  .. _MSS clamping: https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-mss.html
+
+- Encapsulation: Account for the overhead created by the configured mesh protocol
+  encapsulating the payload, which is up to 32 Byte (14 Byte Ethernet + 18 Byte
+  batadv).
+
+- PMTU: What MTU does the path between your gateway and each of its peers support?
+
+For reference, the complete MTU stack looks like this:
+
+.. image:: mtu-diagram_v5.png
+
+Example for Minimum MTU
+-----------------------
+
+Calculate the minimum transport MTU by adding the encapsulation overhead to the
+minimum payload MTU required. This is the lowest recommended value, since going
+lower would cause unnecessary fragmentation for clients which respect the announced
+link MTU.
+
+Example: Our network currently uses batman-adv v15, it therefore requires up
+to 32 Bytes of encapsulation overhead on top of the minimal link MTU required for
+transporting IPv6.::
+
+  \        1312              1294          1280                                 0
+   \---------+-----------------+-------------+----------------------------------+
+    \TAP     |    batadv v15   |   Ethernet  |            Payload               |
+     \-------+-----------------+-------------+----------------------------------+
+      \      ^
+             |
+
+          MTU_LOW = 1280 Byte + 14 Byte + 18 Byte = 1312 Byte
+
+Example for Maximum MTU
+-----------------------
+
+Calculating the maximum transport MTU is interesting, because it increases the
+throughput, by allowing larger payloads to be transported, but also more difficult
+as you have to take into account the tunneling overhead and each peers PMTU, which
+varies between providers.
+The underlying reasons are mostly PPPoE, Tunneling and IPv6 transition technologies
+like DS-Lite.
+
+Example: The peer with the smallest MTU on your network is behind DS-Lite and can
+transport IPv4 packets up to 1436 Bytes in size. Your tunnel uses IPv4 (20 Byte),
+UDP (8 Byte), Fastd (24 byte) and you require TAP (14 Byte) for Layer 2 (Ethernet)
+Tunneling.::
+
+  1436                1416     1408                    1384          1370    \
+    +-------------------+--------+-----------------------+-------------+------\
+    |        IP         |  UDP   |         Fastd         |     TAP     |    bat\
+    +-------------------+--------+-----------------------+-------------+--------\
+                                                                       ^         \
+                                                                       |
+
+       MTU_HIGH = 1436 Byte - 20 Byte - 8 Byte - 24 Byte - 14 Byte = 1370 Byte
+
+
+Tables for Different VPN Providers
+----------------------------------
+
+VPN Protocol Overhead (IPv4)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Overhead of the VPN protocol layers in bytes on top of an Ethernet frame.
+
++----------+-------+--------------+-----------+
+|          | fastd | Tunneldigger | Wireguard |
++==========+=======+==============+===========+
+| IPv4     | 20    | 20           | 20        |
++----------+-------+--------------+-----------+
+| UDP      | 8     | 8            | 8         |
++----------+-------+--------------+-----------+
+| Protocol | 24    | 8            | 32        |
++----------+-------+--------------+-----------+
+| TAP      | 14    | 14           | /         |
++----------+-------+--------------+-----------+
+| Sum      | 66    | 50           | 60        |
++----------+-------+--------------+-----------+
+
+Intermediate Layer Overhead
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Overhead of additional layers on top of the VPN packet needed for different VPN
+providers.
+
++------------+-------+--------------+-----------+
+|            | fastd | Tunneldigger | Wireguard |
++============+=======+==============+===========+
+| IPv6       | /     | /            | 40        |
++------------+-------+--------------+-----------+
+| vxlan      | /     | /            | 16        |
++------------+-------+--------------+-----------+
+| Ethernet   | /     | /            | 14        |
++------------+-------+--------------+-----------+
+| Batman v15 | 18    | 18           | 18        |
++------------+-------+--------------+-----------+
+| Ethernet   | 14    | 14           | 14        |
++------------+-------+--------------+-----------+
+| Sum        | 32    | 32           | 102       |
++------------+-------+--------------+-----------+
+
+Minimum MTU
+^^^^^^^^^^^
+
+Calculation of different derived MTUs based on a 1280 byte payload to
+avoid fragmentation.
+
+Suggestions:
+
+- This configuration is only suggested for fastd and Tunneldigger.
+
+- For WireGuard, this configuration is **unsuitable**. To obtain a 1280 byte
+  payload with our protocol stack (see below), the Ethernet frame payload would
+  be 1442 bytes long (for IPv4). As we assume that the WAN network might have
+  a (worst case) MTU of only 1436 (with DSLite), this packet would be too long
+  for the WAN network.
+
++-------------------------------+-------+--------------+-----------+
+|                               | fastd | Tunneldigger | Wireguard |
++===============================+=======+==============+===========+
+| max unfragmented payload\*    | 1280  | 1280         | 1280      |
++-------------------------------+-------+--------------+-----------+
+| intermed layer overhead       | 32    | 32           | 102       |
++-------------------------------+-------+--------------+-----------+
+| VPN MTU\*\*                   | 1312  | 1312         | 1382      |
++-------------------------------+-------+--------------+-----------+
+| protocol overhead (IPv4)      | 66    | 50           | 60        |
++-------------------------------+-------+--------------+-----------+
+| min acceptable WAN MTU (IPv4) | 1378  | 1362         | **1442**  |
++-------------------------------+-------+--------------+-----------+
+| min acceptable WAN MTU (IPv6) | 1398  | 1382         | 1462      |
++-------------------------------+-------+--------------+-----------+
+
+\* Maximum size of payload going into the bat0 interface, that will not be
+fragmented by batman.
+
+\*\* This is the MTU that is set in the site.conf.
+
+Maximum MTU
+^^^^^^^^^^^
+
+Calculation of different derived MTUs based on a maximum WAN MTU of 1436.
+
+Sugestions:
+
+- This configuration can be used for fastd and Tunneldigger.
+
+- For WireGuard, this is the recommended configuration. batman-adv will
+  fragment larger packets transparently to avoid packet loss.
+
++-------------------------------+-------+--------------+-----------+
+|                               | fastd | Tunneldigger | Wireguard |
++===============================+=======+==============+===========+
+| min acceptable WAN MTU (IPv4) | 1436  | 1436         | 1436      |
++-------------------------------+-------+--------------+-----------+
+| protocol overhead (IPv4)      | 66    | 50           | 60        |
++-------------------------------+-------+--------------+-----------+
+| VPN MTU\*\*                   | 1370  | 1386         | 1376      |
++-------------------------------+-------+--------------+-----------+
+| intermed layer overhead       | 32    | 32           | 102       |
++-------------------------------+-------+--------------+-----------+
+| max unfragmented payload\*    | 1338  | 1354         | 1274      |
++-------------------------------+-------+--------------+-----------+
+| min acceptable WAN MTU (IPv6) | 1398  | 1382         | 1462      |
++-------------------------------+-------+--------------+-----------+
+
+\* Maximum size of payload going into the bat0 interface, that will not be
+fragmented by batman.
+
+\*\* This is the MTU that is set in the site.conf.
+
+Suggested MSS Values
+^^^^^^^^^^^^^^^^^^^^
+
+It is highly advised to use MSS clamping for TCP on the gateways/supernodes in
+order to avoid the fragmentation mechanism of batman whenever possible.
+Especially on small embedded devices, fragmentation costs performance.
+
+As batmans fragmentation is transparent to the TCP layer, clamping the MSS
+automatically to the PMTU does not work. Instead, the MSS must be specified
+explicitly. In iptables, this is done via :code:`-j TCPMSS --set-mss X`,
+whereby :code:`X` is the desired MSS.
+
+Since the MSS is specified in terms of payload of a TCP packet, the MSS is
+different for IPv4 and IPv6. Here are some examples for different max
+unfragmented payloads:
+
++---------------------------------+------+------+------+------+
+| max unfragmented payload        | 1274 | 1280 | 1338 | 1354 |
++=================================+======+======+======+======+
+| suggested MSS (IPv4, -40 bytes) | 1234 | 1240 | 1298 | 1314 |
++---------------------------------+------+------+------+------+
+| suggested MSS (IPv6, -60 bytes) | 1214 | 1220 | 1278 | 1294 |
++---------------------------------+------+------+------+------+
+
+Conclusion
+^^^^^^^^^^
+
+Determining the maximum MTU can be a tedious process, especially since the PMTU
+of peers could change at any time. The general recommendation for maximized
+compatibility is therefore an MTU of 1312 bytes (for fastd and tunneldigger)
+and 1376 bytes (for WireGuard).

docs/user/site.rst

@@ -288,7 +288,7 @@ mesh_vpn
 
   The `enabled` option can be set to true to enable the VPN by default. `mtu`
   defines the MTU of the VPN interface, determining a proper MTU value is described
-  in the :ref:`FAQ <faq-mtu>`.
+  in :doc:`mtu`.
 
   By default the public key of a node's VPN daemon is not added to announced respondd
   data; this prevents malicious ISPs from correlating VPN sessions with specific mesh
@@ -331,10 +331,10 @@ mesh_vpn
 
     mesh_vpn = {
       -- enabled = true,
-      mtu = 1312,
       -- pubkey_privacy = true,
 
       fastd = {
+        mtu = 1312,
         methods = {'salsa2012+umac'},
         -- configurable = true,
         -- syslog_level = 'warn',
@@ -384,7 +384,22 @@ mesh_vpn
       },
 
       tunneldigger = {
-        brokers = {'vpn1.alpha-centauri.freifunk.net'}
+        mtu = 1312,
+        brokers = {'vpn1.alpha-centauri.freifunk.net'},
+      },
+
+      wireguard = {
+        mtu = 1376,
+        peers = {
+          vpn1 = {
+            public_key = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=',
+            endpoint = 'vpn1.alpha-centauri.freifunk.net:51810',
+          },
+          vpn2 = {
+            public_key = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=',
+            endpoint = 'vpn2.alpha-centauri.freifunk.net:51810',
+          },
+        },
       },
 
       bandwidth_limit = {

docs/user/supported_devices.rst

@@ -25,6 +25,7 @@ ath79-generic
   - DAP-2660 A1 [#lan_as_wan]_
   - DIR-505 A1 [#lan_as_wan]_
   - DIR-505 A2 [#lan_as_wan]_
+  - DIR-825 B1
 
 * Enterasys
 
@@ -81,7 +82,7 @@ ath79-generic
 
   - Archer A7 (v5)
   - Archer C5 (v1)
-  - Archer C6 (v2)
+  - Archer C6 (v2 EU/RU/JP)
   - Archer C7 (v2, v4, v5)
   - Archer C59 (v1)
   - CPE210 (v1.0, v1.1, v2.0, v3.0, v3.1, v3.20)
@@ -101,6 +102,7 @@ ath79-generic
 
 * Ubiquiti
 
+  - NanoBeam M5 (XW)
   - NanoStation M2/M5 (XW)
   - UniFi AC Lite
   - UniFi AC LR
@@ -108,6 +110,7 @@ ath79-generic
   - UniFi AC Pro
   - UniFi AP
   - UniFi AP LR
+  - UniFi AP Outdoor+
   - UniFi AP PRO
 
 ath79-nand
@@ -118,6 +121,13 @@ ath79-nand
   - GL-AR300M
   - GL-AR750S
 
+ath79-mikrotik
+--------------
+
+* Mikrotik
+
+  - RB951Ui-2nD (hAP)
+
 brcm2708-bcm2708
 ----------------
 
@@ -243,6 +253,10 @@ mpc85xx-p1020
 ramips-mt7620
 -------------
 
+* ASUS
+
+  - RT-AC51U
+
 * GL.iNet
 
   - GL-MT300A
@@ -285,6 +299,10 @@ ramips-mt7621
   - EX6150 (v1)
   - R6220
 
+* TP-Link
+
+  - RE650 (v1)
+
 * Ubiquiti
 
   - EdgeRouter X

modules

@@ -2,15 +2,15 @@ GLUON_FEEDS='packages routing gluon'
 
 OPENWRT_REPO=https://github.com/openwrt/openwrt.git
 OPENWRT_BRANCH=openwrt-22.03
-OPENWRT_COMMIT=5ff900e0ade775062bf888b447893aefa1a37146
+OPENWRT_COMMIT=3cfe050c4a683ecef25d6ded05b1d240921a121a
 
 PACKAGES_PACKAGES_REPO=https://github.com/openwrt/packages.git
 PACKAGES_PACKAGES_BRANCH=openwrt-22.03
-PACKAGES_PACKAGES_COMMIT=948ea0e9c0465524de92268eea13b2a7ae10b484
+PACKAGES_PACKAGES_COMMIT=3aaf3324206582a488ebbea39b7a7bcf93b72368
 
 PACKAGES_ROUTING_REPO=https://github.com/openwrt/routing.git
 PACKAGES_ROUTING_BRANCH=openwrt-22.03
-PACKAGES_ROUTING_COMMIT=48f6120ad4b8c1515d29110c6291ff7e264fef29
+PACKAGES_ROUTING_COMMIT=4b2b6b3d2b0178d254943409cfb4bdce0edbbda4
 
 PACKAGES_GLUON_REPO=https://github.com/freifunk-gluon/packages.git
 PACKAGES_GLUON_COMMIT=308166e3c6b2d571606dd1dbfadd2bb8e31d8f90

package/gluon-autoupdater/check_site.lua

-need_string(in_site({'autoupdater', 'branch'}), false)
-
-need_table({'autoupdater', 'branches'}, function(branch)
+local branches = table_keys(need_table({'autoupdater', 'branches'}, function(branch)
 	need_alphanumeric_key(branch)
 
 	need_string(in_site(extend(branch, {'name'})))
 	need_string_array_match(extend(branch, {'mirrors'}), '^http://')
+
+	local pubkeys = need_string_array_match(in_site(extend(branch, {'pubkeys'})), '^%x+$')
 	need_number(in_site(extend(branch, {'good_signatures'})))
-	need_string_array_match(in_site(extend(branch, {'pubkeys'})), '^%x+$')
+	need(in_site(extend(branch, {'good_signatures'})), function(good_signatures)
+		return good_signatures <= #pubkeys
+	end, nil, string.format('be less than or equal to the number of public keys (%d)', #pubkeys))
+
 	obsolete(in_site(extend(branch, {'probability'})), 'Use GLUON_PRIORITY in site.mk instead.')
-end)
+end))
+
+need_one_of(in_site({'autoupdater', 'branch'}), branches, false)
+
+-- Check GLUON_AUTOUPDATER_BRANCH
+local default_branch
+local f = io.open((os.getenv('IPKG_INSTROOT') or '') .. '/lib/gluon/autoupdater/default_branch')
+if f then
+	default_branch = f:read('*line')
+	f:close()
+end
+need_one_of(value('GLUON_AUTOUPDATER_BRANCH', default_branch), branches, false)

package/gluon-autoupdater/luasrc/lib/gluon/upgrade/500-autoupdater

@@ -21,26 +21,35 @@ for name, config in pairs(site.autoupdater.branches()) do
 	end
 end
 
-if not uci:get('autoupdater', 'settings') then
-	local enabled = unistd.access('/lib/gluon/autoupdater/default_enabled') ~= nil
-
-	local branch = site.autoupdater.branch(min_branch)
+local function default_branch()
 	local f = io.open('/lib/gluon/autoupdater/default_branch')
 	if f then
-		branch = f:read('*line')
+		local ret = f:read('*line')
 		f:close()
+		return ret
 	end
 
+	return site.autoupdater.branch(min_branch)
+end
+
+local enabled, branch
+if not uci:get('autoupdater', 'settings') then
+	enabled = unistd.access('/lib/gluon/autoupdater/default_enabled') ~= nil
+end
+
+local old_branch = uci:get('autoupdater', 'settings', 'branch')
+if not old_branch or not uci:get('autoupdater', old_branch) then
+	branch = default_branch()
 	if not branch then
 		enabled = false
 	end
-
-	uci:section('autoupdater', 'autoupdater', 'settings', {
-		enabled = enabled,
-		branch = branch,
-	})
 end
 
+uci:section('autoupdater', 'autoupdater', 'settings', {
+	enabled = enabled,
+	branch = branch,
+})
+
 uci:set('autoupdater', 'settings', 'version_file', '/lib/gluon/release')
 
 uci:save('autoupdater')

package/gluon-core/luasrc/lib/gluon/check-site.lua

@@ -57,6 +57,10 @@ end
 
 
 local function path_to_string(path)
+	if path.is_value then
+		return path.label
+	end
+
 	return table.concat(path, '.')
 end
 
@@ -96,6 +100,10 @@ local function domain_src()
 end
 
 local function conf_src(path)
+	if path.is_value then
+		return 'Configuration'
+	end
+
 	local src
 
 	if has_domains then
@@ -138,6 +146,14 @@ function M.in_domain(path)
 	return path
 end
 
+function M.value(label, value)
+	return {
+		is_value = true,
+		label = label,
+		value = value,
+	}
+end
+
 function M.this_domain()
 	return domain_code
 end
@@ -171,6 +187,10 @@ function loadpath(path, base, c, ...)
 end
 
 local function loadvar(path)
+	if path.is_value then
+		return path.value
+	end
+
 	return loadpath({}, conf, unpack(path))
 end
 

package/gluon-core/luasrc/lib/gluon/upgrade/010-primary-mac

@@ -117,6 +117,7 @@ local primary_addrs = {
 		}},
 		{'ramips', 'mt7620', {
 			'xiaomi,miwifi-mini',
+			'asus,rt-ac51u',
 		}},
 	}},
 	{phy(1), {