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 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).
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>
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.
* 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
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.
MAC and IP addresses are switched. This makes the gluon-client-bridge
package more useful for different routing protocols that don't need a
unique address on the client bridge.
As a side effect, gluon-radvd is now using the next-node address, which had
been considered before, but was dismissed to avoid having gluon-radvd
depend on gluon-next-node and gluon-mesh-batman-adv. This will be useful
for announcing default routes via gluon-radvd.
One downside is that this introduces a minor dependency on batman-adv in
gluon-respondd: the hotplug script that checked for the client interface
before will now check for local-node. This doesn't really matter: for mesh
protocols without a local-node interface, the check will do nothing (which
makes sense, as there is no interface to bind to for mesh-wide respondd).
