Increase the peer limit for ath10k-ct from 32 to 96 STAs like it is set
for the non-ct firmware / driver. In order to make this work with the
memory constraints of the wireless platform, reduce the number of
concurrent vdevs to the maximum Gluon uses (4).
Closes#2604
Signed-off-by: David Bauer <mail@david-bauer.net>
Signed-off-by: David Bauer <mail@david-bauer.net>
Before this commit the decision whether a vxlan layer will be
introduced between the lower interface before the interface is
added to batman was inside the proto. Now the decision is moved
to the user of the proto.
This adds the OpenWrt label-mac device selection as the most preferred
fallback.
While this is only used on OpenWrt 19.07 for backports, we can also use
the label-mac device when backporting device support. This way, we have
to deal with less device-sepcific code downstream.
Signed-off-by: David Bauer <mail@david-bauer.net>
In multidomain setups, VXLAN is enabled by default, but can be disabled in
domain configs using the mesh/vxlan option. In single domain setups, the
mesh/vxlan option is mandatory.
The UCI option for legacy mode is removed.
Fixes#1364
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.
Our VXLAN setup was changed to accept VXLAN packets without checksum almost
2 months ago, so we can disable sending the checksums now as well. Slightly
improves performance.
Also disabling TX checksums and not only allowing incoming packets without
checksum will provide another small speedup. As doing so would break wired
meshing with VXLAN-enabled nodes that require non-zero checksums, we will
wait a few days before this step.
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>
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]
Device information can be found at:
http://www.8devices.com/products/carambola-2https://wiki.openwrt.org/toh/8devices/carambola2
I only did some minimal testing of gluon on the carambola 2 development
board:
- Config mode works
- Connects to Wifi Mesh
- Allows clients to connect
Notably, autoupgrade has not yet been tested.
Change to 010-primary-mac is necessary as the mac address printed
on the sticker is the one of eth0, not the wifi mac.
Adopt the according modifications to the default firewall settings of
the WAN interface from OpenWRT, revision 45613.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
This new feature introduces the new uci section 'gluon-core.wireless' with a preserve_channels option:
* preserve_channels (boolean)
By setting this option to 1 (true) wifi channels will be preserved during upgrades.
