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).
Because we unconditionally appended `-i br-client` to the command line of
respondd, it wasn't restarted when br-client changed state. Now, we use a
jsonfilter expression on the network.interface dump data, similar to how the
other interface names are generated, and only add the interface to the argument
list if it is up.
The arguments are now provided by gluon-mesh-batman-adv-core, so
gluon-radvd can be used with other mesh protocols.
[Matthias Schiffer: removed PROVIDES dependency]
Lua's tables are 1-based, so we must decrement the index by 1 to get the
desired MAC addresses. By not doing this, the second IBSS interface would
get the address with index 8, but only indices 0..7 are available.
Fixes: c73a12e0ea
There are a few devices which have more than one LAN interface (for example
some revision of the TL-WR941ND, which uses a DSA-based switch, so each
switch port has its own netdev.) On these devices we need a bridge for
mesh-on-lan (as the alternative of adding them to batman-adv individually
would need too many MAC addresses.)
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]
We are mostly dealing with the 2.4GHz crap-band here, so increasing the
IGMP/MLD robustness parameter to three to be able to compensate for up
to two consecutive instead of just one lost packet.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
There are some devices not acting properly to roaming events, in that
they do not timely reissue IGMP/MLD reports after reconnecting.
To compensate for that this commit reduces the query interval from 125
seconds to 20 and the query response interval from 20 seconds to 5.
This reduces a timeout to 20+5 seconds in the worst-case (12.5s average)
after a roaming event for such broken devices. This should be below the
30s "impatient user threshold" and below any connection timeout.
Until the bridge multicast snooping + querier gets re-enabled this is a
no-op.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
An IGMP/MLD domain split will prevent us from being able to track
multicast listeners on other nodes.
Therefore we need to always hand any multicast packets we received from
local clients to batman-adv. With bridge multicast snooping disabled,
the current setting in Gluon, this is already the case.
However, in preparation to enabling multicast snooping, we need to
enforce forwarding towards batman-adv by setting the bridge port
option "multicast_router" to 2.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Ethernet links provide transitive connectivity in all but very unusual
setup, enable mesh_no_rebroadcast to reduce load for devices on links with
many nodes.
Fixes#652
Is makes sense to always look for both ibss_radio* and mesh_radio* sections
to determine if the meshing should be enabled when regenerating these
sections. Doing this, the disabled state will survive updates changing the
section name (either updating from pre-2015.2 while keeping IBSS, or
changing from IBSS to 11s or vice-versa).
If both ibss_radio* and mesh_radio* sections exist, the disabled state will
be kept correctly for each section, the behaviour is changed only when
creating a section that didn't exist before.
Fixes#549
Convert option ifname in br-client to use a list instead. This
simplifies adding and remove interfaces:
uci:add_to_set("network", "client", "ifname", "eth0")
uci:remove_from_set("network", "client", "ifname", "eth0")
An option ifname will be automatically converted to a list when
performing an upgrade.
Packages affected: gluon-mesh-batman-adv-core, gluon-luci-portconfig
Apart from replacing a patch for the former by two patches for latter,
this involved minimal adaptations of the lua scripts in the following
packages:
* gluon-announce
* gluon-announced
* gluon-mesh-batman-adv-core
* gluon-status-page
Split basic radio configuration from gluon-mesh-batman-adv as this will
be required for virtually any wireless mesh protocol.
This package takes care of setting:
- wireless channel,
- htmode and
- regulatory domain
gluon-mesh-batman-adv-core depends on this package.
This is a site.conf-breaking change in regard to the wireless config.
Make sure to read http://gluon.readthedocs.org/en/latest/user/site.html
and update your site.conf accordingly!
Support for 802.11s mesh interfaces has been added. Gluon now supports
three interface types: ap, ibss and mesh. All of them are now optional
and may be configured independently in site.conf.
A sample site.conf may look like this:
wifi24 = {
channel = 1,
htmode = 'HT40+',
ap = {
ssid = 'luebeck.freifunk.net',
},
ibss = {
ssid = '02:d1:11:37:fc:38',
bssid = '02:d1:11:37:fc:38',
mcast_rate = 12000,
},
mesh = {
id = 'ffhl-mesh',
mcast_rate = 12000,
},
},
The nodeinfo/network/addresses announcement included deprecated and
tentative addresses, which it clearly shouldn't as the host doesn't want
to be contacted on those addresses. They are now filtered out.
Always output empty objects or nothing at all where objects are expected, but
no elements exist.
Also remove a few unneeded "requires", a few basic modules are provided by
announce.lua by default.
This adds mesh_on_lan functionality.
A new optional site.conf option, mesh_on_lan, has been added. If set to
'true', all LAN ports will be used for meshing instead of being part of
the client bridge.
This will introduce a new nodeinfo object, network.mesh.bat0.interfaces,
containing any of the the following subordinated objects:
- wireless
- tunnel
- other
Each of these objects contains a (possibly empty) list of MAC addresses
(lowercase, colon-notation) corresponding to a interface of the given
class. Combined with a batman graph it is thus possible to mark
sub-graphs as "wireless" or "vpn".
The previously used object mesh_intefaces is superseded by this new
object structure and mesh_interfaces will be removed in a future Gluon
release.
