Compare revisions

02fd2d04 · 02fd2d04 · 02fd2d04 · 02fd2d04 · 02fd2d04 · 02fd2d04
--- a/docs/site-example/image-customization.lua
+++ b/docs/site-example/image-customization.lua
+packages {'iwinfo'}
+
+features {
+	'autoupdater',
+	'ebtables-filter-multicast',
+	'ebtables-filter-ra-dhcp',
+	'ebtables-limit-arp',
+	'mesh-batman-adv-15',
+	'mesh-vpn-fastd',
+	'respondd',
+	'status-page',
+	'web-advanced',
+	'web-wizard'
+}
+
+if not device_class('tiny') then
+	features {
+		'wireless-encryption-wpa3'
+	}
+end
--- a/docs/site-example/modules
+++ b/docs/site-example/modules
@@ -12,7 +12,6 @@
 #		the git repository from where to clone the package feed
 #PACKAGES_MY_OWN_PACKAGES_REPO=https://github.com/.../my-own-packages.git

-
 ##	PACKAGES_$feedname_COMMIT
 #		the version/commit of the git repository to clone
 #PACKAGES_MY_OWN_PACKAGES_COMMIT=123456789aabcda1a69b04278e4d38f2a3f57e49

--- a/docs/site-example/site.conf
+++ b/docs/site-example/site.conf
-- This is an example site configuration for Gluon v2018.1
+-- This is an example site configuration for Gluon v2023.2.5
 --
 -- Take a look at the documentation located at
-- http://gluon.readthedocs.org/ for details.
+-- https://gluon.readthedocs.io/ for details.
 --
 -- This configuration will not work as is. You're required to make
 -- community specific changes to it!
@@ -27,7 +27,7 @@
  prefix6 = 'fdxx:xxxx:xxxx::/64',

  -- Timezone of your community.
-  -- See http://wiki.openwrt.org/doc/uci/system#time_zones
+  -- See https://openwrt.org/docs/guide-user/base-system/system_configuration#time_zones
  timezone = 'CET-1CEST,M3.5.0,M10.5.0/3',

  -- List of NTP servers in your community.
@@ -42,18 +42,14 @@
    -- Wireless channel.
    channel = 1,

-    -- List of supported wifi rates (optional)
-    -- Example removes 802.11b compatibility for better performance
-    supported_rates = {6000, 9000, 12000, 18000, 24000, 36000, 48000, 54000},
-
-    -- List of basic wifi rates (optional, required if supported_rates is set)
-    -- Example removes 802.11b compatibility for better performance
-    basic_rate = {6000, 9000, 18000, 36000, 54000},
-
-    -- ESSID used for client network.
+    -- ESSIDs used for client network.
    ap = {
-      ssid = 'alpha-centauri.freifunk.net',
+      -- ssid = 'alpha-centauri.freifunk.net', (optional - SSID for open client network)
      -- disabled = true, -- (optional)
+
+      -- Configuration for a backward compatible OWE network below.
+      -- owe_ssid = 'owe.alpha-centauri.freifunk.net', -- (optional - SSID for OWE client network)
+      -- owe_transition_mode = true, -- (optional - enables transition-mode - requires ssid as well as owe_ssid)
    },

    mesh = {
@@ -69,6 +65,7 @@
  -- for channel.
  wifi5 = {
    channel = 44,
+    outdoor_chanlist = '100-140',
    ap = {
      ssid = 'alpha-centauri.freifunk.net',
    },
@@ -81,6 +78,9 @@

  mesh = {
    vxlan = true,
+    batman_adv = {
+      routing_algo = 'BATMAN_IV',
+    },
  },

  -- The next node feature allows clients to always reach the node it is
@@ -105,14 +105,14 @@

  mesh_vpn = {
    -- enabled = true,
-    mtu = 1312,

    fastd = {
-      -- Refer to http://fastd.readthedocs.org/en/latest/ to better understand
+      -- Refer to https://fastd.readthedocs.io/en/latest/ to better understand
      -- what these options do.

      -- List of crypto-methods to use.
      methods = {'salsa2012+umac'},
+      mtu = 1312,
      -- configurable = true,
      -- syslog_level = 'warn',

@@ -164,7 +164,8 @@
  },

  autoupdater = {
-    -- Default branch. Don't forget to set GLUON_BRANCH when building!
+    -- Default branch (optional), can be overridden by setting GLUON_AUTOUPDATER_BRANCH when building.
+    -- Set GLUON_AUTOUPDATER_ENABLED to enable the autoupdater by default for newly installed nodes.
    branch = 'stable',

    -- List of branches. You may define multiple branches.
@@ -173,7 +174,15 @@
        name = 'stable',

        -- List of mirrors to fetch images from. IPv6 required!
-        mirrors = {'http://1.updates.services.ffhl/stable/sysupgrade'},
+        mirrors = {
+          'http://1.updates.example.org/stable/sysupgrade',
+
+          -- Requires the tls feature in image-customization.lua
+          -- 'https://2.updates.example.org/stable/sysupgrade',
+
+          -- Uses http or https depending on the tls feature in image-customization.lua
+          '//3.updates.example.org/stable/sysupgrade',
+        },

        -- Number of good signatures required.
        -- Have multiple maintainers sign your build and only

--- a/docs/site-example/site.mk
+++ b/docs/site-example/site.mk
 ##	gluon site.mk makefile example

-##	GLUON_FEATURES
-#		Specify Gluon features/packages to enable;
-#		Gluon will automatically enable a set of packages
-#		depending on the combination of features listed
-
-GLUON_FEATURES := \
-	autoupdater \
-	ebtables-filter-multicast \
-	ebtables-filter-ra-dhcp \
-	ebtables-limit-arp \
-	mesh-batman-adv-15 \
-	mesh-vpn-fastd \
-	radvd \
-	respondd \
-	status-page \
-	web-advanced \
-	web-wizard
-
-##	GLUON_SITE_PACKAGES
-#		Specify additional Gluon/LEDE packages to include here;
-#		A minus sign may be prepended to remove a packages from the
-#		selection that would be enabled by default or due to the
-#		chosen feature flags
-
-GLUON_SITE_PACKAGES := haveged iwinfo
-
 ##	DEFAULT_GLUON_RELEASE
 #		version string to use for images
 #		gluon relies on

--- a/docs/user/faq.rst
+++ b/docs/user/faq.rst
 Frequently Asked Questions
 ==========================

+.. _faq-hardware:
+
+What hardware is supported?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+A table with hardware supported by Gluon can be found on the `OpenWrt Wiki`_.
+If you want to find out if your device can potentially be supported
+have a look at :doc:`../dev/hardware` for detailed hardware requirements.
+
+.. _OpenWrt Wiki: https://openwrt.org/toh/views/toh_gluon_supported
+
 .. _faq-dns:

-DNS does not work on the nodes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Why does DNS not work on the nodes?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 Gluon nodes will ignore the DNS server on the WAN port for everything except
 the mesh VPN, which can lead to confusion.
@@ -15,85 +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 Advertisments and DHCP
-
-  .. _MSS clamping: http://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) for batman-adv compat v15 (v2014.0 and later)
-  - up to 28 Byte (14 Byte Ethernet + 14 Byte batadv) for batman-adv compat v14 (v2011.3.0 until and including v2013.4.0)
-
- 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
-----------
-
-Calculcate 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
-all combinations of IPv4, IPv6, batman-adv compat v14 and v15.
--- a/docs/user/getting_started.rst
+++ b/docs/user/getting_started.rst
@@ -8,7 +8,7 @@ Gluon's releases are managed using `Git tags`_. If you are just getting
 started with Gluon we recommend to use the latest stable release of Gluon.

 Take a look at the `list of gluon releases`_ and notice the latest release,
-e.g. *v2018.1*. Always get Gluon using git and don't try to download it
+e.g. *v2023.2.5*. Always get Gluon using git and don't try to download it
 as a Zip archive as the archive will be missing version information.

 Please keep in mind that there is no "default Gluon" build; a site configuration
@@ -19,31 +19,46 @@ an old site configuration to a newer release of Gluon.

 An example configuration can be found in the Gluon repository at *docs/site-example/*.

-.. _Git tags: http://git-scm.com/book/en/Git-Basics-Tagging
+.. _Git tags: https://git-scm.com/book/en/v2/Git-Basics-Tagging
 .. _list of gluon releases: https://github.com/freifunk-gluon/gluon/releases

 Dependencies
 ------------
 To build Gluon, several packages need to be installed on the system. On a
-freshly installed Debian Wheezy system the following packages are required:
+freshly installed Debian Bullseye system the following packages are required:

+* `clang`
 * `git` (to get Gluon and other dependencies)
-* `subversion`
-* `python` (Python 3 doesn't work)
+* `python3`
+* `python3-dev`
+* `python3-pyelftools`
+* `python3-setuptools`
 * `build-essential`
 * `gawk`
 * `unzip`
 * `libncurses-dev` (actually `libncurses5-dev`)
 * `libz-dev` (actually `zlib1g-dev`)
 * `libssl-dev`
+* `libelf-dev` (to build x86-64)
+* `llvm`
 * `wget`
+* `rsync`
+* `time` (built-in `time` doesn't work)
+* `qemu-utils`
+* `ecdsautils` (to sign firmware, see `contrib/sign.sh`)
+* `swig`

+We also provide a container environment that already tracks all these dependencies. It quickly gets you up and running, if you already have either Docker or Podman installed locally.
+
+::
+
+  ./scripts/container.sh

 Building the images
 -------------------

 To build Gluon, first check out the repository. Replace *RELEASE* with the
-version you'd like to checkout, e.g. *v2018.1*.
+version you'd like to checkout, e.g. *v2023.2.5*.

 ::

@@ -79,22 +94,31 @@ Extensive documentation about the site configuration can be found at:
 site directory should always be a git repository by itself; committing site-specific files
 to the Gluon main repository should be avoided, as it will make updates more complicated.

-Next go back to the top-level Gluon directory and build Gluon::
+Next go back to the top-level Gluon directory and build Gluon\ [#make_update]_::

  cd ..
  make update                       # Get other repositories used by Gluon
-    make GLUON_TARGET=ar71xx-generic   # Build Gluon
+  make GLUON_TARGET=ath79-generic   # Build Gluon

-In case of errors read the messages carefully and try to fix the stated issues (e.g. install tools not available yet).
+In case of errors read the messages carefully and try to fix the stated issues
+(e.g. install missing tools not available or look for Troubleshooting_ in the wiki.

-``ar71xx-generic`` is the most common target and will generate images for most of the supported hardware.
+.. _Troubleshooting: https://github.com/freifunk-gluon/gluon/wiki/Troubleshooting
+
+``ath79-generic`` is the most common target and will generate images for most of the supported hardware.
 To see a complete list of supported targets, call ``make`` without setting ``GLUON_TARGET``.

+To build all targets use a loop like this::
+
+  for TARGET in $(make list-targets); do
+    make GLUON_TARGET=$TARGET
+  done
+
 You should generally reserve 5GB of disk space and additionally about 10GB for each `GLUON_TARGET`.

 The built images can be found in the directory `output/images`. Of these, the `factory`
 images are to be used when flashing from the original firmware a device came with,
-and `sysupgrade` is to upgrade from other versions of Gluon or any other OpenWrt/LEDE-based
+and `sysupgrade` is to upgrade from other versions of Gluon or any other OpenWrt-based
 system.

 **Note:** The images for some models are identical; to save disk space, symlinks are generated instead
@@ -103,14 +127,30 @@ symlinks, you can use the following command to resolve these links while copying

  cp -rL output/images /var/www

+The directory `output/debug` contains a compressed kernel image for each
+architecture.
+These can be used for debugging and should be stored along with the images to
+allow debugging of kernel problems on devices in the field.
+See :ref:`Debugging <dev-debugging-kernel-oops>` for more information.
+
+.. rubric:: Footnotes
+
+.. [#make_update] ``make update`` only needs to be called again after updating the
+  Gluon repository (using ``git pull`` or similar) or after changing branches,
+  not for each build. Running it more often than necessary is undesirable, as
+  the update will take some time, and may undo manual modifications of the
+  external repositories while developing on Gluon.
+
+  See :ref:`working-with-repositories` for more information.
+
 Cleaning the build tree
 .......................

 There are two levels of `make clean`::

-    make clean GLUON_TARGET=ar71xx-generic
+  make clean GLUON_TARGET=ath79-generic

-will ensure all packages are rebuilt for a single target. This normally not
+will ensure all packages are rebuilt for a single target. This is usually not
 necessary, but may fix certain kinds of build failures.

 ::
@@ -122,12 +162,12 @@ will clean the entire tree, so the toolchain will be rebuilt as well, which will
 opkg repositories
 -----------------

-Gluon is mostly compatible with LEDE, so the normal LEDE package repositories
+Gluon is mostly compatible with OpenWrt, so the normal OpenWrt package repositories
 can be used for Gluon as well.

 This is not true for kernel modules; the Gluon kernel is incompatible with the
-kernel of the default LEDE images. Therefore, Gluon will not only generate images,
-but also an opkg repository containing all core packages provided by LEDE,
+kernel of the default OpenWrt images. Therefore, Gluon will not only generate images,
+but also an opkg repository containing all core packages provided by OpenWrt,
 including modules for the kernel of the generated images.

 Signing keys
@@ -136,13 +176,21 @@ Signing keys
 Gluon does not support HTTPS for downloading packages; fortunately, opkg deploys
 public-key cryptography to ensure package integrity.

-The Gluon images will contain public keys from two sources: the official LEDE keyring
+The Gluon images will contain public keys from two sources: the official OpenWrt keyring
 (to allow installing userspace packages) and a Gluon-specific key (which is used
 to sign the generated package repository).

-LEDE will handle the generation and handling of the keys itself.
+OpenWrt will handle the generation and handling of the keys itself.
 When making firmware releases based on Gluon, it might make sense to store
 the keypair, so updating the module repository later is possible.
+In fact you should take care to reuse the same opkg keypair, so you don't pollute the key
+store (see ``/etc/opkg/keys``) on the node.
+
+The signing-key is stored at ``openwrt/key-build.pub``, ``openwrt/key-build``,
+``key-build.ucert`` and  ``key-build.ucert.revoke``.
+
+The ``openwrt`` directory is the Git checkout, that gets created after calling ``make update``.
+After making a fresh clone copy the key files to the aforementioned locations.

 .. _getting-started-make-variables:

@@ -155,10 +203,25 @@ usually be set on the command line or in ``site.mk``.
 Common variables
 ................

-GLUON_BRANCH
-  Sets the default branch of the autoupdater. If unset, the autoupdater is disabled
-  by default. For the ``make manifest`` command, GLUON_BRANCH defines the branch to
-  generate a manifest for.
+GLUON_AUTOUPDATER_BRANCH
+  Overrides the default branch of the autoupdater set in ``site.conf``. For the ``make manifest`` command,
+  ``GLUON_AUTOUPDATER_BRANCH`` defines the branch to generate a manifest for.
+
+GLUON_AUTOUPDATER_ENABLED
+  Set to ``1`` to enable the autoupdater by default for newly installed nodes.
+
+GLUON_DEPRECATED
+  Controls whether images for deprecated devices should be built. The following
+  values are supported:
+
+  - ``0``: Do not build any images for deprecated devices.
+  - ``upgrade``: Only build sysupgrade images for deprecated devices.
+  - ``full``: Build both sysupgrade and factory images for deprecated devices.
+
+  Usually, devices are deprecated because their flash size is insufficient to
+  support future Gluon versions. The recommended setting is ``0`` for new sites,
+  and ``upgrade`` for existing configurations (where upgrades for existing
+  deployments of low-flash devices are required). Defaults to ``0``.

 GLUON_LANGS
  Space-separated list of languages to include for the config mode/advanced settings. Defaults to ``en``.
@@ -171,7 +234,7 @@ GLUON_PRIORITY
 GLUON_REGION
  Some devices (at the moment the TP-Link Archer C7) contain a region code that restricts
  firmware installations. Set GLUON_REGION to ``eu`` or ``us`` to make the resulting
-  images installable from the respective stock firmwares.
+  images installable from the respective stock firmware.

 GLUON_RELEASE
  Firmware release number: This string is displayed in the config mode, announced
@@ -179,14 +242,47 @@ GLUON_RELEASE
  is available. The same GLUON_RELEASE has to be passed to ``make`` and ``make manifest``
  to generate a correct manifest.

+GLUON_SITE_VERSION
+  Version of the site configuration. This string is displayed in the config mode
+  and ``gluon-info``. If unset, Gluon generates a version string using ``git describe``
+  on the site folder.
+
 GLUON_TARGET
  Target architecture to build.

 Special variables
 .................

-GLUON_BUILDDIR
-  Working directory during build. Defaults to ``build``.
+GLUON_AUTOREMOVE
+  Setting ``GLUON_AUTOREMOVE=1`` enables the ``CONFIG_AUTOREMOVE`` OpenWrt setting, which will delete package build
+  directories after a package build has finished to save space. This is mostly useful for CI builds from scratch. Do
+  not set this flag during development (or generally, when you want to reuse your build tree for subsequent builds),
+  as it significantly increases incremental build times.
+
+GLUON_DEBUG
+  The following values are supported:
+
+  - ``0``: Remove symbol tables and debug information as well as most section and other
+    information not strictly necessary for execution using ``sstrip``. This saves a small amount
+    of flash space over the default ``strip`` command (roughly 70kiB for ath79), but makes any
+    kind of binary analysis much more difficult, as common tools like objdump and gdb can't
+    handle such files at all.
+  - ``1``: Remove symbol tables and debug information from binaries using the standard ``strip``
+    command. This is the default.
+  - ``2``:  Include debugging symbols usable with GDB or similar tools in all binaries of the image.
+    Requires a device or target with at least 16 MB of flash space, e.g. ``x86-64``.
+
+GLUON_MINIFY
+  Setting ``GLUON_MINIFY=0`` will omit the minification of scripts during the build process. By
+  default the flag is set to ``1``. Disabling the flag is handy if human readable scripts on the
+  devices are desired for development purposes. Be aware that this will increase the size of the
+  resulting images and is therefore not suitable for devices with small flash chips.
+
+GLUON_DEVICES
+  List of devices to build. The list contains the Gluon profile name of a device, the profile
+  name is the first parameter of the ``device`` command in a target file.
+  e.g. ``GLUON_DEVICES="avm-fritz-box-4020 tp-link-tl-wdr4300-v1"``.
+  Empty by default to build all devices of a target.

 GLUON_IMAGEDIR
  Path where images will be stored. Defaults to ``$(GLUON_OUTPUTDIR)/images``.

--- a/docs/user/mtu-diagram_v5.png
+++ b/docs/user/mtu-diagram_v5.png
--- a/docs/user/mtu.rst
+++ b/docs/user/mtu.rst
+.. _mtu:
+
+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://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
+  batman-adv).
+
+- 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.
+
+.. editorconfig-checker-disable
+
+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     |  batman-adv 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
+
+.. editorconfig-checker-enable
+
+Tables for Different VPN Providers
+----------------------------------
+
+VPN Protocol Overhead (IPv4)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Overhead of the VPN protocol layers in bytes on top of an Ethernet frame.
+
+----------+-------+-----------+
+|          | fastd | WireGuard |
+==========+=======+===========+
+| IPv4     | 20    | 20        |
+----------+-------+-----------+
+| UDP      | 8     | 8         |
+----------+-------+-----------+
+| Protocol | 24    | 32        |
+----------+-------+-----------+
+| TAP      | 14    | /         |
+----------+-------+-----------+
+| Sum      | 66    | 60        |
+----------+-------+-----------+
+
+Intermediate Layer Overhead
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Overhead of additional layers on top of the VPN packet needed for different VPN
+providers.
+
+------------+-------+-----------+
+|            | fastd | WireGuard |
+============+=======+===========+
+| IPv6       | /     | 40        |
+------------+-------+-----------+
+| vxlan      | /     | 16        |
+------------+-------+-----------+
+| Ethernet   | /     | 14        |
+------------+-------+-----------+
+| Batman v15 | 18    | 18        |
+------------+-------+-----------+
+| Ethernet   | 14    | 14        |
+------------+-------+-----------+
+| Sum        | 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.
+
+- 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 | WireGuard |
+===============================+=======+===========+
+| max unfragmented payload\*    | 1280  | 1280      |
+-------------------------------+-------+-----------+
+| intermediate layer overhead   | 32    | 102       |
+-------------------------------+-------+-----------+
+| VPN MTU\*\*                   | 1312  | 1382      |
+-------------------------------+-------+-----------+
+| protocol overhead (IPv4)      | 66    | 60        |
+-------------------------------+-------+-----------+
+| min acceptable WAN MTU (IPv4) | 1378  | **1442**  |
+-------------------------------+-------+-----------+
+| min acceptable WAN MTU (IPv6) | 1398  | 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.
+
+Suggestions:
+
+- This configuration can be used for fastd.
+
+- For WireGuard, this is the recommended configuration. batman-adv will
+  fragment larger packets transparently to avoid packet loss.
+
+-------------------------------+-------+-----------+
+|                               | fastd | WireGuard |
+===============================+=======+===========+
+| min acceptable WAN MTU (IPv4) | 1436  | 1436      |
+-------------------------------+-------+-----------+
+| protocol overhead (IPv4)      | 66    | 60        |
+-------------------------------+-------+-----------+
+| VPN MTU\*\*                   | 1370  | 1376      |
+-------------------------------+-------+-----------+
+| intermediate layer overhead   | 32    | 102       |
+-------------------------------+-------+-----------+
+| max unfragmented payload\*    | 1338  | 1274      |
+-------------------------------+-------+-----------+
+| min acceptable WAN MTU (IPv6) | 1398  | 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 1376 bytes for WireGuard.
--- a/docs/user/site.rst
+++ b/docs/user/site.rst
@@ -24,42 +24,43 @@ site_code
 domain_seed
  32 bytes of random data, encoded in hexadecimal, used to seed other random
  values specific to the mesh domain. It must be the same for all nodes of one
-    mesh, but should be different for firmwares that are not supposed to mesh with
+  mesh, but should be different for firmware that is not supposed to mesh with
  each other.

-    The recommended way to generate a value for a new site is:
-    ::
+  The recommended way to generate a value for a new site is::

    echo $(hexdump -v -n 32 -e '1/1 "%02x"' </dev/urandom)

 prefix4 \: optional
-    The IPv4 Subnet of your community mesh network in CIDR notation, e.g.
-    ::
+  The IPv4 Subnet of your community mesh network in CIDR notation, e.g. ::

    prefix4 = '10.111.111.0/18'

  Required if ``next_node.ip4`` is set.

 prefix6
-    The IPv6 subnet of your community mesh network, e.g.
-    ::
+  The IPv6 subnet of your community mesh network, e.g. ::

    prefix6 = 'fdca::ffee:babe:1::/64'

+node_prefix6
+  The ipv6 prefix from which the unique IP-addresses for nodes are selected
+  in olsr-based networks. This may overlap with prefix6. e.g. ::
+
+    node_prefix6 = 'fdca::ffee:babe:2::/64'
+
 timezone
-    The timezone of your community live in, e.g.
-    ::
+  The timezone of your community live in, e.g. ::

    -- Europe/Berlin
    timezone = 'CET-1CEST,M3.5.0,M10.5.0/3'

-ntp_server
-    List of NTP servers available in your community or used by your community, e.g.:
-    ::
+ntp_servers
+  List of NTP servers available in your community or used by your community, e.g.::

    ntp_servers = {'1.ntp.services.ffac','2.ntp.services.ffac'}

-    This NTP servers must be reachable via IPv6 from the nodes. If you don't want to set an IPv6 address
+  These NTP servers must be reachable via IPv6 from the nodes. If you don't want to set an IPv6 address
  explicitly, but use a hostname (which is recommended), see also the :ref:`FAQ <faq-dns>`.

 opkg \: optional
@@ -67,8 +68,8 @@ opkg \: optional

  There are two optional fields in the ``opkg`` section:

-    - ``lede`` overrides the default LEDE repository URL. The default URL would
-      correspond to ``http://downloads.lede-project.org/snapshots/packages/%A``
+  - ``openwrt`` overrides the default OpenWrt repository URL. The default URL would
+    correspond to ``http://downloads.openwrt.org/snapshots/packages/%A``
    and usually doesn't need to be changed when nodes are expected to have IPv6
    internet connectivity.
  - ``extra`` specifies a table of additional repositories (with arbitrary keys)
@@ -76,7 +77,7 @@ opkg \: optional
  ::

    opkg = {
-        lede = 'http://opkg.services.ffac/lede/snapshots/packages/%A',
+      openwrt = 'http://opkg.services.ffac/openwrt/snapshots/packages/%A',
      extra = {
        gluon = 'http://opkg.services.ffac/modules/gluon-%GS-%GR/%S',
      },
@@ -84,17 +85,16 @@ opkg \: optional

  There are various patterns which can be used in the URLs:

-    - ``%n`` is replaced by the LEDE version codename
-    - ``%v`` is replaced by the LEDE version number (e.g. "17.01")
-    - ``%S`` is replaced by the target board (e.g. "ar71xx/generic")
+  - ``%d`` is replaced by the OpenWrt distribution name ("openwrt")
+  - ``%v`` is replaced by the OpenWrt version number (e.g. "17.01")
+  - ``%S`` is replaced by the target board (e.g. "ath79/generic")
  - ``%A`` is replaced by the target architecture (e.g. "mips_24kc")
  - ``%GS`` is replaced by the Gluon site code (as specified in ``site.conf``)
  - ``%GV`` is replaced by the Gluon version
  - ``%GR`` is replaced by the Gluon release (as specified in ``site.mk``)

 regdom \: optional
-    The wireless regulatory domain responsible for your area, e.g.:
-    ::
+  The wireless regulatory domain responsible for your area, e.g. ::

    regdom = 'DE'

@@ -103,63 +103,93 @@ regdom \: optional
 wifi24 \: optional
  WLAN configuration for 2.4 GHz devices.
  ``channel`` must be set to a valid wireless channel for your radio.
+  ``beacon_interval`` can be specified to set a custom beacon interval in
+  time units (TU). A time unit is equivalent to 1024 µs.
+  If not set, the default value of 100 TU (=102.4 ms) is used.

-    There are currently three interface types available. You many choose to
+  There are currently two interface types available. You may choose to
  configure any subset of them:

  - ``ap`` creates a master interface where clients may connect
  - ``mesh`` creates an 802.11s mesh interface with forwarding disabled
-    - ``ibss`` creates an ad-hoc interface

  Each interface may be disabled by setting ``disabled`` to ``true``.
  This will only affect new installations.
  Upgrades will not change the disabled state.

-    Additionally it is possible to configure the ``supported_rates`` and ``basic_rate``
-    of each radio. Both are optional, by default hostapd/driver dictate the rates.
-    If ``supported_rates`` is set, ``basic_rate`` is required, because ``basic_rate``
-    has to be a subset of ``supported_rates``.
-    The example below disables 802.11b rates.
-
-    ``ap`` requires a single parameter, a string, named ``ssid`` which sets the
-    interface's ESSID. This is the WiFi the clients connect to.
+  ``ap`` holds the client network configuration.
+  To create an unencrypted client network, a string named ``ssid`` which sets the
+  interface's ESSID is required. This is the wireless network clients connect to.
+  For an OWE secured network, the ``owe_ssid`` string has to be set. It sets the
+  SSID for the opportunistically encrypted wireless network, to which compatible
+  clients can connect to.
+  For OWE to work, the ``wireless-encryption-wpa3`` has to be enabled as a feature
+  in your site.
+  To utilize the OWE transition mode, ``owe_transition_mode`` has to be set to true.
+  When ``owe_transition_mode`` is enabled, the OWE secured SSID will be hidden.
+  Compatible devices will automatically connect to the OWE secured SSID when selecting
+  the open SSID.
+  Note that for the transition mode to work, both ``ssid`` as well as ``owe_ssid``
+  have to be enabled. Also, some devices with a broken implementation might not be able
+  to connect with a transition-mode enabled network.

  ``mesh`` requires a single parameter, a string, named ``id`` which sets the
  mesh id, also visible as an open WiFi in some network managers. Usually you
  don't want users to connect to this mesh-SSID, so use a cryptic id that no
  one will accidentally mistake for the client WiFi.

-    ``ibss`` requires two parametersr: ``ssid`` (a string) and ``bssid`` (a MAC).
-    An optional parameter ``vlan`` (integer) is supported.
-
-    Both ``mesh`` and ``ibss`` accept an optional ``mcast_rate`` (kbit/s) parameter for
+  ``mesh`` also accepts an optional ``mcast_rate`` (kbit/s) parameter for
  setting the multicast bitrate. Increasing the default value of 1000 to something
  like 12000 is recommended.
+
  ::

    wifi24 = {
      channel = 11,
-         supported_rates = {6000, 9000, 12000, 18000, 24000, 36000, 48000, 54000},
-         basic_rate = {6000, 9000, 18000, 36000, 54000},
      ap = {
        ssid = 'alpha-centauri.freifunk.net',
+        owe_ssid = 'owe.alpha-centauri.freifunk.net',
+        owe_transition_mode = true,
      },
      mesh = {
        id = 'ueH3uXjdp',
        mcast_rate = 12000,
      },
-         ibss = {
-           ssid = 'ff:ff:ff:ee:ba:be',
-           bssid = 'ff:ff:ff:ee:ba:be',
-           mcast_rate = 12000,
-         },
    },

+.. _user-site-wifi5:
+
 wifi5 \: optional
-    Same as `wifi24` but for the 5Ghz radio.
+  Same as `wifi24` but for the 5 GHz radio.
+
+  Additionally a range of channels that are safe to use outsides on the 5 GHz band can
+  be set up through ``outdoor_chanlist``, which allows for a space-separated list of
+  channels and channel ranges, separated by a hyphen.
+  When set this offers the outdoor mode flag for 5 GHz radios in the config mode which
+  reconfigures the AP to select its channel from outdoor chanlist, while respecting
+  regulatory specifications, and disables mesh on that radio.
+  The ``outdoors`` option in turn allows to configure when outdoor mode will be enabled.
+  When set to ``true`` all 5 GHz radios will use outdoor channels, while on ``false``
+  the outdoor mode will be completely disabled. The default setting is ``'preset'``,
+  which will enable outdoor mode automatically on outdoor-capable devices.
+
+  It can be beneficial to look up the WLAN channels that are used by `weather radars`_
+  when constructing ``outdoor_chanlist`` to try and minimize the impact of DFS events.
+
+  .. _weather radars: https://homepage.univie.ac.at/albert.rafetseder/RADARs/help.html
+
+  ::
+
+    wifi5 = {
+      channel = 44,
+      outdoor_chanlist = "100-140",
+
+      [...]
+    },

 next_node \: package
  Configuration of the local node feature of Gluon
+
  ::

    next_node = {
@@ -197,7 +227,8 @@ mesh
  Gluon generally segments layer-2 meshes so that each node becomes IGMP/MLD
  querier for its own local clients. This is necessary for reliable multicast
  snooping. The segmentation is realized by preventing IGMP/MLD queries from
-    passing through the mesh.
+  passing through the mesh. See also
+  :ref:`gluon-mesh-batman-adv <igmp-mld-domain-segmentation>` for details.

  By default, not only queries are filtered, but also membership report and
  leave packets, as they add to the background noise of the mesh. As a
@@ -211,15 +242,34 @@ mesh
  In addition, options specific to the batman-adv routing protocol can be set
  in the *batman_adv* section:

-    The optional value *gw_sel_class* sets the gateway selection class. The
-    default is class 20, which is based on the link quality (TQ) only; class 1
-    is calculated from both the TQ and the announced bandwidth.
+  The mandatory value *routing_algo* selects the batman-adv protocol variant.
+  The following values are supported:
+
+  - ``BATMAN_IV``
+  - ``BATMAN_V``
+
+  The optional value *gw_sel_class* sets the gateway selection class, the
+  default is ``20`` for B.A.T.M.A.N. IV and ``5000`` kbit/s for B.A.T.M.A.N. V.
+
+  - **B.A.T.M.A.N. IV:** with the value ``20`` the gateway is selected based
+    on the link quality (TQ) only; with class ``1`` it is calculated from
+    both, the TQ and the announced bandwidth.
+  - **B.A.T.M.A.N. V:** with the value ``1500`` the gateway is selected if the
+    throughput is at least 1500 kbit/s faster than the throughput of the
+    currently selected gateway.
+
+  For details on determining the threshold, when to switch to a new gateway,
+  see `batctl manpage`_, section "gw_mode".
+
+  .. _batctl manpage: https://www.open-mesh.org/projects/batman-adv/wiki/Gateways
+
  ::

    mesh = {
      vxlan = true,
      filter_membership_reports = false,
      batman_adv = {
+        routing_algo = 'BATMAN_IV',
        gw_sel_class = 1,
      },
    }
@@ -230,13 +280,13 @@ 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
  nodes via public respondd data. If this is of no concern in your threat model,
  this behaviour can be disabled (and thus announcing the public key be enabled) by
-    setting `pubkey_privacy` to `false`. At the moment, this option only affects fastd.
+  setting `pubkey_privacy` to `false`.

  The `fastd` section configures settings specific to the *fastd* VPN
  implementation.
@@ -253,21 +303,23 @@ mesh_vpn

  You can set syslog_level from verbose (default) to warn to reduce syslog output.

-    The `tunneldigger` section is used to define the *tunneldigger* broker list.
+  fastd allows to configure a tree of peer groups and peers. By default, the
+  list of groups and peers configured in the *fastd* UCI config is completely
+  replaced by the list from site.conf on upgrades. To allow custom modifications
+  to the peer list, removal and modification of peers can be prevented by
+  setting the *preserve* option of a peer to ``1`` in UCI.

-    **Note:** It doesn't make sense to include both `fastd` and `tunneldigger`
-    sections in the same configuration file, as only one of the packages *gluon-mesh-vpn-fastd*
-    and *gluon-mesh-vpn-tunneldigger* should be installed with the current
-    implementation.
+  **Note:** It may be interesting to include the package *gluon-iptables-clamp-mss-to-pmtu*
+  in the build when using *gluon-mesh-olsrd* to work around ICMP black holes on the internet.

  ::

    mesh_vpn = {
      -- enabled = true,
-        mtu = 1312,
      -- pubkey_privacy = true,

      fastd = {
+        mtu = 1312,
        methods = {'salsa2012+umac'},
        -- configurable = true,
        -- syslog_level = 'warn',
@@ -316,8 +368,18 @@ mesh_vpn
        },
      },

-        tunneldigger = {
-          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 = {
@@ -332,17 +394,46 @@ mesh_vpn
      },
    }

-mesh_on_wan \: optional
-    Enables the mesh on the WAN port (``true`` or ``false``).
+.. _user-site-interfaces:
+
+interfaces \: optional
+  Default setup for Ethernet ports.
  ::

-       mesh_on_wan = true,
+    interfaces = {
+      lan = {
+        default_roles = { 'client', 'mesh' },
+      },
+      wan = {
+        default_roles = { 'uplink', 'mesh' },
+      },
+      single = {
+        default_roles = { 'uplink', 'mesh' },
+      },
+    },
+
+  For devices that have two distinct Ethernet ports or port groups (often
+  labeled WAN and LAN), the ``lan`` and ``wan`` sections are used. When there
+  is only one port (group), ``single`` is used instead.

-mesh_on_lan \: optional
-    Enables the mesh on the LAN port (``true`` or ``false``).
-    ::
+  Available interface roles:

-        mesh_on_lan = true,
+  - ``client``: Port allows regular clients to connect to the mesh
+  - ``uplink``: Port is used to establish Mesh VPN connections
+  - ``mesh``: Wired meshing to another Gluon or Gluon-compatible node
+
+  The ``client`` role requires exclusive control over an interface. When
+  the ``client`` role is assigned to an interface at the same time as other
+  roles (like ``'client', 'mesh'`` in the above example), the other roles take
+  precedence (enabling ``mesh``, but not ``client`` in the example). In that
+  case, the ``client`` role is removed from the config of the interface.
+
+  All interface settings are optional. If unset, the following defaults are
+  used:
+
+  - ``lan``: ``{ 'client' }``
+  - ``wan``: ``{ 'uplink' }``
+  - ``single``: Same as ``wan``

 poe_passthrough \: optional
  Enable PoE passthrough by default on hardware with such a feature.
@@ -350,18 +441,25 @@ poe_passthrough \: optional
 autoupdater \: package
  Configuration for the autoupdater feature of Gluon.

+  Specifying a default branch in *site.conf* is optional. See
+  :doc:`../features/autoupdater` for information how to change the behaviour
+  of the autoupdater during image build.
+
  The mirrors are checked in random order until the manifest could be downloaded
  successfully or all mirrors have been tried.
  ::

    autoupdater = {
-        branch = 'stable',
+      branch = 'stable', -- optional
      branches = {
        stable = {
          name = 'stable',
          mirrors = {
            'http://[fdca:ffee:babe:1::fec1]/firmware/stable/sysupgrade/',
-              'http://autoupdate.alpha-centauri.freifunk.net/firmware/stable/sysupgrade/',
+            -- Requires the tls feature in image-customization.lua
+            'https://autoupdate.alpha-centauri.freifunk.net/firmware/stable/sysupgrade/',
+            -- Uses http or https depending on the tls feature in image-customization.lua
+            '//autoupdate2.alpha-centauri.freifunk.net/firmware/stable/sysupgrade/',
          },
          -- Number of good signatures required
          good_signatures = 2,
@@ -376,6 +474,18 @@ autoupdater \: package
  All configured mirrors must be reachable from the nodes via IPv6. If you don't want to set an IPv6 address
  explicitly, but use a hostname (which is recommended), see also the :ref:`FAQ <faq-dns>`.

+  HTTPS URLs can be used if the **tls** feature is enabled in **image-customization.lua**.
+
+  Use protocol-less ``//server/path`` URLs to use HTTPS if the **tls** feature is available,
+  but fall back to HTTP otherwise. The server **must** allow HTTPS connections and provide
+  a valid certificate in this case; the autoupdater will not fall back to HTTP if the **tls**
+  feature is enabled, but the HTTPS connection fails.
+
+  Note that the validity period of TLS certificates is checked as well, so care must be taken
+  to provide working NTP servers in addition to the update mirrors when using HTTPS.
+
+.. _user-site-config_mode:
+
 config_mode \: optional
  Additional configuration for the configuration web interface. All values are
  optional.
@@ -384,10 +494,24 @@ config_mode \: optional
  and the node's primary MAC address is assigned. Manually setting a hostname
  can be enforced by setting *hostname.optional* to *false*.

-    By default, no altitude fields are shown by the *gluon-config-mode-geo-location*
-    package. If *geo_location.show_altitude* is set to *true*, the *gluon-config-mode:altitude-label*
-    and *gluon-config-mode:altitude-help* strings must be provided in the site i18n
-    data as well.
+  To not prefill the hostname-field in config-mode with the default hostname,
+  set *hostname.prefill* to *false*.
+
+  By default, no altitude field is shown by the *gluon-config-mode-geo-location*
+  package. Set *geo_location.show_altitude* to *true* if you want the altitude
+  field to be visible.
+
+  The *geo_location.osm* section is only relevant when the *gluon-config-mode-geo-location-osm*
+  package is used. The *center.lon* and *center.lat* values are mandatory in this case and
+  define the default center of the map when no position has been picked yet. The *zoom* level
+  defaults to 12 in this case.
+
+  *openlayers_url* allows to override the base URL of the
+  *build/ol.js* and *css/ol.css* files (the default is
+  ``https://cdn.jsdelivr.net/gh/openlayers/openlayers.github.io@35ffe7626ce16c372143f3c903950750075e7068/en/v5.3.0``).
+  It is also possible to replace the default tile layer (which is OpenStreetMap)
+  with a custom one using the *tile_layer* section. Only XYZ layers are supported
+  at this point.

  The remote login page only shows SSH key configuration by default. A
  password form can be displayed by setting *remote_login.show_password_form*
@@ -398,9 +522,23 @@ config_mode \: optional
    config_mode = {
      hostname = {
        optional = false,
+        prefill = true,
      },
      geo_location = {
        show_altitude = true,
+        osm = {
+          center = {
+            lat = 52.951947558,
+            lon = 8.744238281,
+          },
+          zoom = 13,
+          -- openlayers_url = 'http://ffac.example.org/openlayer',
+          -- tile_layer = {
+          --   type = 'XYZ',
+          --   url = 'https://{a-c}.tile.openstreetmap.org/{z}/{x}/{y}.png',
+          --   attributions = '&#169; <a href="https://www.openstreetmap.org/copyright" target="_blank">OpenStreetMap</a> contributors.',
+          -- },
+        },
      },
      remote_login = {
        show_password_form = true,
@@ -442,20 +580,26 @@ setup_mode \: package
      skip = true,
    },

+.. _user-site-build-configuration:
+
 Build configuration
 -------------------

 The ``site.mk`` is a Makefile which defines various values
 involved in the build process of Gluon.

-GLUON_FEATURES
-    Defines a list of features to include. The feature list is used to generate
-    the default package set.
+GLUON_DEPRECATED
+  Controls whether images for deprecated devices should be built. The following
+  values are supported:
+
+  - ``0``: Do not build any images for deprecated devices.
+  - ``upgrade``: Only build sysupgrade images for deprecated devices.
+  - ``full``: Build both sysupgrade and factory images for deprecated devices.

-GLUON_SITE_PACKAGES
-    Defines a list of packages which should be installed in addition to the
-    default package set. It is also possible to remove packages from the
-    default set by prepending a minus sign to the package name.
+  Usually, devices are deprecated because their flash size is insufficient to
+  support future Gluon versions. The recommended setting is ``0`` for new sites,
+  and ``upgrade`` for existing configurations (where upgrades for existing
+  deployments of low-flash devices are required). Defaults to ``0``.

 GLUON_RELEASE
  The current release version Gluon should use.
@@ -472,11 +616,6 @@ GLUON_LANGS
  List of languages (as two-letter-codes) to be included in the web interface. Should always contain
  ``en``.

-GLUON_WLAN_MESH
-  Setting this to ``11s`` or ``ibss`` will enable generation of matching images for devices which don't
-  support both meshing modes, either at all (e.g. ralink and mediatek don't support AP+IBSS) or in the
-  same firmware (ath10k-based 5GHz). Defaults to ``11s``.
-
 .. _user-site-feature-flags:

 Feature flags
@@ -498,8 +637,8 @@ leading to entangled package names like *gluon-mesh-vpn-fastd-respondd* or
 *gluon-status-page-mesh-batman-adv-i18n-de*.

 For this reason, we have introduced *feature flags*, which can be specified
-in the *GLUON_FEATURES* variable. These flags allow to specify a set of features
-on a higher level than individual package names.
+using the ``image-customization.lua`` file. These flags allow to specify
+a set of features on a higher level than individual package names.

 Most Gluon packages can simply be specified as feature flags by removing the ``gluon-``
 prefix: The feature flag corresponding to the package *gluon-mesh-batman-adv-15* is
@@ -507,12 +646,12 @@ prefix: The feature flag corresponding to the package *gluon-mesh-batman-adv-15*

 The file ``package/features`` in the Gluon repository (or
 ``features`` in site feeds) can specify additional rules for deriving package lists
-from feature flags, e.g. specifying both *status-page* and either *mesh-batman-adv-14*
-or *mesh-batman-adv-15* will automatically select the additional package
+from feature flags, e.g. specifying both *status-page* and *mesh-batman-adv-15*
+will automatically select the additional package
 *gluon-status-page-mesh-batman-adv*. In the future, selecting the flags
 *mesh-vpn-fastd* and *respondd* might automatically enable the additional
 package *gluon-mesh-vpn-fastd-respondd*, and enabling *status-page* and
-*mesh-batman-adv-15* (or *-14*) with ``de`` in *GLUON_LANGS* could
+*mesh-batman-adv-15* with ``de`` in *GLUON_LANGS* could
 add the package *gluon-status-page-mesh-batman-adv-i18n-de*.

 In short, it is not necessary anymore to list all the individual packages that are
@@ -521,9 +660,10 @@ flags using a flexible ruleset defined in the Gluon repo or site package feeds.
 To some extent, it will even allow us to further modularize existing Gluon packages,
 without necessitating changes to existing site configurations.

-It is still possible to override such automatic rules using *GLUON_SITE_PACKAGES*
-(e.g., ``-gluon-status-page-mesh-batman-adv`` to remove the automatically added
-package *gluon-status-page-mesh-batman-adv*).
+It is still possible to override such automatic rules by removing them using
+*packages* in the ``image-customization.lua`` file
+(e.g., ``features { '-gluon-status-page-mesh-batman-adv' }`` to remove
+the automatically added package *gluon-status-page-mesh-batman-adv*).

 For convenience, there are two feature flags that do not directly correspond to a Gluon
 package:
@@ -531,19 +671,70 @@ package:
 * web-wizard

  Includes the *gluon-config-mode-...* base packages (hostname, geolocation and contact info),
-  as well as the *gluon-config-mode-autoupdater* (when *autoupdater* is in *GLUON_FEATURES*),
-  and *gluon-config-mode-mesh-vpn* (when *mesh-vpn-fastd* or *mesh-vpn-tunneldigger* are in
-  *GLUON_FEATURES*)
+  as well as the *gluon-config-mode-autoupdater* (when *autoupdater* is an enabled feature),
+  and *gluon-config-mode-mesh-vpn* (when *mesh-vpn-fastd* or `mesh-vpn-wireguard` are
+  enabled features)

 * web-advanced

  Includes the *gluon-web-...* base packages (admin, network, WiFi config),
-  as well as the *gluon-web-autoupdater* (when *autoupdater* is in *GLUON_FEATURES*)
+  as well as the *gluon-web-autoupdater* (when *autoupdater* is an enabled feature),

-We recommend to use *GLUON_SITE_PACKAGES* for non-Gluon OpenWrt packages only and
-completely rely on *GLUON_FEATURES* for Gluon packages, as it is shown in the
+We recommend to include packages for non-Gluon OpenWrt packages only and
+completely rely on features for Gluon packages, as it is shown in the
 example *site.mk*.

+.. _site-image-customization:
+
+Image customization
+^^^^^^^^^^^^^^^^^^^
+
+Gluon allows configuration of the build parameters for the images. This
+configuration must always exist to configure the basic features included in a
+Gluon build.
+
+The file ``image-customization.lua`` in the root of the site configuration is
+used for this purpose, making use of a Domain Specific Language based on Lua.
+See the :ref:`site-examples` section for a simple example showing both basic
+setup and a device-specific alteration.
+
+The following functions are available:
+
+device(device_name_list)
+  Returns true in case the current device is in the list of devices specified in ``device_name_list``.
+  ``device_name_list`` is a table of strings.
+
+target(openwrt_target, openwrt_subtarget)
+  Returns true in case the current device is of the specified OpenWrt target and subtarget.
+  The parameter ```openwrt_subtarget``` is optional. If it is not specified, only the target is matched.
+
+device_class(dev_class)
+  Returns true in case the current device is of the specified device class.
+
+features(feature_table)
+  Includes the specified list of features in the image. ``feature_table`` is a table of strings.
+  These strings can be prefixed with a dash to exclude features included earlier in the file.
+
+packages(package_table)
+  Includes the specified list of packages in the image. ``package_table`` is a table of strings.
+  These strings can be prefixed with a dash to exclude packages included earlier in the file.
+
+broken(broken_state)
+  Overrides the broken state specified by Gluon. Can be used to mark a device as broken or
+  remove the pre-defined broken state.
+
+disable()
+  Disables image generation.
+
+disable_factory()
+  Disables factory image generation. Sysupgrade images are still generated and stored in the image
+  output directory.
+
+Technically, the image customization file is evaluated once for each device, allowing
+to make use of regular Lua *if* statements for device-specific configuration as
+can be seen in the example.
+
+
 .. _site-config-mode-texts:

 Config mode texts
@@ -561,12 +752,6 @@ gluon-config-mode:pubkey
 gluon-config-mode:novpn
  Information shown on the reboot page, if the mesh VPN was not selected.

-gluon-config-mode:altitude-label
-    Label for the ``altitude`` field
-
-gluon-config-mode:altitude-help
-    Description for the usage of the ``altitude`` field
-
 gluon-config-mode:contact-help
  Description for the usage of the ``contact`` field

@@ -577,7 +762,10 @@ gluon-config-mode:hostname-help
  Description for the usage of the ``hostname`` field

 gluon-config-mode:geo-location-help
-    Description for the usage of the longitude/latitude fields
+  Description for the usage of the longitude/latitude fields (and altitude, if shown)
+
+gluon-config-mode:altitude-label
+  Label for the ``altitude`` field

 gluon-config-mode:reboot
  General information shown on the reboot page.
@@ -602,9 +790,9 @@ Site modules
 The file ``modules`` in the site repository is completely optional and can be used
 to supply additional package feeds from which packages are built. The git repositories
 specified here are retrieved in addition to the default feeds when ``make update``
-it called.
+is called.

-This file's format is very similar to the toplevel ``modules`` file of the Gluon
+This file's format is very similar to the top-level ``modules`` file of the Gluon
 tree, with the important different that the list of feeds must be assigned to
 the variable ``GLUON_SITE_FEEDS``. Multiple feed names must be separated by spaces,
 for example::
@@ -623,13 +811,14 @@ PACKAGES_${feed}_COMMIT

 PACKAGES_${feed}_BRANCH
  Optional: The branch of the repository the given commit ID can be found in.
-    Defaults to the default branch of the repository (usually ``master``)
+  Defaults to the default branch of the repository (usually ``main`` or ``master``)

 These variables are always all uppercase, so for an entry ``foo`` in GLUON_SITE_FEEDS,
 the corresponding configuration variables would be ``PACKAGES_FOO_REPO``,
 ``PACKAGES_FOO_COMMIT`` and ``PACKAGES_FOO_BRANCH``. Slashes in feed names are
 replaced by underscores to get valid shell variable identifiers.

+.. _site-examples:

 Examples
 --------
@@ -646,6 +835,12 @@ site.conf
 .. literalinclude:: ../site-example/site.conf
  :language: lua

+image-customization.lua
+^^^^^^^^^^^^^^^^^^^^^^^
+
+.. literalinclude:: ../site-example/image-customization.lua
+  :language: lua
+
 i18n/en.po
 ^^^^^^^^^^

@@ -667,41 +862,5 @@ modules
 site-repos in the wild
 ^^^^^^^^^^^^^^^^^^^^^^

-This is a non-exhaustive list of site-repos from various communities:
-
-* `site-ffa <https://github.com/tecff/site-ffa>`_ (Altdorf, Landshut & Umgebung)
-* `site-ffac <https://github.com/ffac/site>`_ (Regio Aachen)
-* `site-ffbs <https://github.com/ffbs/site-ffbs>`_ (Braunschweig)
-* `site-ffhb <https://github.com/FreifunkBremen/gluon-site-ffhb>`_ (Bremen)
-* `site-ffda <https://git.darmstadt.ccc.de/ffda/site>`_ (Darmstadt)
-* `site-ff3l <https://github.com/ff3l/site-ff3l>`_ (Dreiländereck)
-* `site-ffeh <https://github.com/freifunk-ehingen/site-ffeh>`_ (Ehingen)
-* `site-fffl <https://github.com/freifunk-flensburg/site-fffl>`_ (Flensburg)
-* `site-ffgoe <https://github.com/freifunk-goettingen/site-ffgoe>`_ (Göttingen)
-* `site-ffgt-rhw <https://github.com/ffgtso/site-ffgt-rhw>`_ (Guetersloh)
-* `site-ffhh <https://github.com/freifunkhamburg/site-ffhh>`_ (Hamburg)
-* `site-ffho <https://git.ffho.net/freifunkhochstift/ffho-site>`_ (Hochstift)
-* `site-ffhgw <https://github.com/lorenzo-greifswald/site-ffhgw>`_ (Greifswald)
-* `site-ffka <https://github.com/ffka/site-ffka>`_ (Karlsruhe)
-* `site-ffki <https://git.freifunk.in-kiel.de/ffki-site/>`_ (Kiel)
-* `site-fflz <https://github.com/freifunk-lausitz/site-fflz>`_ (Lausitz)
-* `site-ffl <https://github.com/freifunk-leipzig/freifunk-gluon-leipzig>`_ (Leipzig)
-* `site-ffhl <https://github.com/freifunk-luebeck/site-ffhl>`_ (Lübeck)
-* `site-fflg <https://github.com/kartenkarsten/site-fflg>`_ (Lüneburg)
-* `site-ffmd <https://github.com/FreifunkMD/site-ffmd>`_ (Magdeburg)
-* `site-ffmwu <https://github.com/freifunk-mwu/sites-ffmwu>`_ (Mainz, Wiesbaden & Umgebung)
-* `site-ffmyk <https://github.com/FreifunkMYK/site-ffmyk>`_ (Mayen-Koblenz)
-* `site-ffmo <https://github.com/ffruhr/site-ffmo>`_ (Moers)
-* `site-ffmg <https://github.com/ffruhr/site-ffmg>`_ (Mönchengladbach)
-* `site-ffm <https://github.com/freifunkMUC/site-ffm>`_ (München)
-* `site-ffhmue <https://github.com/Freifunk-Muenden/site-conf>`_ (Münden)
-* `site-ffms <https://github.com/FreiFunkMuenster/site-ffms>`_ (Münsterland)
-* `site-neuss <https://github.com/ffne/site-neuss>`_ (Neuss)
-* `site-ffniers <https://github.com/ffruhr/site-ffniers>`_ (Niersufer)
-* `site-ffndh <https://github.com/freifunk-nordheide/ffnordheide/tree/ffnh-lede/ffndh-site>`_ (Nordheide)
-* `site-ffnw <https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/tree/master>`_ (Nordwest)
-* `site-ffrgb <https://github.com/ffrgb/site-ffrgb>`_ (Regensburg)
-* `site-ffrn <https://github.com/Freifunk-Rhein-Neckar/site-ffrn>`_ (Rhein-Neckar)
-* `site-ffruhr <https://github.com/ffruhr?utf8=✓&query=site>`_ (Ruhrgebiet, Multi-Communities)
-* `site-ffs <https://github.com/freifunk-stuttgart/site-ffs>`_ (Stuttgart)
-* `site-fftr <https://github.com/freifunktrier/site-fftr>`_ (Trier)
+A non-exhaustive list of site-repos from various communities can be found on the
+wiki: https://github.com/freifunk-gluon/gluon/wiki/Site-Configurations
--- a/docs/user/supported_devices.rst
+++ b/docs/user/supported_devices.rst
+Supported Devices & Architectures
+=================================
+
+armsr-armv7
+-----------
+
+* Arm SystemReady (EFI) 32-bit
+
+armsr-armv8
+-----------
+
+* Arm SystemReady (EFI) 64-bit
+
+ath79-generic
+--------------
+
+* ALFA Network
+
+  - AP121F
+
+* AVM
+
+  - FRITZ!WLAN Repeater 300E [#avmflash]_
+  - Fritz!WLAN Repeater 450E [#avmflash]_
+  - Fritz!Box 4020 [#avmflash]_
+
+* Buffalo
+
+  - WZR-HP-AG300H / WZR-600DHP
+  - WZR-HP-G300NH (rtl8366s)
+
+* devolo
+
+  - WiFi pro 1200e [#lan_as_wan]_
+  - WiFi pro 1200i
+  - WiFi pro 1750c
+  - WiFi pro 1750e [#lan_as_wan]_
+  - WiFi pro 1750i
+  - WiFi pro 1750x
+
+* D-Link
+
+  - DAP-1330 A1 [#lan_as_wan]_
+  - DAP-1365 A1 [#lan_as_wan]_
+  - DAP-2660 A1 [#lan_as_wan]_
+  - DAP-2680 A1 [#lan_as_wan]_
+  - DAP-2695 A1 [#lan_as_wan]_
+  - DIR-505 A1 [#lan_as_wan]_
+  - DIR-505 A2 [#lan_as_wan]_
+  - DIR-825 B1
+
+* Enterasys
+
+  - WS-AP3705i
+
+* Extreme Networks
+
+  - WS-AP3805i
+
+* GL.iNet
+
+  - 6416A
+  - GL-AR150
+  - GL-AR300M-Lite
+  - GL-AR750
+  - GL-USB150 (Microuter)
+
+* Joy-IT
+
+  - JT-OR750i
+
+* LibreRouter
+
+  - LibreRouter v1 [#missing_radios]_
+
+* NETGEAR
+
+  - WNDR3700 (v1, v2)
+  - WNDR3800
+  - WNR2200 (8M, 16M)
+  - WNDRMAC (v2)
+
+* OCEDO
+
+  - Koala
+  - Raccoon
+
+* Onion
+
+  - Omega [#modular_ethernet]_
+
+* OpenMesh
+
+  - A40
+  - A60
+  - MR600 (v1, v2)
+  - MR900 (v1, v2)
+  - MR1750 (v1, v2)
+  - OM2P (v1, v2, v4)
+  - OM2P-HS (v1, v2, v3, v4)
+  - OM2P-LC
+  - OM5P
+  - OM5P-AC (v1, v2)
+  - OM5P-AN
+
+* Plasma Cloud
+
+  - PA300
+  - PA300E
+
+* Siemens
+
+  - WS-AP3610
+
+* Sophos
+
+  - AP15C
+  - AP100
+  - AP100c
+  - AP55
+  - AP55c
+
+* Teltonika
+
+  - RUT230 (v1)
+
+* TP-Link
+
+  - Archer A7 (v5)
+  - Archer C5 (v1)
+  - Archer C6 (v2 EU/RU/JP)
+  - Archer C7 (v2, v4, v5)
+  - Archer C59 (v1)
+  - Archer C60 (v1)
+  - CPE210 (v1.0, v1.1, v2.0, v3.0, v3.1, v3.20)
+  - CPE220 (v3.0)
+  - CPE510 (v1.0, v1.1, v2.0, v3.0)
+  - CPE710 (v1.0)
+  - EAP225-Outdoor (v1, v3)
+  - TL-WDR3500 (v1)
+  - TL-WDR3600 (v1)
+  - TL-WDR4300 (v1)
+  - TL-WR810N (v1)
+  - TL-WR842N/ND (v3)
+  - TL-WR1043N/ND (v2, v3, v4, v5)
+  - TL-WR2543N/ND (v1)
+  - WBS210 (v1.20, v2.0)
+  - WBS510 (v1.20)
+
+* Ubiquiti
+
+  - NanoBeam 5AC 19 (XC)
+  - NanoBeam M5 (XW)
+  - NanoStation Loco M2/M5 (XW)
+  - NanoStation M2/M5 (XW)
+  - UniFi AC Lite
+  - UniFi AC LR
+  - UniFi AC Mesh
+  - UniFi AC Mesh Pro
+  - UniFi AC Pro
+  - UniFi AP
+  - UniFi AP LR
+  - UniFi AP Outdoor+
+  - UniFi AP PRO
+  - UniFi Swiss Army Knife Ultra
+
+ath79-mikrotik
+--------------
+
+* Mikrotik
+
+  - RB951Ui-2nD (hAP)
+  - RBwAPR-2nD (wAP R)
+
+ath79-nand
+----------
+
+* Aerohive
+
+  - HiveAP 121
+
+* GL.iNet
+
+  - GL-AR300M
+  - GL-AR750S
+  - GL-XE300
+
+* NETGEAR
+
+  - WNDR3700 (v4)
+  - WNDR4300 (v1)
+
+* Zyxel
+
+  - NBG6716
+
+brcm2708-bcm2708
+----------------
+
+* Raspberry Pi 1
+
+brcm2708-bcm2709
+----------------
+
+* Raspberry Pi 2
+
+
+ipq40xx-generic
+---------------
+
+* 8devices
+
+  - Jalapeno
+
+* Aruba
+
+  - AP-303
+  - AP-303H
+  - AP-365
+  - Instant On AP11
+  - Instant On AP11D
+  - Instant On AP17
+
+* AVM
+
+  - FRITZ!Box 4040 [#avmflash]_
+  - FRITZ!Box 7520 (v1) [#eva_ramboot]_ [#lan_as_wan]_
+  - FRITZ!Box 7530 [#eva_ramboot]_ [#lan_as_wan]_
+  - FRITZ!Repeater 1200 [#eva_ramboot]_
+
+* Extreme Networks
+
+  - WS-AP3915i
+
+* GL.iNet
+
+  - GL-AP1300
+  - GL-B1300
+
+* Linksys
+
+  - EA6350 (v3)
+
+* NETGEAR
+
+  - EX6100 (v2)
+  - EX6150 (v2)
+
+* OpenMesh
+
+  - A42
+  - A62
+
+* Plasma Cloud
+
+  - PA1200
+  - PA2200
+
+* Zyxel
+
+  - NBG6617
+
+ipq40xx-mikrotik
+----------------
+
+* Mikrotik
+
+  - DISC Lite5 ac (RBDiscG-5acD)
+  - hAP ac2
+  - SXTsq 5 ac (RBSXTsqG-5acD)
+
+ipq806x-generic
+---------------
+
+* NETGEAR
+
+  - R7800
+
+* Ubiquiti
+
+  - UniFi AC HD
+
+lantiq-xrx200
+-------------
+
+* Arcadyan
+
+  - VGV7510KW22 (o2 Box 6431)
+
+* AVM
+
+  - FRITZ!Box 7360 (v1, v2) [#avmflash]_ [#lan_as_wan]_
+  - FRITZ!Box 7360 SL [#avmflash]_ [#lan_as_wan]_
+  - FRITZ!Box 7362 SL [#eva_ramboot]_ [#lan_as_wan]_
+  - FRITZ!Box 7412 [#eva_ramboot]_
+
+lantiq-xrx200_legacy
+--------------------
+
+* TP-Link
+
+  - TD-W8970 (v1) [#lan_as_wan]_
+
+lantiq-xway
+-----------
+
+* AVM
+
+  - FRITZ!Box 7312 [#avmflash]_
+
+* NETGEAR
+
+  - DGN3500B [#lan_as_wan]_
+
+mediatek-filogic
+----------------
+
+* ASUS
+
+  - RT-AX52
+  - TUF AX4200
+  - TUF AX6000
+
+* Cudy
+
+  - AP3000 Outdoor (v1)
+  - TR3000 (v1)
+  - WR3000 (v1)
+
+* D-Link
+
+  - AQUILA PRO AI M30 A1
+  - AQUILA PRO AI M60 A1
+
+* GL.iNet
+
+  - GL-MT2500
+  - GL-MT3000
+
+* NETGEAR
+
+  - WAX220
+
+* OpenWrt
+
+  - One
+
+* Ubiquiti
+
+  - UniFi 6 Plus
+
+* Zyxel
+
+  - NWA50AX Pro
+
+mediatek-mt7622
+---------------
+
+* Linksys
+
+  - E8450
+
+* Ubiquiti
+
+  - UniFi 6 LR (v1)
+
+mpc85xx-p1010
+-------------
+
+* Enterasys
+
+  - WS-AP3715i
+
+* Sophos
+
+  - RED 15w Rev.1
+
+* TP-Link
+
+  - TL-WDR4900 (v1)
+
+mpc85xx-p1020
+---------------
+
+* Aerohive
+
+  - HiveAP 330
+
+* Enterasys
+
+  - WS-AP3710i
+
+* Extreme Networks
+
+  - WS-AP3825i
+
+* Hewlett-Packard
+
+  - MSM460
+
+* Ocedo
+
+  - Panda
+
+ramips-mt7620
+-------------
+
+* ASUS
+
+  - RT-AC51U
+
+* GL.iNet
+
+  - GL-MT300A
+  - GL-MT300N
+  - GL-MT750
+
+* NETGEAR
+
+  - EX3700
+  - EX3800
+  - EX6130
+
+* Nexx
+
+  - WT3020AD/F/H
+
+* TP-Link
+
+  - Archer C2 (v1)
+  - Archer C20 (v1)
+  - Archer C20i
+  - Archer C50 (v1)
+
+* Xiaomi
+
+  - MiWiFi Mini
+
+ramips-mt7621
+-------------
+
+* ASUS
+
+  - RT-AC57U (v1)
+  - RT-AX53U
+
+* Cudy
+
+  - WR1300 (v1)
+  - WR2100
+  - X6 (v1, v2)
+
+* D-Link
+
+  - COVR-X1860 (A1)
+  - DAP-X1860 (A1)
+  - DIR-860L (B1)
+  - DIR-878 (A1)
+  - DIR-882 (A1)
+
+* Genexis
+
+  - Pulse EX400
+
+* GL.iNet
+
+  - GL-MT1300
+
+* MERCUSYS
+
+  - MR70X (v1)
+
+* NETGEAR
+
+  - EX6150 (v1)
+  - R6220
+  - R6260
+  - WAC104
+  - WAX202
+
+* TP-Link
+
+  - EAX11 (v2)
+  - EAX12
+  - EAX15 (v2)
+  - EAP615-Wall (v1)
+  - RE500 (v1)
+  - RE650 (v1)
+
+* Ubiquiti
+
+  - UniFi 6 Lite
+  - UniFi nanoHD
+
+* Wavlink
+
+  - WS-WN572HP3 (4G)
+
+* Xiaomi
+
+  - Xiaomi Mi Router 3G (v1, v2)
+  - Xiaomi Mi Router 4A (Gigabit Edition v1, v2)
+
+* Zbtlink
+
+  - WG3526-16M
+  - WG3526-32M
+
+* Zyxel
+
+  - NWA50AX
+  - WSM20
+
+ramips-mt76x8
+-------------
+
+* Cudy
+
+  - TR1200 (v1)
+  - WR1000 (v1)
+
+* GL.iNet
+
+  - GL-MT300N (v2)
+  - microuter-N300
+  - VIXMINI
+
+* NETGEAR
+
+  - R6020
+  - R6120
+
+* RAVPower
+
+  - RP-WD009
+
+* TP-Link
+
+  - Archer C20 (v4, v5)
+  - Archer C50 (v3, v4)
+  - RE200 (v2, v3, v4)
+  - TL-MR3020 (v3)
+  - TL-MR3420 (v5)
+  - TL-MR6400 (v5)
+  - TL-WA801ND (v5)
+  - TL-WR841N (v13)
+  - TL-WR902AC (v3, v4)
+
+* VoCore
+
+  - VoCore2
+
+* Xiaomi
+
+  - Xiaomi Mi Router 4A (100M Edition) - MIR4A
+  - Xiaomi Mi Router 4A (100M International Edition) - R4AC
+  - Xiaomi Mi Router 4A (100M International Edition v2) - R4ACv2
+  - Xiaomi Mi Router 4C - R4CM
+
+rockchip-armv8
+--------------
+
+* FriendlyElec
+
+  - NanoPi R2S
+  - NanoPi R3S
+  - NanoPi R4S (4GB LPDDR4)
+
+sunxi-cortexa7
+--------------
+
+* LeMaker
+
+  - Banana Pi M1
+
+x86-generic
+-----------
+
+* x86-generic
+* x86-virtualbox
+* x86-vmware
+
+See also: :doc:`x86`
+
+x86-geode
+---------
+
+* x86-geode
+
+See also: :doc:`x86`
+
+x86-64
+------
+
+* x86-64-generic
+* x86-64-virtualbox
+* x86-64-vmware
+
+See also: :doc:`x86`
+
+Footnotes
+---------
+
+.. [#avmflash]
+  For instructions on how to flash AVM devices, visit https://fritz-tools.readthedocs.io
+
+.. [#eva_ramboot]
+  For instructions on how to flash AVM NAND devices, see the respective
+  commit which added support in OpenWrt.
+
+.. [#lan_as_wan]
+  All LAN ports on this device are used as WAN.
+
+.. [#missing_radios]
+  This device contains more than two WLAN radios, which is currently
+  unsupported by Gluon. Only the first two radios will work.
+
+.. [#modular_ethernet]
+  These devices follow a modular principle,
+  which means even basic functionality like ethernet is provided by an expansion-board,
+  that may not be bundled with the device itself.
+  Such expansions are recommended for the config mode, but are not strictly necessary,
+  as exposed serial ports may grant sufficient access as well.
--- a/docs/user/x86.rst
+++ b/docs/user/x86.rst
@@ -9,21 +9,26 @@ Targets

 The following targets for x86 images exist:

-`x86-generic`
-    Generic x86 support with many different ethernet drivers; should run on
-    most x86 systems.
+`x86-64`
+    Generic x86 64-bit support with many different ethernet drivers; should run on
+    most x86 systems with 64-bit support.

    There are three images:

-    * `generic` (compressed "raw" image, can written to a disk directly or booted with qemu)
+    * `generic` (compressed "raw" image, can be written to a disk directly or booted with qemu)
    * `virtualbox` (VDI image)
    * `vmware` (VMDK image)

-    These images only differ in the image file format, the content is the same. Therefore there is
-    only a single `x86-generic` sysupgrade image instead of three.
+    These images differ in the image file format, the content is the same. Therefore
+    a single `x86-64` sysupgrade image is provided, only.
+
+`x86-generic`
+    32-bit version of `x86-64` for hardware not supporting 64-bit images.
+    Also comes with `virtualbox` and `vmware` factory installs.

 `x86-geode`
    x86 image for Geode CPUs.

-`x86-64`
-    64bit version of `x86-generic`.
+`x86-legacy`
+    x86 image for very old PC hardware like i586.
+
--- a/modules
+++ b/modules
-GLUON_FEEDS='openwrt gluon routing luci'
+GLUON_FEEDS='gluon packages routing'

-LEDE_REPO=https://git.openwrt.org/openwrt/openwrt.git
-LEDE_BRANCH=lede-17.01
-LEDE_COMMIT=b6a1f43075f96b0028e33ed1af1fe31068791d24
-
-PACKAGES_OPENWRT_REPO=https://github.com/openwrt/packages.git
-PACKAGES_OPENWRT_BRANCH=lede-17.01
-PACKAGES_OPENWRT_COMMIT=338690b2f79e2c7090be4e9adbb19b452c9e3c36
+OPENWRT_REPO=https://github.com/openwrt/openwrt.git
+OPENWRT_BRANCH=openwrt-24.10
+OPENWRT_COMMIT=e709e9bc067f0e97f9ccc43fdec451ff83bba2d5

 PACKAGES_GLUON_REPO=https://github.com/freifunk-gluon/packages.git
-PACKAGES_GLUON_COMMIT=be2c35785994e443d895225c7240474a46f64f5e
+PACKAGES_GLUON_COMMIT=bae34a0f53b25dbd691c57c8ab2d0b7cfe811517

-PACKAGES_ROUTING_REPO=https://github.com/openwrt-routing/packages.git
-PACKAGES_ROUTING_BRANCH=openwrt-18.06
-PACKAGES_ROUTING_COMMIT=1b9d1c419f0ecefda51922a7845ab2183d6acd76
+PACKAGES_PACKAGES_REPO=https://github.com/openwrt/packages.git
+PACKAGES_PACKAGES_BRANCH=openwrt-24.10
+PACKAGES_PACKAGES_COMMIT=acd385976da5bd26c8837e847b76146a3c1b8ad7

-PACKAGES_LUCI_REPO=https://github.com/openwrt/luci.git
-PACKAGES_LUCI_BRANCH=lede-17.01
-PACKAGES_LUCI_COMMIT=1f014bd2180b364bec4c3f6457f72a0621884f9a
+PACKAGES_ROUTING_REPO=https://github.com/openwrt/routing.git
+PACKAGES_ROUTING_BRANCH=openwrt-24.10
+PACKAGES_ROUTING_COMMIT=f2ee837d3714f86e9d636302e9f69612c71029cb
--- a/overlay/opkg.mk
+++ b/overlay/opkg.mk
-# LEDE doesn't have a nice way to set the list of feeds in
-# /etc/opkg/distfeeds.conf, so we use this overlay file (which is included by
-# the opkg package Makefile though LEDE's IncludeOverlay mechanism).
-
-# The following definitions make /etc/opkg/distfeeds.conf match the one included
-# in official LEDE builds (by default, FEEDS_DISABLED contains the original list
-# of feeds (which are unused by Gluon), and FEEDS_ENABLED our own feed list).
-
-FEEDS_ENABLED := $(FEEDS_DISABLED)
-FEEDS_DISABLED :=
--- a/package/features
+++ b/package/features
-nodefault 'web-wizard'
+-- Feature definition file
+--
+-- See the page `dev/packages` (Developer Documentation / Package development)
+-- in the `docs` directory or on gluon.readthedocs.io for information on the
+-- file format

-packages 'web-wizard' \
-	'gluon-config-mode-hostname' \
-	'gluon-config-mode-geo-location' \
-	'gluon-config-mode-contact-info'

-packages 'web-wizard & autoupdater' \
-	'gluon-config-mode-autoupdater'
+feature('web-wizard', {
+	'gluon-config-mode-hostname',
+	'gluon-config-mode-geo-location',
+	'gluon-config-mode-contact-info',
+	'gluon-config-mode-outdoor',
+})

-packages 'web-wizard & (mesh-vpn-fastd | mesh-vpn-tunneldigger)' \
-	'gluon-config-mode-mesh-vpn'
+when(_'web-wizard' and _'autoupdater', {
+	'gluon-config-mode-autoupdater',
+})

+when(_'web-wizard' and (
+	_'mesh-vpn-fastd' or
+	_'mesh-vpn-fastd-l2tp' or
+	_'mesh-vpn-wireguard'
+), {
+	'gluon-config-mode-mesh-vpn',
+})

-nodefault 'web-advanced'

-packages 'web-advanced' \
-	'gluon-web-admin' \
-	'gluon-web-network' \
-	'gluon-web-wifi-config'
+feature('web-advanced', {
+	'gluon-web-admin',
+	'gluon-web-network',
+	'gluon-web-wifi-config',
+})

-packages 'web-advanced & autoupdater' \
-	'gluon-web-autoupdater'
+when(_'web-advanced' and _'autoupdater', {
+	'gluon-web-autoupdater',
+})

-packages 'status-page & (mesh-batman-adv-14 | mesh-batman-adv-15)' \
-        'gluon-status-page-mesh-batman-adv'
+
+when(_'mesh-batman-adv-15', {
+	'gluon-ebtables-limit-arp',
+	'gluon-radvd',
+})
+
+when(_'status-page' and _'mesh-batman-adv-15', {
+	'gluon-status-page-mesh-batman-adv',
+})
+
+
+when(_'mesh-olsrd', {
+	'gluon-radvd',
+})
+
+
+when(not _'wireless-encryption-wpa3', {
+	'hostapd-mini',
+})
--- a/package/gluon-alfred/Makefile
+++ b/package/gluon-alfred/Makefile
 include $(TOPDIR)/rules.mk

 PKG_NAME:=gluon-alfred
-PKG_VERSION:=1
-PKG_RELEASE:=1

 include ../gluon.mk


--- a/package/gluon-alfred/files/lib/gluon/reload.d/301-alfred-stop
+++ b/package/gluon-alfred/files/lib/gluon/reload.d/301-alfred-stop
+#!/bin/sh
+/etc/init.d/alfred stop
--- a/package/gluon-alfred/files/lib/gluon/reload.d/799-alfred-start
+++ b/package/gluon-alfred/files/lib/gluon/reload.d/799-alfred-start
+#!/bin/sh
+/etc/init.d/alfred start
--- a/package/gluon-alfred/files/usr/lib/autoupdater/abort.d/60gluon-alfred
+++ b/package/gluon-alfred/files/usr/lib/autoupdater/abort.d/60gluon-alfred
 #!/bin/sh

+# shellcheck source=package/gluon-autoupdater/files/lib/gluon/autoupdater/lib.sh
 . /lib/gluon/autoupdater/lib.sh

-
 start_enabled alfred
--- a/package/gluon-alfred/files/usr/lib/autoupdater/download.d/40gluon-alfred
+++ b/package/gluon-alfred/files/usr/lib/autoupdater/download.d/40gluon-alfred
 #!/bin/sh

+# shellcheck source=package/gluon-autoupdater/files/lib/gluon/autoupdater/lib.sh
 . /lib/gluon/autoupdater/lib.sh

-
 stop alfred
--- a/package/gluon-authorized-keys/Makefile
+++ b/package/gluon-authorized-keys/Makefile
 include $(TOPDIR)/rules.mk

 PKG_NAME:=gluon-authorized-keys
-PKG_VERSION:=2

 include ../gluon.mk

 define Package/gluon-authorized-keys
  TITLE:=Fill /etc/dropbear/authorized_keys from site.conf
-  DEPENDS:=+gluon-core
+  DEPENDS:=+gluon-core +gluon-lock-password
 endef

 $(eval $(call BuildPackageGluon,gluon-authorized-keys))
No results found