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>

With the new role-based interface configuration, it would be better to
rename the wan/wan6 interfaces to uplink/uplink6, but that would cause
unnecessary churn for the firewall configuration, so it is left for a
later update.

As all interfaces with the 'uplink' role are in the br-wan bridge, it is
not possible to assign these to the 'mesh' role independently - instead,
br-wan is added as a mesh interface as soon as a single interface has
both the 'uplink' and 'mesh' roles. The UCI section for this
configuration is now called 'mesh_uplink' instead of 'mesh_wan'.

For all interfaces that have the 'mesh', but not the 'uplink' role a
second configuration 'mesh_other' is created. If there is more than one
such interface, all these interfaces are bridged as well (creating a
bridge 'br-mesh_other'). This replaces the 'mesh_lan' section with its
optional 'br-mesh_lan' bridge, but can also include interfaces that were
not considered "LAN" when interfaces roles are modified (via site.conf
or manually).

This removes PKG_VERSION and PKG_RELEASE from most Makefiles, as the
value was never useful for Gluon packages; instead, PKG_VERSION is set
to 1 in gluon.mk.

It also removes two other weird definitions:

- gluon-iptables-clamp-mss-to-pmtu replicating the old PKG_VERSION logic
  from gluon-core, but without the fixed PKG_BUILD_DIR to prevent
  unnessary rebuilds
- gluon-hoodselector set GLUON_VERSION=3

Avoid requiring gluon.wireless from gluon.platform, and requiring
gluon.platform from various other scripts.

With the removal of ramips-rt305x, the last user of
GLUON_SPECIALIZE_KERNEL is gone.

* gluon-core: remove obsolete file 100-core-reset-sysctl

* gluon-core: remove obsolete cleanup line

* gluon-client-bridge: remove obsolete cleanup line

This renames the local_client zone to loc_client, as local_clint exceeds
the maximum zone length allowed for firewall3, which is 11 bytes.

This worked previously due to firewall3 using unsafe string operations.
Now creation of the chain fails (latest OpenWrt master).

Separate wireless-related helper methods from the util module to a
new wireless module. This keeps them separated, as the amount of
wireless helpers increased in the past, justifying a separate module.

Allow odhcp6c to fork the script to handle router
advertisments in 30 seconds intervals. This is the value
that was previously used in Gluon v2018.1 / LEDE 17.01.

The default value is 3 seconds and while it is RFC compliant
it can put alot of pressure on even moderately sized devices.

Signed-off-by: Martin Weinelt <martin@darmstadt.freifunk.net>

The commit b3762fc6 ("gluon-client-bridge: move IPv4 local subnet route
to br-client (#1312)") moves the IPv4 prefix from the local-port interface
to br-client. A client requesting an IPv4 connection to the IPv4 anycast
address of the node (the device running gluon) will create following
packets:

1. ARP packet from client to get the MAC of the mac address of the anycast
   IPv4 address
2. ARP reply from node to client with the anycast MAC address for the IPv4
   anycast address
3. IPv4 packet from client which requires reply (for example ICMP echo
   request)
4. ARP request for the client MAC address for its IPv4 address in prefix4
   (done with the mac address of br-client and transmitted over br-client)
5. IPv4 packet from node (transmitted over br-client with br-client MAC
   address) as reply for the client IPv4 packet (for example ICMP echo
   reply)

The step 4 and 5 are problematic here because packets use the node specific
MAC addresses from br-client instead of the anycast MAC address. The client
will receive the ARP packet with the node specific MAC address and change
their own neighbor IP (translation) table. This will for example break the
access to the status page to the connected device or the anycast DNS
forwarder implementation when the client roams to a different node.

This reverts commit b3762fc6 and adds an
upgrade code to remove local_node_route on on existing installations.

net.ipv6.conf.br-client.forwarding is moved from gluon-client-bridge to
gluon-mesh-batman-adv, as the setting is not useful with non-bridged
protocols.

Fixes: 7ccdacd2 ("treewide: rework check_site_lib.lua")

This patch moves the prefix4 subnet route from the local-node veth
device to br-client (while keeping the next node ipv4 address on the
local node device).

This is in preparation to allow routing over the br-client interface
later.

Allows to remove some redundant UCI lookups.

In addition to significant internal differences in check_site_lib.lua (in
particular unifying error handling to a single place for the upcoming
multi-domain support), this changes the way fields are addressed in site
check scripts: rather than providing a string like 'next_node.ip6', the
path is passed as an array {'next_node', 'ip6'}.

Other changes in site check scripts:
* need_array and need_table now pass the full path to the sub fields to the
subcheck instead of the key and value
* Any check referring to a field inside a table implies that all higher
levels must be tables if they exist: a check for {'next_node', 'ip6'} adds
an implicit (optional) check for {'next_node'}, which allows to remove many
explicit checks for such tables

[Matthias schiffer: rebase, add a few more restrictions]

The 'auto' attribute still allows enabling the interface using ifup, which
is not intended when wired mesh is disabled.

As core defines basic rules for this zone, it makes sense to create it
there.

 * gluon-core, gluon-client-bridge: introduce new firewall zone: local_client
 * gluon-core: put clients in local_client zone, introduce drop-zone,
   set dns-rules and zones
 * gluon-respondd: allow respondd on mesh
 * gluon-status-page-api: allow http input on mesh and client

Some files have received some additional refactoring.

In particular, this affects users of gluon.util.iterate_radios.

The next-node MAC address doesn't need to be unique in different
communities, so we can as well add a default value.

LEDE recently disabled multicast snooping by default:

https://git.lede-project.org/?p=project/netifd.git;a=commitdiff;h=52541140f8138e31958cdc3d7e42a4029fa6bbc9



Reenable it for Gluon as there have been no confirmed issues for
LEDE and no negative reports concerning Gluon v2016.2.x so far.

Closes #1025.

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

gluon-core: gluon.util: pass UCI cursor as argument to iterate_radios() instead of using local context

We always want to prefer the unique node address for outgoing traffic. Note
that this doesn't have an effect with batman-adv, as usually br-client will
be the outgoing interface, so the unique address would be chosen anyways.

macvlan interfaces never directly exchange traffic with the underlying
interface, but only with other hosts behind the interface. In consequence,
router advertisements from the uradvd running on br-client could never
reach local-node, preventing it from getting an IPv6 address without RAs
from an external radvd. Fix this be replacing the macvlan interface with
a veth pair (with the peer interface in br-client).

As a side effect, this saves about 5KB of flash, as the veth module is
simpler than macvlan.

When preparing the migration from macvlan to veth for local-node, MAC
address conflicts occurred as some ports of br-client had the same address
as local-node. Reverting the roles of both interfaces fixes this.

By default, br-client is left as an interface without addresses and
firewall rules that drop everything, so the bridge is used to connect its
ports only. gluon-mesh-batman-adv-core changes this to the usual set
of addresses and firewall rules.