docs/features/configmode.rst

@@ -14,10 +14,13 @@ Activating Config Mode
 ----------------------
 
 Config Mode is automatically entered at the first boot. You can re-enter
-Config Mode by pressing and holding the RESET/WPS button for about three
-seconds. The device should reboot (all LEDs will turn of briefly) and 
+Config Mode by pressing and holding the RESET/WPS/DECT button for about three
+seconds. The device should reboot (all LEDs will turn off briefly) and
 Config Mode will be available.
 
+If you have access to the console of the node, there is the
+``gluon-enter-setup-mode`` command, which reboots a node into Config Mode.
+
 
 Port Configuration
 ------------------

docs/features/dns-cache.rst

+.. _dns-caching:
+
+DNS caching
+===========
+
+User experience may be greatly improved when dns is accelerated. Also, it
+seems like a good idea to keep the number of packages being exchanged
+between node and gateway as small as possible. In order to do this, a
+DNS cache may be used on a node. The dnsmasq instance listening on port
+53 on the node will be reconfigured to answer requests, use a list of
+upstream servers and a specific cache size if the options listed below are
+added to site.conf. Upstream servers are the DNS servers which are normally
+used by the nodes to resolve hostnames (e.g. gateways/supernodes).
+
+There are the following settings:
+    servers
+    cacheentries
+
+To use the node's DNS server, both options should be set. The node will cache at
+most 'cacheentries' many DNS records in RAM. The 'servers' list will be used to
+resolve the received DNS queries if the request cannot be answered from
+cache. Gateways should announce the "next node" address via DHCP and RDNSS (if
+any). Note that not setting 'servers' here will lead to DNS not working: Once
+the gateways all announce the "next node" address for DNS, there is no way for
+nodes to automatically determine DNS servers. They have to be baked into the
+firmware.
+
+If these settings do not exist, the cache is not initialized and RAM usage will
+not increase.
+
+When next_node.name is set, an A record and an AAAA record for the
+next-node IP address are placed in the dnsmasq configuration. This means that
+the content of next_node.name may be resolved even without upstream connectivity.
+It is suggested to use the same name as the DNS server provides:
+e.g. nextnode.location.community.example.org (This way the name also works if a
+client uses static DNS Servers). Hint: If next_node.name does not contain a dot
+some browsers would open the searchpage instead.
+
+::
+
+  dns = {
+    cacheentries = 5000,
+    servers = { '2001:4860:4860::8888', '2001:4860:4860::8844' },
+  },
+
+  next_node = {
+    name = { 'nextnode.location.community.example.org', 'nextnode', 'nn' },
+    ip6 = '2001:db8:8::1',
+    ip4 = '198.51.100.1',
+  }
+
+
+Each cache entry will occupy about 90 bytes of RAM.

docs/features/dns-forwarder.rst

-DNS forwarder
-=============
-
-A Gluon node can be configured to act as a DNS forwarder. Requests for the
-next-node hostname(s) can be answered locally, without querying the upstream
-resolver.
-
-**Note:** While this reduces answer time and allows to use the next-node
-hostname without upstream connectivity, this feature should not be used for
-next-node hostnames that are FQDN when the zone uses DNSSEC.
-
-One or more upstream resolvers can be configured in the *dns.servers* setting.
-When *next_node.name* is set, A and/or AAAA records for the next-node IP
-addresses are placed in the dnsmasq configuration.
-
-::
-
-  dns = {
-    servers = { '2001:db8::1', },
-  },
-
-  next_node = {
-    name = { 'nextnode.location.community.example.org', 'nextnode', 'nn' },
-    ip6 = '2001:db8:8::1',
-    ip4 = '198.51.100.1',
-  }

docs/features/monitoring.rst

@@ -24,7 +24,7 @@ Information to be announced is currently split into three categories:
     interfaces. This data can be used to determine the network topology.
 
 All categories will have a ``node_id`` key. It should be used to
-relate data of different catagories.
+relate data of different categories.
 
 Accessing Node Information
 --------------------------
@@ -47,7 +47,7 @@ installed. Please note that at least one alfred daemon is required to run as
 
 .. _alfred-json: https://github.com/ffnord/alfred-json
 
-The following datatypes are used:
+The following data types are used:
 
 * `nodeinfo`: 158
 * `statistics`: 159
@@ -104,7 +104,8 @@ gluon-respondd
 
 `gluon-respondd` allows querying neighbouring nodes for their information.
 It is a daemon listening on the multicast address ``ff02::2:1001`` on
-UDP port 1001 on both the bare mesh interfaces and `br-client`. Unicast
+UDP port 1001 on the mesh interface and on the multicast address
+``ff05::2:1001`` on the `br-client` interface. Unicast
 requests are supported as well.
 
 The supported requests are:
@@ -117,13 +118,13 @@ The supported requests are:
 gluon-neighbour-info
 ~~~~~~~~~~~~~~~~~~~~
 
-The programm `gluon-neighbour-info` can be used to retrieve
+The program `gluon-neighbour-info` can be used to retrieve
 information from other nodes.
 
 ::
 
-  gluon-neighbour-info -i wlan0 \
-  -p 1001 -d ff02:0:0:0:0:0:2:1001 \
+  gluon-neighbour-info -i bat0 \
+  -p 1001 -d ff05:0:0:0:0:0:2:1001 \
   -r nodeinfo
 
 An optional timeout may be specified, e.g. `-t 5` (default: 3 seconds). See

docs/features/multidomain.rst

@@ -21,18 +21,18 @@ Overview
 Multidomain support allows to build a single firmware with multiple,
 switchable domain configurations. The nomenclature is as follows:
 
--  ``site``: an aggregate over multiple domains
--  ``domain``: mesh network with connectivity parameters that prevent
-   accidental bridging with other domains
--  ``domain code``: unique domain identifier
--  ``domain name``: pretty name for a domain code
+- ``site``: an aggregate over multiple domains
+- ``domain``: mesh network with connectivity parameters that prevent
+  accidental bridging with other domains
+- ``domain code``: unique domain identifier
+- ``domain name``: pretty name for a domain code
 
 By default Gluon builds firmware with a single domain embedded into
 ``site.conf``. To use multiple domains, enable it in ``site.mk``:
 
 ::
 
-    GLUON_MULTIDOMAIN=1
+  GLUON_MULTIDOMAIN=1
 
 In the site repository, create the ``domains/`` directory, which will
 hold your domain configurations. Each domain configuration file is named
@@ -41,26 +41,26 @@ supported.
 
 ::
 
-    site/
-    |-- site.conf
-    |-- site.mk
-    |-- i18n/
-    |-- domains/
-      |-- alpha_centauri.conf
-      |-- beta_centauri.conf
-      |-- gamma_centauri.conf
+  site/
+  |-- site.conf
+  |-- site.mk
+  |-- i18n/
+  |-- domains/
+    |-- alpha_centauri.conf
+    |-- beta_centauri.conf
+    |-- gamma_centauri.conf
 
 The domain configuration ``alpha_centauri.conf`` could look like this.
 
 ::
 
-    {
-      domain_names = {
-        alpha_centauri = 'Alpha Centauri'
-      },
+  {
+    domain_names = {
+      alpha_centauri = 'Alpha Centauri'
+    },
 
-      -- more domain specific config follows below
-    }
+    -- more domain specific config follows below
+  }
 
 In this example “Alpha Centauri” is the user-visible ``domain_name`` for the
 domain_code ``alpha_centauri``. Also note that the domain code
@@ -88,18 +88,25 @@ domain of a router, if and only if one of the above conditions matches.
 Switching the domain
 --------------------
 
-**via commandline**:
+Via commandline
+^^^^^^^^^^^^^^^
 
 ::
 
-    uci set gluon.core.domain="newdomaincode"
-    gluon-reconfigure
-    reboot
+  gluon-switch-domain 'newdomaincode'
 
-**via config mode:**
+When the node is not in config mode, ``gluon-switch-domain`` will automatically
+reboot the node by default. This can be suppressed by passing ``--no-reboot``::
 
-To allow switching the domain via config mode, ``config-mode-domain-select``
-has to be added to GLUON_FEATURES in the site.mk.
+  gluon-switch-domain --no-reboot 'newdomaincode'
+
+Switching the domain without reboot is currently **experimental**.
+
+Via config mode
+^^^^^^^^^^^^^^^
+
+To allow switching the domain via config mode, add ``config-mode-domain-select``
+to the enabled features in the image-customization.lua file.
 
 |image0|
 
@@ -116,119 +123,113 @@ site or domain context.
 site.conf only variables
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
--  Used in as initial default values, when the firmware was just flashed
-   and/or the config mode is skipped, so they do not make sense in a
-   domain specific way:
-
-   -  authorized_keys
-   -  default_domain
-   -  poe_passthrough
-   -  mesh_on_wan
-   -  mesh_on_lan
-   -  single_as_lan
-   -  setup_mode.skip
-   -  autoupdater.branch
-   -  mesh_vpn.enabled
-   -  mesh_vpn.pubkey_privacy
-   -  mesh_vpn.bandwidth_limit
-   -  mesh_vpn.bandwidth_limit.enabled
-   -  mesh_vpn.bandwidth_limit.ingress
-   -  mesh_vpn.bandwidth_limit.egress
-
--  Variables that influence the appearance of the config mode,
-   domain-independent because they are relevant before a domain was selected.
-
-   -  config_mode.geo_location.show_altitude
-   -  config_mode.hostname.optional
-   -  config_mode.remote_login
-   -  config_mode.remote_login.show_password_form
-   -  config_mode.remote_login.min_password_length
-   -  hostname_prefix
-   -  mesh_vpn.fastd.configurable
-   -  roles.default
-   -  roles.list
-
--  Specific to a firmware build itself:
-
-   -  site_code
-   -  site_name
-   -  autoupdater.branches.*.name
-   -  autoupdater.branches.*.good_signatures
-   -  autoupdater.branches.*.pubkeys
-
--  We simply do not see any reason, why these variables could be helpful
-   in a domain specific way:
-
-   -  mesh_vpn.fastd.syslog_level
-   -  wifi*.supported_rates
-   -  wifi*.basic_rates
-   -  timezone
-   -  regdom
+- Used in as initial default values, when the firmware was just flashed
+  and/or the config mode is skipped, so they do not make sense in a
+  domain specific way:
+
+  - authorized_keys
+  - default_domain
+  - poe_passthrough
+  - interfaces.*.default_roles
+  - setup_mode.skip
+  - autoupdater.branch
+  - mesh_vpn.enabled
+  - mesh_vpn.pubkey_privacy
+  - mesh_vpn.bandwidth_limit
+  - mesh_vpn.bandwidth_limit.enabled
+  - mesh_vpn.bandwidth_limit.ingress
+  - mesh_vpn.bandwidth_limit.egress
+
+- Variables that influence the appearance of the config mode,
+  domain-independent because they are relevant before a domain was selected.
+
+  - config_mode.geo_location.show_altitude
+  - config_mode.hostname.optional
+  - config_mode.remote_login
+  - config_mode.remote_login.show_password_form
+  - config_mode.remote_login.min_password_length
+  - hostname_prefix
+  - mesh_vpn.fastd.configurable
+  - roles.default
+  - roles.list
+
+- Specific to a firmware build itself:
+
+  - site_code
+  - site_name
+  - autoupdater.branches.*.name
+  - autoupdater.branches.*.good_signatures
+  - autoupdater.branches.*.pubkeys
+
+- We simply do not see any reason, why these variables could be helpful
+  in a domain specific way:
+
+  - mesh_vpn.fastd.syslog_level
+  - timezone
+  - regdom
 
 domain.conf only variables
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
--  Obviously:
+- Obviously:
 
-   -  domain_names
+  - domain_names
 
-      -  a table of domain codes to domain names
-         ``domain_names = { foo = 'Foo Domain', bar = 'Bar Domain', baz = 'Baz Domain' }``
+    - a table of domain codes to domain names
+      ``domain_names = { foo = 'Foo Domain', bar = 'Bar Domain', baz = 'Baz Domain' }``
 
-   -  hide_domain
+  - hide_domain
 
-      -  prevents a domain name(s) from appearing in config mode, either
-         boolean or array of domain codes
+    - prevents a domain name(s) from appearing in config mode, either
+      boolean or array of domain codes
 
-         -  ``true``, ``false``
-         -  ``{ 'foo', 'bar' }``
+      - ``true``, ``false``
+      - ``{ 'foo', 'bar' }``
 
--  Because each domain is considered as an own layer 2 network, these
-   values should be different in each domain:
+- Because each domain is considered a separate layer 2 network, these
+  values should be different in each domain:
 
-   -  next_node.ip4
-   -  next_node.ip6
-   -  next_node.name
-   -  prefix6
-   -  prefix4
-   -  extra_prefixes6
+  - next_node.ip4
+  - next_node.ip6
+  - next_node.name
+  - prefix6
+  - prefix4
+  - extra_prefixes6
 
--  To prevent accidential bridging of different domains, all meshing
-   technologies should be seperated:
+- To prevent accidental bridging of different domains, all meshing
+  technologies should be separated:
 
-   -  domain_seed (wired mesh)
+  - domain_seed (wired mesh)
 
-      -  must be a random value used to derive the vxlan id for wired meshing
+    - must be a random value used to derive the vxlan id for wired meshing
 
-   -  wifi*.ibss.ssid
-   -  wifi*.ibss.bssid
-   -  wifi*.mesh.id
-   -  mesh_vpn.fastd.groups.*.peers.remotes
-   -  mesh_vpn.fastd.groups.*.peers.key
-   -  mesh_vpn.tunneldigger.brokers
+  - wifi*.mesh.id
+  - mesh_vpn.fastd.groups.*.peers.remotes
+  - mesh_vpn.fastd.groups.*.peers.key
+  - mesh_vpn.tunneldigger.brokers
 
--  Clients consider WiFi networks sharing the same ESSID as if they were
-   the same L2 network and try to reconfirm and reuse previous
-   addressing. If multiple neighbouring domains shared the same ESSID,
-   the roaming experience of clients would degrade.
+- Clients consider WiFi networks sharing the same ESSID as if they were
+  the same L2 network and try to reconfirm and reuse previous
+  addressing. If multiple neighbouring domains shared the same ESSID,
+  the roaming experience of clients would degrade.
 
-   -  wifi*.ap.ssid
+  - wifi*.ap.ssid
 
--  Some values should be only set in legacy domains and not in new domains.
+- Some values should be only set in legacy domains and not in new domains.
 
-   -  mesh.vxlan
+  - mesh.vxlan
 
-      -  By default, this value is `true`. It should be only set to `false`
-         for one legacy domain, since vxlan prevents accidental wired
-         merges of domains. For old domains this value is still available
-         to keep compatibility between all nodes in one domain.
+    - By default, this value is `true`. It should be only set to `false`
+      for one legacy domain, since vxlan prevents accidental wired
+      merges of domains. For old domains this value is still available
+      to keep compatibility between all nodes in one domain.
 
-   -  next_node.mac
+  - next_node.mac
 
-      -  For new domains, the default value should be used, since there is
-         no need for a special mac (or domain specific mac). For old domains
-         this value is still available to keep compatibility between all
-         nodes in one domain.
+    - For new domains, the default value should be used, since there is
+      no need for a special mac (or domain specific mac). For old domains
+      this value is still available to keep compatibility between all
+      nodes in one domain.
 
 Example config
 --------------

docs/features/private-wlan.rst

 Private WLAN
 ============
 
-It is possible to set up a private WLAN that bridges the WAN port and is seperated from the mesh network.
-Please note that you should not enable ``mesh_on_wan`` simultaneously.
+It is possible to set up a private WLAN that bridges the uplink port and is separated from the mesh network.
+Please note that you should not enable Wired Mesh on the uplink port at the same time.
+
+The private WLAN is encrypted using WPA2 by default. On devices with enough flash and a supported radio,
+WPA3 or WPA2/WPA3 mixed-mode can be used instead of WPA2. For this to work, the ``wireless-encryption-wpa3``
+feature has to be enabled as a feature.
+
+It is recommended to enable IEEE 802.11w management frame protection for WPA2/WPA3 networks, however this
+can lead to connectivity problems for older clients. In this case, management frame protection can be
+made optional or completely disabled in the advanced settings tab.
 
 The private WLAN can be enabled through the config mode if the package ``gluon-web-private-wifi`` is installed.
 You may also enable a private WLAN using the command line::
@@ -19,7 +27,7 @@ You may also enable a private WLAN using the command line::
   uci set wireless.wan_radio$RID.ssid="$SSID"
   uci set wireless.wan_radio$RID.key="$KEY"
   uci set wireless.wan_radio$RID.disabled=0
-  uci set wireless.wan_radio$RID.macaddr="$($(echo "lua -e print(require('gluon.util').generate_mac(3+4*$RID))"))"
+  uci set wireless.wan_radio$RID.macaddr=$(lua -e "print(require('gluon.util').generate_mac(3+4*$RID))")
   uci commit
   wifi
 

docs/features/roles.rst

@@ -2,8 +2,8 @@ Roles
 =====
 
 It is possible to define a set of roles you want to distinguish at backend side. One node can own one
-role which it will announce via alfred inside the mesh. This will make it easier to differentiate
-nodes when parsing alfred data. E.g to count only **normal** nodes and not the gateways
+role which it will announce via respondd/announced inside the mesh. This will make it easier to differentiate
+nodes when parsing respondd data. E.g to count only **normal** nodes and not the gateways
 or servers (nodemap). A lot of things are possible.
 
 For this the section ``roles`` in ``site.conf`` is needed::
@@ -28,7 +28,7 @@ If you want node owners to change the defined roles via config-mode you can add
 
 The role is saved in ``gluon-node-info.system.role``. To change the role using command line do::
 
-  uci set gluon-node-info.system.role="$ROLE"
+  uci set gluon-node-info.@system[0].role="$ROLE"
   uci commit
 
 Please replace ``$ROLE`` by the role you want the node to own.

docs/features/vpn.rst

-Mesh-VPN
+Mesh VPN
 ========
 
-Gluon integrates several OSI-Layer 2 tunneling protocols to
-enable interconnects between local meshes and provide
-internetwork access. Available protocols currently are:
+Gluon integrates several layer 2 tunneling protocols to
+allow connections between local meshes through the internet.
 
-- fastd
-- L2TPv3 (via tunneldigger)
+Protocol handlers
+^^^^^^^^^^^^^^^^^
 
-fastd is a lightweight userspace tunneling daemon, that
+There are currently three protocol handlers which can be selected
+as a feature:
+
+mesh-vpn-fastd
+""""""""""""""
+
+fastd is a lightweight userspace tunneling daemon that
 implements cipher suites that are specifically designed
 to work well on embedded devices. It offers encryption
-and authentication. Its primary drawback are the necessary
-context-switches when forwarding packets.
-
-L2TPv3 is an in-kernel tunneling protocol that performs well,
-but offers no security properties by itself.
-The brokering of the tunnel happens through tunneldigger,
-its primary drawback being the lack of IPv6 support.
+and authentication.
+The primary drawback of fastd's encrypted connection modes
+is the necessary context switches when forwarding packets.
+A kernel-supported L2TPv3 offloading option is available to
+work around the context-switching bottleneck, but it comes
+at the cost of losing the ability to protect tunnel connections
+against eavesdropping or manipulation.
+
+mesh-vpn-tunneldigger
+"""""""""""""""""""""
+
+Tunneldigger always uses L2TPv3, generally achieving the same
+performance as fastd with the ``null@l2tp`` method, but offering
+no security.
+Tunneldigger's primary drawback is the lack of IPv6 support.
+It also provides less configurability than fastd.
+
+mesh-vpn-wireguard
+""""""""""""""""""
+
+WireGuard is an encrypted in-kernel tunneling protocol that
+provides encrypted transmission and at the same time offers
+high throughput.
 
 fastd
------
+^^^^^
 
-Configurable Cipher
-^^^^^^^^^^^^^^^^^^^
+.. _VPN fastd methods:
 
+Methods
+"""""""
 
-From the site configuration fastd can be allowed to offer
-toggleable encryption in the config mode with the intent to
-increase throughput, although in practice the gain is minimal.
+fastd offers various different connection "methods" with different
+security properties that can be configured in the site configuration.
 
-**Site configuration:**
+The following methods are currently recommended:
 
-1) Add the feature ``web-mesh-vpn-fastd`` in ``site.mk``
-2) Set ``mesh_vpn.fastd.configurable = true`` in ``site.conf``
-3) Optionally add ``null`` to the ``mesh_vpn.fastd.methods`` table if you want "Performance mode" as default (not recommended)
+- ``salsa2012+umac``: Encrypted + authenticated
+- ``null+salsa2012+umac``: Unencrypted, authenticated
+- ``null@l2tp``: Unencrypted, unauthenticated
 
-**Gateway configuration:**
+Multiple methods can be listed in ``site.conf``. The first listed method
+supported by both the node and its peer will be used.
 
-1) Prepend the ``null`` cipher in fastd's method list
+The use of the ``null@l2tp`` method with offloading enabled can provide a
+considerable performance gain, especially on weaker embedded hardware.
+For L2TP offloading, the ``mesh-vpn-fastd-l2tp`` feature needs to be enabled in
+``site.mk``.
 
 
-**Config Mode:**
-The resulting firmware will allow users to choose between secure (encrypted) and fast (unencrypted) transport.
+.. _vpn-gateway-configuration:
 
-.. image:: fastd_mode.gif
+Gateway / Supernode Configuration
+"""""""""""""""""""""""""""""""""
+
+When only using the ``null`` or ``null@l2tp`` methods without offloading,
+simply add these methods to the front of the method list. ``null@l2tp``
+should always appear before ``null`` in the configuration when both are enabled.
+fastd v22 or newer is needed for the ``null@l2tp`` method.
+
+It is often not necessary to enable L2TP offloading on supernodes for
+performance reasons. Nodes using offloading can communicate with supernodes that
+don't use offloading as long as both use the ``null@l2tp`` method.
+
+
+.. _vpn-gateway-configuration-offloading:
+
+Offloading on Gateways / Supernodes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To enable L2TP offloading on the supernodes, it is recommended to study the
+fastd documentation section pertaining to the `offload configuration option
+<https://fastd.readthedocs.io/en/stable/manual/config.html#option-offload>`_.
+
+However, the important changes to the fastd config on your Supernode are:
+
+    - | Set ``mode multitap;``
+      | Every peer gets their own interface.
+
+    - | Replace ``interface "foo":`` with ``interface "peer-%k";``
+      | ``%k`` is substituted for a portion of the peers public key.
+
+    - | Set ``offload l2tp yes;``
+      | This tells fastd to use the l2tp kernel module.
 
-**Unix socket:**
-To confirm whether the correct cipher is being used, fastds unix
-socket can be interrogated, after installing for example `socat`.
+    - | Set ``persist interface no;``
+      | This tells fastd to only keep interfaces around while the connection is active.
 
-::
+Note that in ``multitap`` mode, which is required when using L2TP offloading,
+fastd will create one interface per peer on the supernode's. This allows
+offloading the L2TP forwarding into the kernel space. But this also means added
+complexity with regards to handling those interfaces.
+
+There are two main options on how you can handle this:
+
+    -  create ``on up`` and ``on down`` hooks
+
+        - to handle interface setup and destruction
+        - preferably using the async keyword, so hooks are not blocking fastd
+
+    - use a daemon like systemd-networkd
+
+Examples for both options can be found in the
+`Wiki <https://github.com/freifunk-gluon/gluon/wiki/fastd-l2tp-offloading-on-supernodes>`_.
+
+Configurable Method
+"""""""""""""""""""
+
+From the site configuration, fastd can be allowed to offer
+toggleable encryption in the config mode with the intent to
+increase throughput.
+
+There is also an older unprotected method ``null``. Use of the newer
+``null@l2tp`` method is generally recommended over ``null``, as the
+performance gains provided by the latter (compared to the encrypted
+and authenticated methods) are very small.
+
+Site configuration
+~~~~~~~~~~~~~~~~~~
+
+1)
+  Add the feature ``web-mesh-vpn-fastd`` in ``site.mk``
+2)
+  Set ``mesh_vpn.fastd.configurable = true`` in ``site.conf``
+3)
+  Optionally, add ``null@l2tp`` to the ``mesh_vpn.fastd.methods`` table if you want
+  "Performance mode" as default (not recommended)
+
+Config Mode
+~~~~~~~~~~~
+
+The resulting firmware will allow users to choose between secure (encrypted) and fast (unencrypted) transport.
+
+.. image:: fastd_mode.gif
 
-       opkg update
-       opkg install socat
-       socat - UNIX-CONNECT:/var/run/fastd.mesh_vpn.socket
+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 configuration 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.
+
+.. _gluon-mesh-vpn-key-translate:
+
+gluon-mesh-vpn-key-translate
+""""""""""""""""""""""""""""
+
+Many communities already possess a collection of active fastd-keys when they
+plan migrating their community to WireGuard.
+These public keys known on the server-side can be derived into their WireGuard
+equivalent using `gluon-mesh-vpn-key-translate <https://github.com/AiyionPrime/gluon-mesh-vpn-key-translate>`__.
+The routers do the necessary reencoding of the private key seamlessly
+when updating firmware from fastd to the WireGuard variant.
+
+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/features/wired-mesh.rst

@@ -20,7 +20,7 @@ Wired mesh encapsulation
 
 Since version 2018.1, Gluon supports encapsulating wired mesh traffic in
 `VXLAN <https://en.wikipedia.org/wiki/Virtual_Extensible_LAN>`_, a new standard with
-usecases similar to VLANs, but a much greater ID space of 24bit; in addition, VXLAN
+use cases similar to VLANs, but a much greater ID space of 24bit; in addition, VXLAN
 packets pass through VLAN-aware switches without any special configuration.
 
 Encapsulating mesh traffic has two advantages:
@@ -50,38 +50,84 @@ Configuration
 Both Mesh-on-WAN and Mesh-on-LAN can be configured on the "Network" page
 of the *Advanced settings* (if the package ``gluon-web-network`` is installed).
 
-It is also possible to enable Mesh-on-WAN and Mesh-on-LAN by default by
-adding ``mesh_on_wan = true`` and ``mesh_on_lan = true`` to ``site.conf``.
+It is also possible to enable Mesh-on-WAN and Mesh-on-LAN by default by adding
+the ``mesh`` role to the ``interfaces.*.default_roles`` options in your
+:ref:`site.conf<user-site-interfaces>`.
+
+
+.. _wired-mesh-commandline:
 
 Commandline
 ===========
 
+Starting with release 2022.1, the wired network configuration is rebuilt from ``/etc/config/gluon``
+upon each ``gluon-reconfigure``.
+Therefore the network configuration is overwritten at least with every firmware upgrade.
+
+Every interface has a list of roles assigned to it which can be ``client``, ``mesh`` or ``uplink``.
+
+When the client role is assigned to an interface in combination with other roles
+(like 'client', 'mesh' in the Mesh-on-LAN example below), the other roles take
+precedence, enabling mesh but not client in the previous example.
+
+The setup/config-mode interface is every interface with the role ``client`` which makes removing
+it from interfaces not only unnecessary, but generally unrecommended.
+
+In order to make persistent changes to the router's configuration it's necessary to:
+
+* change the sections in ``/etc/config/gluon`` e.g. using uci (see examples below)
+* call ``gluon-reconfigure`` to re-generate ``/etc/config/network``
+* apply the networking changes, either through executing ``service network restart`` or by performing a ``reboot``
+
 Enable Mesh-on-WAN::
 
-  uci set network.mesh_wan.disabled=0
-  uci commit network
+  uci add_list gluon.iface_wan.role='mesh'
+  uci commit gluon
 
 Disable Mesh-on-WAN::
 
-  uci set network.mesh_wan.disabled=1
-  uci commit network
+  uci del_list gluon.iface_wan.role='mesh'
+  uci commit gluon
 
 Enable Mesh-on-LAN::
 
-  uci set network.mesh_lan.disabled=0
-  for ifname in $(cat /lib/gluon/core/sysconfig/lan_ifname); do
-    uci del_list network.client.ifname=$ifname
-  done
-  uci commit network
+  uci add_list gluon.iface_lan.role='mesh'
+  uci commit gluon
 
 Disable Mesh-on-LAN::
 
-  uci set network.mesh_lan.disabled=1
-  for ifname in $(cat /lib/gluon/core/sysconfig/lan_ifname); do
-    uci add_list network.client.ifname=$ifname
-  done
-  uci commit network
+  uci del_list gluon.iface_lan.role='mesh'
+  uci commit gluon
+
+For devices with a single interface, instead of `iface_lan` and `iface_wan` configuration is
+done with `iface_single`.
+
+Enable Mesh-on-Single::
+
+  uci add_list gluon.iface_single.role='mesh'
+  uci commit gluon
+
+Disable Mesh-on-Single::
+
+  uci del_list gluon.iface_single.role='mesh'
+  uci commit gluon
+
+Furthermore it is possible to make use of 802.1Q VLAN.
+The following statements would create a VLAN with id 8 on ``eth0`` and join the mesh network with it::
+
+  uci set gluon.iface_lan_vlan8=interface
+  uci set gluon.iface_lan_vlan8.name='eth0.8'
+  uci add_list gluon.iface_lan_vlan8.role='mesh'
+  uci commit gluon
+
+Other VLAN-interfaces could be configured on the same parent interface in order to have
+all three roles available on ``eth0`` without having them interfere with each other.
+This feature comes in especially handy for the persistent configuration of virtual machines
+as offloader for bigger installations.
+
+A ``reboot`` is not sufficient to apply an altered configuration; calling ``gluon-reconfigure`` before is
+mandatory in order for changes to take effect.
 
-Please note that this configuration has changed in Gluon 2016.1. Using
-the old commands on 2016.1 and later will break the corresponding options
+Please note that this configuration has changed in Gluon 2022.1. Using
+the old commands on 2022.1 and later will break the corresponding options
 in the *Advanced settings*.

docs/features/wlan-configuration.rst

@@ -2,10 +2,9 @@ WLAN configuration
 ==================
 
 Gluon allows to configure 2.4GHz and 5GHz radios independently. The configuration
-may include any or all of the three networks "client" (AP mode), "mesh" (802.11s
-mode) and "ibss" (adhoc mode), which can be used simultaneously (using "mesh" and
-"ibss" at same time should be avoided though as weaker hardware usually can't handle the additional
-load). See :doc:`../user/site` for details on the configuration.
+may include one or both of the two networks "client" (AP mode) and "mesh" (802.11s
+mode), which can be used simultaneously. See :doc:`../user/site` for details on the
+configuration.
 
 Upgrade behaviour
 -----------------
@@ -16,19 +15,12 @@ on upgrades the existing setting is always retained (as this setting may have be
 by the user). This means that it is not possible to enable or disable an existing network
 configurations during upgrades.
 
-For the "mesh" and "ibss" networks, the default setting only has an effect if none
-of the two has existed before. If a new configuration has been added for "mesh" or "ibss",
-while the other of the two has already existed before, the enabled/disabled state of the
-existing configuration will also be set for the new configuration.
-
-This allows upgrades to change from IBSS to 11s and vice-versa while retaining the
-"wireless meshing is enabled/disabled" property configured by the user regardless
-of the used mode.
-
 During upgrades the wifi channel of the 2.4GHz and 5GHz radio will be restored to the channel
-configured in the site.conf. If you need to preserve a user defined wifi channel during upgrades
-you can configure this via the uci section ``gluon-core.wireless``::
+configured in the site.conf. The channel width will be reset to Gluon's default. If you need to preserve
+these settings during upgrades you can configure this via the uci section ``gluon-core.wireless``::
 
-  uci set gluon-core.@wireless[0].preserve_channels='1'
+  uci set gluon.wireless.preserve_channels='1'
 
+When channels should be preserved, toggling the outdoor mode will have no effect on the channel settings.
+Therefore, the Outdoor mode settings won't be displayed in config mode.
 Keep in mind that nodes running wifi interfaces on custom channels can't mesh with default nodes anymore!

docs/index.rst

 Welcome to Gluon
 ================
 
-Gluon is a modular framework for creating OpenWrt-based firmwares for wireless mesh nodes.
-Several Freifunk communities in Germany use Gluon as the foundation of their Freifunk firmwares.
+Gluon is a modular framework for creating OpenWrt-based firmware images for wireless mesh nodes.
+Several Freifunk communities in Germany use Gluon as the foundation of their Freifunk firmware.
 
 
 .. toctree::
-   :caption: User Documentation
-   :maxdepth: 2
+  :caption: User Documentation
+  :maxdepth: 2
 
-   user/getting_started
-   user/site
-   user/x86
-   user/faq
+  user/getting_started
+  user/site
+  user/supported_devices
+  user/x86
+  user/faq
+  user/mtu
 
 .. toctree::
-   :caption: Features
-   :maxdepth: 2
-
-   features/configmode
-   features/autoupdater
-   features/wlan-configuration
-   features/private-wlan
-   features/wired-mesh
-   features/dns-forwarder
-   features/monitoring
-   features/multidomain
-   features/authorized-keys
-   features/roles
-   features/vpn
+  :caption: Features
+  :maxdepth: 2
+
+  features/configmode
+  features/autoupdater
+  features/wlan-configuration
+  features/private-wlan
+  features/wired-mesh
+  features/dns-cache
+  features/monitoring
+  features/multidomain
+  features/authorized-keys
+  features/roles
+  features/vpn
 
 .. toctree::
-   :caption: Developer Documentation
-   :maxdepth: 2
-
-   dev/basics
-   dev/hardware
-   dev/packages
-   dev/upgrade
-   dev/wan
-   dev/mac_addresses
-   dev/site_library
+  :caption: Developer Documentation
+  :maxdepth: 2
+
+  dev/basics
+  dev/hardware
+  dev/packages
+  dev/upgrade
+  dev/uplink
+  dev/mac_addresses
+  dev/site_library
+  dev/build
+  dev/debugging
 
 .. toctree::
-   :caption: gluon-web Reference
-   :maxdepth: 1
+  :caption: gluon-web Reference
+  :maxdepth: 1
 
-   dev/web/controller
-   dev/web/model
-   dev/web/view
-   dev/web/i18n
-   dev/web/config-mode
+  dev/web/controller
+  dev/web/model
+  dev/web/view
+  dev/web/i18n
+  dev/web/config-mode
 
 .. toctree::
-   :caption: Packages
-   :maxdepth: 1
-
-   package/gluon-client-bridge
-   package/gluon-config-mode-domain-select
-   package/gluon-ebtables-filter-multicast
-   package/gluon-ebtables-filter-ra-dhcp
-   package/gluon-ebtables-limit-arp
-   package/gluon-ebtables-source-filter
-   package/gluon-radv-filterd
-   package/gluon-web-admin
-   package/gluon-web-logging
+  :caption: Packages
+  :maxdepth: 1
+
+  package/gluon-client-bridge
+  package/gluon-config-mode-domain-select
+  package/gluon-ebtables-filter-multicast
+  package/gluon-ebtables-filter-ra-dhcp
+  package/gluon-ebtables-limit-arp
+  package/gluon-ebtables-source-filter
+  package/gluon-hoodselector
+  package/gluon-logging
+  package/gluon-mesh-batman-adv
+  package/gluon-mesh-wireless-sae
+  package/gluon-radv-filterd
+  package/gluon-scheduled-domain-switch
+  package/gluon-web-admin
+  package/gluon-web-logging
 
 .. toctree::
-   :caption: Releases
-   :maxdepth: 1
-
-   releases/v2018.2
-   releases/v2018.1.4
-   releases/v2018.1.3
-   releases/v2018.1.2
-   releases/v2018.1.1
-   releases/v2018.1
-   releases/v2017.1.8
-   releases/v2017.1.7
-   releases/v2017.1.6
-   releases/v2017.1.5
-   releases/v2017.1.4
-   releases/v2017.1.3
-   releases/v2017.1.2
-   releases/v2017.1.1
-   releases/v2017.1
-   releases/v2016.2.7
-   releases/v2016.2.6
-   releases/v2016.2.5
-   releases/v2016.2.4
-   releases/v2016.2.3
-   releases/v2016.2.2
-   releases/v2016.2.1
-   releases/v2016.2
-   releases/v2016.1.6
-   releases/v2016.1.5
-   releases/v2016.1.4
-   releases/v2016.1.3
-   releases/v2016.1.2
-   releases/v2016.1.1
-   releases/v2016.1
-   releases/v2015.1.2
-   releases/v2015.1.1
-   releases/v2015.1
-   releases/v2014.4
-   releases/v2014.3.1
-   releases/v2014.3
-
-
-Supported Devices & Architectures
----------------------------------
-
-ar71xx-generic
-^^^^^^^^^^^^^^
-
-* 8devices
-
-  - Carambola 2
-
-* ALFA Network
-
-  - AP121
-  - AP121F
-  - AP121U
-  - Hornet-UB
-  - Tube2H
-  - N2
-  - N5
-
-* Allnet
-
-  - ALL0315N
-
-* AVM
-
-  - Fritz!Box 4020 [#avmflash]_
-  - Fritz!WLAN Repeater 300E [#avmflash]_
-  - Fritz!WLAN Repeater 450E [#avmflash]_
-
-* Buffalo
-
-  - WZR-HP-AG300H / WZR-600DHP
-  - WZR-HP-G300NH
-  - WZR-HP-G300NH2
-  - WZR-HP-G450H
-
-* D-Link
-
-  - DIR-505 (A1, A2)
-  - DIR-825 (B1)
-
-* GL Innovations
-
-  - GL-AR150
-  - GL-AR300M
-  - GL-AR750 [#ath10k]_
-  - GL-iNet 6408A (v1)
-  - GL-iNet 6416A (v1)
-
-* Linksys
-
-  - WRT160NL
-
-* Netgear
-
-  - WNDR3700 (v1, v2, v5)
-  - WNDR3800
-  - WNDRMAC (v2)
-
-* OCEDO
-
-  - Koala [#ath10k]_
-
-* Onion
-
-  - Omega
-
-* OpenMesh
-
-  - A40
-  - A60
-  - MR600 (v1, v2)
-  - MR900 (v1, v2)
-  - MR1750 (v1, v2) [#ath10k]_
-  - OM2P (v1, v2, v4)
-  - OM2P-HS (v1, v2, v3, v4)
-  - OM2P-LC
-  - OM5P
-  - OM5P-AN
-  - OM5P-AC (v1, v2) [#ath10k]_
-
-* TP-Link
-
-  - Archer C5 (v1) [#ath10k]_
-  - Archer C59 (v1) [#80211s]_
-  - Archer C7 (v2, v4, v5) [#ath10k]_
-  - CPE210 (v1.0, v1.1, v2.0)
-  - CPE220 (v1.1)
-  - CPE510 (v1.0, v1.1)
-  - CPE520 (v1.1)
-  - RE450 [#ath10k]_
-  - TL-WDR3500 (v1)
-  - TL-WDR3600 (v1)
-  - TL-WDR4300 (v1)
-  - TL-WR710N (v1, v2.1)
-  - TL-WR810N (v1)
-  - TL-WR842N/ND (v1, v2, v3)
-  - TL-WR1043N/ND (v1, v2, v3, v4, v5)
-  - TL-WR2543N/ND (v1)
-  - WBS210 (v1.20)
-  - WBS510 (v1.20)
-
-* Ubiquiti
-
-  - Air Gateway
-  - Air Gateway LR
-  - Air Gateway PRO
-  - Air Router
-  - Bullet M2/M5
-  - Loco M2/M5
-  - Loco M2/M5 XW
-  - Nanostation M2/M5
-  - Nanostation M2/M5 XW
-  - Picostation M2/M5
-  - Rocket M2/M5
-  - Rocket M2/M5 Ti
-  - Rocket M2/M5 XW
-  - UniFi AC Mesh [#ath10k]_
-  - UniFi AC Mesh Pro [#ath10k]_
-  - UniFi AP
-  - UniFi AP AC Lite [#ath10k]_
-  - UniFi AP AC LR [#ath10k]_
-  - UniFi AP AC Pro [#ath10k]_
-  - UniFi AP LR
-  - UniFi AP Pro
-  - UniFi AP Outdoor
-  - UniFi AP Outdoor+
-
-* Western Digital
-
-  - My Net N600
-  - My Net N750
-
-* ZyXEL
-
-  - NBG6616 [#ath10k]_
-
-ar71xx-nand
-^^^^^^^^^^^
-
-* Netgear
-
-  - WNDR3700 (v4)
-  - WNDR4300 (v1)
-
-* ZyXEL
-
-  - NBG6716 [#ath10k]_
-
-ar71xx-tiny
-^^^^^^^^^^^
-
-* D-Link
-
-  - DIR-615 (C1)
-
-* TP-Link
-
-  - TL-MR13U (v1)
-  - TL-MR3020 (v1)
-  - TL-MR3040 (v1, v2)
-  - TL-MR3220 (v1, v2)
-  - TL-MR3420 (v1, v2)
-  - TL-WA701N/ND (v1, v2)
-  - TL-WA730RE (v1)
-  - TL-WA750RE (v1)
-  - TL-WA801N/ND (v1, v2, v3)
-  - TL-WA830RE (v1, v2)
-  - TL-WA850RE (v1)
-  - TL-WA860RE (v1)
-  - TL-WA901N/ND (v1, v2, v3, v4, v5)
-  - TL-WA7210N (v2)
-  - TL-WA7510N (v1)
-  - TL-WR703N (v1)
-  - TL-WR710N (v1, v2, v2.1)
-  - TL-WR740N (v1, v3, v4, v5)
-  - TL-WR741N/ND (v1, v2, v4, v5)
-  - TL-WR743N/ND (v1, v2)
-  - TL-WR841N/ND (v3, v5, v7, v8, v9, v10, v11, v12)
-  - TL-WR843N/ND (v1)
-  - TL-WR940N (v1, v2, v3, v4, v5, v6)
-  - TL-WR941ND (v2, v3, v4, v5, v6)
-
-brcm2708-bcm2708
-^^^^^^^^^^^^^^^^
-
-* RaspberryPi 1
-
-brcm2708-bcm2709
-^^^^^^^^^^^^^^^^
-
-* RaspberryPi 2
-
-
-ipq40xx
-^^^^^^^
-
-* AVM
-
-  - FRITZ!Box 4040 [#80211s]_ [#avmflash]_
-
-* GL.iNet
-
-  - GL-B1300 [#80211s]_
-
-* NETGEAR
-
-  - EX6100v2 [#80211s]_
-  - EX6150v2 [#80211s]_
-
-* OpenMesh
-
-  - A42 [#80211s]_
-  - A62 [#80211s]_
-
-* ZyXEL
-
-  - NBG6617 [#80211s]_
-  - WRE6606 [#80211s]_
-
-ipq806x
-^^^^^^^
-
-* TP-Link
-
-  - Archer C2600 [#80211s]_
-
-mpc85xx-generic
-^^^^^^^^^^^^^^^
-
-* TP-Link
-
-  - TL-WDR4900 (v1)
-
-ramips-mt7620
-^^^^^^^^^^^^^
-
-* GL Innovations
-
-  - GL-MT300A [#80211s]_
-  - GL-MT300N [#80211s]_
-  - GL-MT750 [#80211s]_
-
-* Nexx
-
-  - WT3020AD/F/H
-
-ramips-mt7621
-^^^^^^^^^^^^^
-
-* D-Link
-
-  - DIR-860L (B1) [#80211s]_
-
-* Ubiquiti
-
-  - EdgeRouter X
-  - EdgeRouter X-SFP
-
-* ZBT
-
-  - WG3526-16M [#80211s]_
-  - WG3526-32M [#80211s]_
-
-ramips-mt76x8
-^^^^^^^^^^^^^
-
-* GL.iNet
-
-  - GL-MT300N v2 [#80211s]_
-
-* TP-Link
-
-  - TL-WR841N v13 [#80211s]_
-  - Archer C50 v3 [#80211s]_
-  - Archer C50 v4 [#80211s]_
-
-* VoCore
-
-  - VoCore2 [#80211s]_
-
-ramips-rt305x
-^^^^^^^^^^^^^
-
-* A5-V11 [#80211s]_
-
-* D-Link
-
-  - DIR-615 (D1, D2, D3, D4, H1) [#80211s]_
-
-* VoCore
-
-  - VoCore (8M, 16M) [#80211s]_
-
-sunxi
-^^^^^
-
-* LeMaker
-
-  - Banana Pi M1
-
-x86-generic
-^^^^^^^^^^^
-
-* x86-generic
-* x86-virtualbox
-* x86-vmware
-
-See also: :doc:`user/x86`
-
-x86-geode
-^^^^^^^^^
-
-* x86-geode
-
-See also: :doc:`user/x86`
-
-x86-64
-^^^^^^
-
-* x86-64-generic
-* x86-64-virtualbox
-* x86-64-vmware
-
-See also: :doc:`user/x86`
-
-Footnotes
-^^^^^^^^^
-
-.. [#ath10k]
-  Device uses the ath10k WLAN driver; images are built for 11s by default unless GLUON_WLAN_MESH
-  is set as described in :ref:`getting-started-make-variables`
-
-.. [#80211s]
-  Device does not support IBSS; images are built by default unless GLUON_WLAN_MESH
-  is explicitly set to something other than *11s*
+  :caption: Releases
+  :maxdepth: 1
 
-.. [#avmflash]
-  For instructions on how to flash AVM devices, visit https://www.fritzfla.sh
+  releases/index
 
 License
 -------

docs/multidomain-site-example/domains/alpha_centauri.conf

@@ -21,26 +21,32 @@
     ip6 = 'fdxx:xxxx:xxxx:xxxx::xxxx',
   },
 
-  wifi24= {
+  wifi24 = {
+    channel = 1,
     ap = {
       ssid = "alpha-centauri.example.org",
-      channel = 1,
     },
     mesh = {
       id = 'ueH3uXjdp', -- 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
     },
   },
 
-  wifi5= {
+  wifi5 = {
+    channel = 44,
     ap = {
       ssid = "alpha-centauri.example.org",
-      channel = 44,
     },
     mesh = {
       id = 'ueH3uXjdp',
     },
   },
 
+  mesh = {
+    batman_adv = {
+      routing_algo = 'BATMAN_IV',
+    },
+  },
+
   mesh_vpn = {
     fastd = {
       groups = {

docs/multidomain-site-example/image-customization.lua

+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',
+}
+
+packages {
+	'iwinfo',
+}
+
+if not device_class('tiny') then
+	features {'wireless-encryption-wpa3'}
+end

docs/multidomain-site-example/site.conf

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

docs/multidomain-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_MULTIDOMAIN
 #		Build gluon with multidomain support.
 
 GLUON_MULTIDOMAIN=1
 
-##	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

docs/package/gluon-config-mode-domain-select.rst

@@ -5,7 +5,7 @@ the node will be placed in. If the selection has changed the upgrade scripts in
 ``/lib/gluon/upgrade/`` are triggered to update the nodes configuration.
 
 Hiding domains could be useful for default or testing domains, which should not
-be accidentally selected by a node operater.
+be accidentally selected by a node operator.
 
 domains/\*.conf
 ---------------

docs/package/gluon-ebtables-limit-arp.rst

 gluon-ebtables-limit-arp
 ========================
 
-The *gluon-ebtables-limit-arp* package adds filters to limit the 
-amount of ARP requests client devices are allowed to send into the 
-mesh. 
+The *gluon-ebtables-limit-arp* package adds filters to limit the
+amount of ARP requests client devices are allowed to send into the
+mesh.
 
 The limits per client device, identified by its MAC address, are
-6 packets per minute and 1 per second per node in total. 
+6 packets per minute and 1 per second per node in total.
 A burst of up to 50 ARP requests is allowed until the rate-limiting
 takes effect (see ``--limit-burst`` in ``ebtables(8)``).
 
 Furthermore, ARP requests for a target IP already present in the
-batman-adv DAT cache are excluded from rate-limiting, in regard 
+batman-adv DAT cache are excluded from rate-limiting, in regard
 to both counting and filtering, as batman-adv will be able
 to respond locally without a burden for the mesh. Therefore, this
 limiter should not affect popular target IP addresses, like those
@@ -21,3 +21,10 @@ However it mitigates the impact on the mesh when a larger range of
 its IPv4 subnet is being scanned, which would otherwise result in
 a significant amount of ARP chatter, even for unused IP addresses.
 
+This package is installed by default if the selected routing
+feature is *mesh-batman-adv-15*.
+It can be unselected via::
+
+    packages {
+      '-gluon-ebtables-limit-arp',
+    }

docs/package/gluon-hoodselector-rectangle-example.svg

+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd">
+<svg width="13cm" height="9cm" viewBox="348 138 253 169" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+  <g>
+    <rect style="fill: #ffffff" x="389" y="164" width="158" height="115"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="389" y="164" width="158" height="115"/>
+  </g>
+  <text font-size="12.7998" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="348" y="150">
+    <tspan x="348" y="150">53.22,</tspan>
+    <tspan x="348" y="166">8.09 #</tspan>
+  </text>
+  <text font-size="12.7998" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="545" y="288">
+    <tspan x="545" y="288"># 53.36,</tspan>
+    <tspan x="545" y="304">    8.32</tspan>
+  </text>
+</svg>