I have submitted a pull request for LuCI support for the batman-adv protocol and would be very grateful if someone could test it : LuCI Support for batman-adv
Super stoked to see this! Literally two days ago I was wishing this was a thing... I was about to rule out batman-adv for my network because there is no luci-proto package. While its previously been no problem for me to do the network config manually, I tend to gravitate to the web-ui for things - and its nice to do stuff with the smartphone sometimes.
I'll check this out in the next week, and try to remember to report back.
2 Likes
Hey looks good! Only criticism is that I would simplify the protocol names to be shorter like "BATMAN-adv master" / "BATMAN-adv hardif" or something. "B. A. T. M. A. N. advanced interface" is a bit long... Otherwise its great, and I actually appreciate the wordy help bubbles.
I was able to set up a working batman IV mesh on OpenWRT 21.02.2 by following these steps on each node:
- remove wpad-wolfssl-basic
- install wpad-wolfssl, kmod-batman-adv, batctl-default
- install luci-proto-batman-adv (of course this doesn't exist yet - I just copied your new proto .js files from https://github.com/openwrt/luci/pull/5698 into /www/luci-static/resources/protocol/ )
- reboot the device
- create both a batman-adv master, and hardif interface
- create an 802.11s encrypted mesh with WPA3, and attaching to the hardif from (5)
- create 802.1q VLANS on the batman-adv master for each network (no DSA support on my devices)
- add each of the vlans from (7) to their respective networks' bridges.
It think the last steps are easier with DSA, you just add the master interface to your main bridge and then set up the tagged members under the "bridge VLAN filtering" tab.
EDIT: This was all 100% done in the luci UI - with the exception of copying the protocol .js files... But once you get your PR, it will be easy for the masses to follow a youtube guide on batman-adv mesh setup. @onemarcfifty You ARE gonna make a new video once this goes through, right? 
2 Likes
Hey, many thanks for testing ! w/r to the protocol names - yes, we can change that - let's see what other testers think about it. And yes - there will be a video I have just set up a test mesh with 6 Asus lyra MAP AC 2200 nodes and it works like a charm Need to talk my neighbor into sharing his internet connection with me in order to have multiple gateways maybe
1 Like
I haven't tested it properly, but I copied the script files to one of my routers and had a quick fiddle with the settings on my existing mesh interfaces and also tried creating a brand new master and interface.
All seems good to me.
I think it might be helpful to add "Master", or "control" or somesuch to the "B. A. T. M. A. N. advanced" protocol name as it would make it clearer which one does what.
I noticed when I made changes, that it removed a few of the existing settings from my bat0 interface, but having checked, it turns out they were all set to their defaults, so it is working as intended.
Many thanks for testing! I have suggested ("batman main" and "batman interface") or ("batman device" and "batman interface") on the pull request - would that sound right to you ? It's shorter and at the same time allows to distinguish the two
Either seem good to me, possibly yet another option, although not one I favour, could be batman meshif and batman hardif, as I seem to recall those also being used in some documentation.
Thanks for creating this, good to see support for batman in the UI, it would have been helpful to me when I was setting mine up.
My apologies for not replying sooner.
I tried it and it won't let me enter the wireless interface settings.
You mean on the hardif ("Batman Interface") - presumably in the "Device" dropdown, right ? What exactly happens there - can you select the Wifi device but it has no effect (which would be expected ecause this is how things work without LuCI) or is there no item for the Wifi at all or are you unable to save when you enter a Wifi network ? If it is the first case, then please see the helptext at the bottom of that form :
"If you want to assign the batman-adv interface to a Wi-fi mesh then do not select a Device in the Device selector but rather go to the Wireless settings and select this Interface as a network from there."
I followed the commit instructions. I have also installed the .ipk file. I created an interface with the "Batman Device" protocol called "bat0". Then I created another interface (without pressing Save & Apply) with the protocol "Batman Interface" and it does not appear in "Device" "bat0". For it to appear I had to press "Save & Apply" before creating the "Batman Interface". I clarify the "Save & Apply" because in another case like creating a simple bridge in "Devices" and then creating an interface in "Interfaces", the newly created bridge appears in the "Device" section without pressing that button. Maybe it's a mistake, so I mention it.
The interface "Batman Interface" is called "mesh". When entering the edition I see in "Device" "bat0" and in "Batman Device" "bat0". This interface is what I select under the 802.11s interface in the "Network" section. Only this is the one that appears in that section. And here is an error in LuCI trying to enter the 802.11s interface after choosing "mesh".
And the browser console shows this error.
After deleting the two new batman interfaces, it allows me to log back into the 802.11s edition or the other AP interfaces.
I also have two bridges called "br-lan" and "br-lan2" which are for the private and guest network respectively. In each one I added "bat0.1" and "bat0.2" respectively also in case it has something to do with it.
I have Device unspecified in the BATMAN Interface, and only batman device is set to bat0. Providing device is left unspecified I don't get that error.
With Device also set to bat0 in the batman interface, configuring the "Network" to my mesh in the wireless mesh point's settings adds "option type 'bridge'" to the mesh interface in network, which seems to be causing the TypeError issue. (also seems to stop "save" closing the pop-up window)
# /etc/config/network
uci set network.mesh_2ghz.type='bridge'
# /etc/config/wireless
uci set wireless.mesh2.network='mesh_2ghz'
config interface 'mesh_2ghz'
option mtu '2304'
option proto 'batadv_hardif'
option master 'bat0'
option device 'bat0'
option type 'bridge'
Removing bat0 from device in the batman interface doesn't get rid of the option type 'bridge'
Deleting "option device 'bat0'" and "option type 'bridge'" from /etc/config/network sorted it, but this obviously needs fixing.
I confirm that the red error appears when I have "bat0" in "Device" within "Batman Interface". I also see option type 'bridge' on this interface and it appears only when I choose this interface on 802.11s.
root@ap:~# cat /etc/config/network
config interface 'bat0'
option proto 'batadv'
option routing_algo 'BATMAN_IV'
option gw_mode 'off'
option hop_penalty '30'
config interface 'malla'
option proto 'batadv_hardif'
option device 'bat0'
option master 'bat0'
option type 'bridge'
root@ap:~# cat /etc/config/wireless
config wifi-iface 'wifinet2'
option device 'radio0'
option mode 'mesh'
option encryption 'sae'
option mesh_id 'malla'
option mesh_fwding '0'
option mesh_rssi_threshold '0'
option ifname '2g_malla'
option key '000000000000000000000000000000'
option network 'malla'
I've also tried removing bat0 and leaving Unspecified and still the red error and the option type 'bridge' line.
root@ap:~# cat /etc/config/network
config interface 'bat0'
option proto 'batadv'
option routing_algo 'BATMAN_IV'
option gw_mode 'off'
option hop_penalty '30'
config interface 'malla'
option proto 'batadv_hardif'
option master 'bat0'
option type 'bridge'
In the end, I have the same results as you. Even the Save button.
This happened to me not long ago when I wanted to create a guest network and that line appeared in config device and in config interface and for it to work I had to remove it from config interface.
The errors are several. The interface "Batman Interface" does not find "bat0" after creating it without saving.
I see all the errors appear when "bat0" is selected before "Batman Interface" is selected in 802.11s. If it is selected after having chosen in 802.11s, neither the red error nor the option type 'bridge' line appears.
Many thanks Franco. The "Device" should not be selected when you add a Mesh (as it is stated in the help text). So the Device dropdown needs to be empty in this case really. That explains the errors you have seen. Still unsure why it marked the device as bridge. Presumably because there was already a Wifi attached to it. Overall this behaviour is expected. I might add an additional check on the parameters that avoids selecting bat0 as the device though.
Many thanks for testing - the "device" should not be set to bat0, only the "Batman Device". The Device is what you put under control of the bat0. I might add a check for this so that a batman device can't be selected here.
Yes, I was trying to reproduce the error and added it because I guessed this was the cause.
When Batman Interface is selected for the protocol in the "Add new interface" a field for Device is shown - would it be possible to change this to set the batman device (option master), or omit it. Otherwise, I think it likely others will try to set device to the batman device they've just added.
Would "device" ever be used in a batman hardif? If not it would be better if the option to set it in the UI did not appear, if that is possible.
Thanks for your hard work.
Totally agree. It's confusing. Yes, you might want to select a device here if you want for example extend your mesh over wired portions (e.g. eth0.xx) - then you would select that device here. I need to run some tests in order to see how I can preload, check or omit that dropdown.
1 Like
It was very confusing. It would be nice to indicate which device to select (or not) depending on the use case. And regarding the bridge, I have seen that if I didn't select bat0 in "Devices", it showed that it was not present, so it makes me think that adding this interface in 802.11s, the system thinks that it has to be a bridge because there is 2 devices. I think it's a legacy behavior when there was no separation between "Devices" and "interfaces".
Hi Franco - yes, I agree - it is confusing. I played it through after your first post and instantly went „doh!“ - the intuition would tell you to select the batman device… I will most probably not be able to fix it in very short term but I will fix it. Thank you for your time and effort in testing this!
2 Likes
I keep seeing br-lan: received packet on bat0.1 with own address as source address (addr:"mac-eth0", vlan:0) in the system logs on both devices.
I am getting these warnings in my log too, but I have used the command line to configure batman. I am not sure why, but all my devices have the same mac-address.