Two distinct Networks with batman-adv

Hi there

I already have some kind of believe what my issue might be but I'd love the here your thoughts on that.

Setup
My goal is to have two completely distinct networks spanned in one single physical mesh network (for kind of security and management of the clients by given hardware). The hardware I am using are two Fritzbox 3370 (https://openwrt.org/toh/avm/fritz.box.wlan.3370) and two TP-Link TD-W8970B v1.2 (https://openwrt.org/toh/tp-link/td-w8970_v1)
What I have done to achieve this is setting up a batman-adv mesh network similar to most tutorials (https://openwrt.org/docs/guide-user/network/wifi/mesh/batman). Basically it is

  • 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.

VLANs work on a BATMAN mesh, e.g. bat0.1 and bat0.2 will be separate networks. It is just like you would do with an Ethernet cable.

1 Like

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)
[...]

1 Like

Thanks for the very quick response. Just in that second I was adding my last line about the VLANs in my original post :slight_smile:

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.

1 Like

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.

In that case, you add the bat0.nnnn to the bridge that the AP's SSID is configured to connect to, and possibly a wired connection. Some examples at https://openwrt.org/docs/guide-user/network/wifi/mesh/batman#bridge_vlans_over_batman-adv

@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.)

https://ask.wireshark.org/question/2506/how-do-i-use-ssh-remote-capture-in-wireshark/, for example, suggests that there is some remote-capture facility within Wireshark. I haven't tried it myself.

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

ssh root@openwrt tcpdump -i bat0 -w - | wireshark -k -i -

usually works.

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.

2 Likes

I was hoping for something simpler like what "routes" are for IP protocol. But I do comprehend what you are suggesting an will have a look later.

Again thanks a lot for the help.

Best regards

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.