Nothing outside the config mode depends on luci-base anymore.

We also make use of the boolean support of simple-uci to make scripts
clearer.

A lot of our code does not actually work with other prefix lengths.

Fixes #1014

Closes #844

gluon-core: add get_mesh_devices(uconn) to gluon.util which will return all devices being up and having proto = gluon_mesh

The interfaces were accidentially switched when the CPE210 was separated
from the CPE510 code.

If next_node.ip4 is not set or gluon-next-node is not used, prefix4 will
now be optional as well.

Fixes #842

Users may have defined additional mesh interfaces. Properly migrate these
to avoid subtly breaking the network config (and make them ready for new
mesh protocols).

This new protocol will allow configuring mesh interfaces independently of
the used mesh protocol.

Fixes #414

and add documentation

Just like we enabled multicast snooping on the batman-adv client bridge
again, let's do the same for the WAN side.

With one exception: The IGMP/MLD querier is kept disabled to avoid
becoming too "bossy"/"noisy" on a foreign network. The main router on
the WAN side should perform querying and by that enable
IGMP/MLD/snooping if it considers this appropriate there.

Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>

Some drivers (mt76) don't support arbitrary MAC addresses. Use the
addresses provided by the driver (avoiding the primary address) by default,
but fall back to our has-based scheme when the driver doesn't provide
(enough) addresses.

Fixes #121

Based-on-patch-by: Tobias Hachmer <tobias@hachmer.de>

The new MR1750v2 device support is only available in LEDE master. The
relevant patches have to backported to add support for them in Gluon

Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>

The new OM2P-HSv3 device support is only available in LEDE master. The
relevant patches have to backported to add support for them in Gluon

Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>

The OpenMesh devices have a sticker with the eth0 mac address on the
bottom. Also all other mac addresses are calculated based on this address.
Therefore, it is better to use this as primary mac address instead of the
WiFi mac address.

Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>

Fixes #764

Also backport some patches improving QCA956x support.

While ath9k/ath10k devices can supprt VIFs with any combination of MAC addresses, there are also adapters which have a hardware MAC filter which only allows a few bits to differ. This commit changes the addresses of all VIFs to ony differ in the last 3 bits, which is required to support many Ralink/Mediatek based WLAN adapters.

Technically, the new addresses are generated by calculating an MD5 hash of the primary MAC address and using a part of this hash as a prefix for the MAC addresses.

The addresses (BSSIDs) of the AP VIFs are also reused for the LAN and WAN interfaces in mesh-on-LAN/WAN mode to reduce the number of needed addresses, and thus reduce the chance of collisions. This is not a problem as the MAC addresses of the AP VIFs are never used except as BSSID, and thus not seen by routing protocols like batman-adv.

Fixes #648

[Matthias Schiffer: rewrote commit message]