This method previously returned the string literal of the config key,
leading to checks evaluating to true even in case this option was
disabled.

Signed-off-by: David Bauer <mail@david-bauer.net>

The preserve_channels configuration option was moved to the gluon UCI
package without adding a proper migration.

Signed-off-by: David Bauer <mail@david-bauer.net>

Increase the peer limit for ath10k-ct from 32 to 96 STAs like it is set
for the non-ct firmware / driver. In order to make this work with the
memory constraints of the wireless platform, reduce the number of
concurrent vdevs to the maximum Gluon uses (4).

Closes #2604

Signed-off-by: David Bauer <mail@david-bauer.net>

Signed-off-by: David Bauer <mail@david-bauer.net>

The below mentioned commit introduced a regression, that the "wifi"
section of the request type "neighbours" was empty:

    ~# gluon-neighbour-info -d ::1 -r neighbours | ffh_pretty_json
    {
      "wifi": [
      ],
      ...
    }

After this commit, the section (correctly) looks like this:

    root@UFU-FWH-A272-Tresckowstr-GemR-vorne:~# gluon-neighbour-info -d ::1 -r neighbours | ffh_pretty_json
    {
      "wifi": {
        "ca:38:7e:42:5f:21": {
          "neighbours": {
            "fe:9f:4d:01:ea:e1": {
              "noise": -102,
              "inactive": 50,
              "signal": -84
            },
            "fe:df:b9:84:37:51": {
              "noise": -102,
              "inactive": 20,
              "signal": -73
            }
          }
        }
      },
      ...
    }

The issue was due to the fact, that the iteration over the (mesh) wifi interfaces
was broken. The code was assuming, that the section

    config interface 'mesh_radio0'
            option proto 'gluon_mesh'

in /etc/config/network contains an option "ifname", which it does not.
The ifname property is only stored in the corresponding section in
/etc/config/wireless:

    config wifi-iface 'mesh_radio0'
            option ifname 'mesh0'
            option network 'mesh_radio0'
            option mode 'mesh'
            ...

Therefore, we now iterate over wifi-ifaces in /etc/config/wireless, that
have the mode 'mesh' instead. This resolves the issue.

Fixes 0f1fa243

This new field reflects the TQ to the selected gateway.

Before this commit, if you had connectivity issues in a larger mesh,
it was a tedious task to understand which nodes are affected and which
are not. By providing this new value for each node, it becomes easier
to see which nodes are affected by the connectivity issues and which
are not.

The new field "gateway_tq" is located at the toplevel of the
statistics resource (next to "gateway" and "gateway_nexthop"):

    gluon-neighbour-info -d ::1 -r statistics
    {
        ...
        "gateway": "02:a1:71:04:09:10",
        "gateway_nexthop": "88:e6:40:20:90:10",
        "gateway_tq": 193,
        ...
    }

This implements the same behavior as it is used in the autoupdater [1].

This is for example required to allow the manual installation of
firmware upgrades via the config mode on devices which where migrated
from swconfig to DSA. Otherwise the image will always be invalid.

[1] https://github.com/freifunk-gluon/packages/commit/b80428166454d184f356e5a14a144911d9ee11aa

When running "fastd -v" fails, line may be NULL, causing a segfault in
strncmp.

for devices in targets that do no implement `get_status_led` in /etc/diag.sh
and do not have an led-running in their dts

Gone due to
commit 45c84a11 ("ar71xx: drop target")

Depending on the source of the primary MAC address, uppercase digits
would be used on some devices. Convert the address to lowercase for
consistency.

We only change the case for newly configured nodes to avoid changing the
node ID and derives MAC addresses for existing installations.

The ip6tables-legacy metapackage was renamed to ip6ables-zz-legacy.

Only restore the netifd proto for the WAN bridge in case the upgrade is
done from an older Gluon version.

For DSL targets, OpenWrt defaults the WAN proto to pppoe, while Gluon
uses the Ethernet ports for WAN. When unconditionally preserving the WAN
proto, pppoe is carried over to Gluon's network config.

Signed-off-by: David Bauer <mail@david-bauer.net>

Co-Authored-By: J. Burfeind <github@aiyionpri.me>

Co-authored-by: Tim-Niklas Koch <info@tnkoch.de>
Co-authored-by: J. Burfeind <github@aiyionpri.me>

There was never a device with a dedicated WAN port supported in Gluon
which could make use of such a workaround.

As the only relevant lantiq-xrx200 target now uses swconfig anyways,
we can remove this workaround.

Signed-off-by: David Bauer <mail@david-bauer.net>

Gone due to
commit 45c84a11 ("ar71xx: drop target")

posix-sh does not support pipefail this way

to prevent word splitting and globbing

OpenWrt now allows to specify the ifname of the transition interface
instead of SSID and BSSID, internally automatically detecting these from
interfaces on the same PHY. Thus, these cross-VAP dependant
configuration can be omitted from UCI.

Signed-off-by: David Bauer <mail@david-bauer.net>

Co-authored-by: Maximilian Baumgartner <aufhaxer@googlemail.com>

Gone due to
commit 45c84a11 ("ar71xx: drop target")

Gone due to
commit 071cf7b2 ("Switch to Lua for target definitions")

Has prior been introduced as untested -> broken in
commit d586720c ("ar71xx-generic: add support for Ubiquiti NanoBeam M5")

Was commented out in the former commit.

An invalid branch may be set for various reasons:

- Previous firmware had an invalid default branch
- Branch list has changed and old UCI branch config was removed by a
  site-specific upgrade script
- Manual UCI configuration

Make the code clearer and prepare for invalid branch fixup.

Check the default branch (both from site.conf and GLUON_AUTOUPDATER_BRANCH)
against the list of configured branch names to avoid misconfiguration.

The new "value" helper can be used to turn a Lua value into a path that
can be passed to need_*() etc.

Removed in 45c84a11 ("ar71xx: drop target").

Since freifunk-gluon/packages#250 mesh-vpn-peers
can be empty arrays if they're not connected
and the node is in a WireGuard site.

If a community uses different vpn providers, they typically
assume the same MTU for the wan device underneath the VPN. As
different VPN providers however have different overhead, the MTU
of the VPN device differs for each provider. Therefore this
commit makes the MTU of the VPN device provider specific.

This has two advantages:
1. The same site.conf can used to bake firmwares for different
   VPN providers (only by selecting a diferent vpn feature in the
   site.mk).
2. We are coming closer to the option of integrating multiple VPN
   providers into one firmware.