configuring mesh WiFi (encrypted 802.11s mesh in my case) - called bridge since it connects the routers
adding and configuring bat0 interface
configuring the actual WiFi for the clients with an interface to connect to
bridging them together
which is working quite ok.
Afterwards I have done exactly the same thing again on all the routers with a bat1 interface where the wireless connections are not encrypted. Please Note that for all networks only one real physical net exists. Therefore I would expect the signal strength to be the same for all the networks.
The Issue
From time to time (way too often) it happens that one of the bridge networks (batman interfaces) are connected as the luci wireless page shows but the RX / TX Rates are on 1.0 Mbit/s and not changing at all. That implies a not working connection. I can confirm that this setup would work in theory by simply disabling the working networks (and maybe rebooting). I also can confirm that in a small test environment with two routers this approach has worked at lest once.
I would happaly provide more information about the interfacec (DHCP servers, clients, ...) if needed
My Conslusion
With that said I feel like there is simply a hardware issue. Maybe there are to many virtual networks with to many connections. Could that be the case? Do you have any other approaches in mind? Maybe you have done the same thing on different hardware?
Best regards and thanks a lot!
EDIT:
Of course VLANs came to my mind but I was not able to figure out ho to distinguish devices connecting to WiFi.
batctl can provide a lot of insight into what batman-adv thinks is happening. batctl n and batctl o are the two I often use, and the "help" includes
-m mesh interface or VLAN created on top of a mesh interface (default 'bat0')
so that you could focus on both meshes.
Last I looked, LuCI didn't understand 802.11s interfaces too well, so I use iw commands to see what the radio really thinks.
I carry multiple VLANs on a single bat0. If your dual-mesh approach doesn't work, that may be something to try.
Edit:
VLAN MMMM -- bridge over WIFI_SSID_XXXX and bat0.mmmm (and, perhaps, ethN.mmmm on your gateway)
VLAN NNNN -- bridge over WIFI_SSID_YYYY and bat0.nnnn (and, perhaps, ethN.nnnn on your gateway)
[...]
Thanks for the very quick response. Just in that second I was adding my last line about the VLANs in my original post
Since you seem experienced in that manner... Could you explain to me how I would distinguish the clients and route there traffic over bat0.1 and bat0.2 ?
EDIT:
I just read through jeffs post and I do think I understood the explanation. I will try it out. Thanks a lot.
Assuming that you don't have any mesh participants other than your OpenWrt boxes, then those clients are associating with a specific AP with its own interface on that OpenWrt box. For most poeple, that is the situation. Phones in my house connect to "Guest Wireless" or what have you, not to the 802.11s mesh.
@jeff
I tried right away and it is looking good for me. Would probably have been the bedder approach from the start...
Anyhow I'd like to ask how you would confirm the batman VLANs are working as intended. I have tcpdump installed already and can more or less check the amount of packets going through by issuing tcpdump -i bat0.1. But since I am not really looking for anything in particular it feels somewhat naive to me to simply trust I configred everything the right way an nothing is leaking.
In any case thank you a lot for pointing out this much bedder way to handle things!
Wireshark can be valuable in a situation like this, as you can capture everything and then filter the packets in its GUI. It's a little tricky to run on your desktop but collect on the router, but can be done.
The easiest is to run tcpdump into a file on /tmp/ then scp it from/to your desktop and open it with Wireshark. The only drawback is you can't poke things and immediately see them in Wireshark. (See below for capturing raw packets to the file, not the parsed information.)
I've found that running tcpdump on OpenWrt into a pipe into Wireshark can be challenging with passwords and even more if you don't permit root login and use sudo. Setting up root with SSH keys can help, especially if using ssh-agent. With that, something like, from your desktop
I believe that Wireshark should be able to "see" the VLAN tags on the traffic of the bat0 interface. If not, you might have to check bat0.mmmm and then bat0.nnnn.