- May 12, 2020
-
-
Matthias Schiffer authored
As a partial fix to #496, do not touch the MAC address of the WAN interface when using VXLANs (as only the MAC address of the VXLAN interface matters to batman-adv).
-
- Apr 12, 2017
-
-
Matthias Schiffer authored
For simplicity, we don't use different MTUs for compat 14 and 15 anymore, there's no harm in using 1532 for batman-adv-legacy as well.
-
- Feb 10, 2017
-
-
Matthias Schiffer authored
We also make use of the boolean support of simple-uci to make scripts clearer.
-
- Dec 10, 2016
-
-
Matthias Schiffer authored
gluon-client-bridge, gluon-mesh-batman-adv-core: switch roles of br-client and local-node interfaces 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).
-
- Sep 07, 2016
-
-
Matthias Schiffer authored
Fixes #842
-
Matthias Schiffer authored
-
- Aug 30, 2016
-
-
Matthias Schiffer authored
Switch to: 1. WAN 2. LAN 3. Mesh VPN As WAN and LAN are setup in gluon-mesh-batman-adv-core (and will be moved to gluon-core), while the mesh VPN has its own package, giving WAN and LAN the first indices is preferable.
-
- Jul 20, 2016
-
-
Matthias Schiffer authored
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.
-
- Jul 10, 2016
-
-
Jan-Tarek Butt authored
-
- Apr 27, 2016
-
-
lemoer authored
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]
-
- Apr 02, 2016
-
-
Matthias Schiffer authored
Avoid commiting configs inbetween to decrease number of flash writes. Fixes #714.
-
- Jul 11, 2015
-
-
Matthias Schiffer authored
This fixes MAC address conflicts on devices which use the eth0 as primary address.
-
- Jan 24, 2015
-
-
Matthias Schiffer authored
Moving the scripts to a common directory not only vastly simplifies the zzz-gluon-upgrade script, but also allows to define an ordering of such scripts across packages.
-
- Sep 15, 2014
-
-
Matthias Schiffer authored
-
- Aug 08, 2014
-
-
Matthias Schiffer authored
-
- Jul 19, 2014
-
-
Matthias Schiffer authored
Also move it to gluon-mesh-batman-adv, as mesh_on_wan is the only feature that needs a unique MAC address on the WAN interface.
-