FAQ

If you are missing a question/answer (quite likely) please use the BATMAN mailing list or IRC channel to trigger us.

General questions

Does B.A.T.M.A.N. have simulator (NS2, Omnet++, etc) support?

At this point no B.A.T.M.A.N. implementation (we know of) supports simulators like the ones mentioned above. However, some people experiment with B.A.T.M.A.N. using emulators (UML/Qemu/etc). If you are looking for step-by-step instructions to install such a system you can read our emulation document.

How to make my mesh network secure ?

What kind of security do you need? Security is a big field. Maybe you just mean encryption and authentication.....

When you only want to make the whole wlan stuff unreadable for the outside, you could just use WPA_NONE or IBSS RSN. But this doesn't resolve the problem that the key could leak and make the mesh attackable - but that is something which could always happen. So it is probably not a solution for wifi community projects, but for mesh networks controlled by a company.

There are other ideas for traffic over batman-adv. Just forget about encrypting your data on the wifi layer, but instead do everything some layers above. Some people experimented with the idea of implementing the needed authentication and encryption over IPsec.

And most of the encryption and authentication stuff has to be resolved by the user and not by the network provider. This means https for sensible data instead of http, ssh instead of telnet, pop3s instead of pop3 and so on.

So it really depends what you want and cannot be resolved in a "security for everything, against any attack and for every purpose" blob.

Why does batman need so much time to detect a "dead" node ?

Or: Why can I see a node in the originator table a long time after it died ?

Or: Does batman really need 200 seconds (PURGE_TIMEOUT) to switch the route ?

Batman switches the route as soon as it learns about a better path towards a destination which can take a fraction of a second up to several seconds very much depending on the settings and situation. When no more new originator messages are sent by a node (because it died), no more routing updates regarding this node are exchanged. Batman will not immediately delete this node from its database because the connection could just have a temporary problem and might recover. Only after a timeout period of (currently) 200 seconds the node is removed entirely from batman's internal database. It does not hurt to give the node a little extra time to recover from a connection loss as it speeds up the resume process. All routes using this "lost" node as intermediate hop will have changed towards another path in the meantime and are of no concern.

batman-adv - general questions

Can batman-adv run on interfaces in AP / Station / etc mode ?

batman-adv doesn't know anything about stuff below the ethernet interface. So you could also use it over layer 2 ethernet tunnels, wifi ap, wifi sta, wifi adhoc, ethernet or even write a virtual interface which prints everything on paper and scans the paper on the remote machine (but you should be fast or increase the ogm interval).

How can I connect non-mesh clients to my batman-adv network ?

The batman-adv quick-start-guide explains how to bridge your standard AP / Ethernet interfaces with bat0 which can be problematic if you only possess one WiFi card. In these cases it might be desirable to run adhoc mode and AP mode at the same time. Fortunately, some WiFi chips / drivers support a so-called "multi VAP" (virtual AP) or "multi SSID" mode to have multiple WiFi networks on the same WiFi interface.

How big networks does batman-adv support?

That is a good question. It is not possible to give an exact answer, but there are several parameters limiting the number of nodes in your network:

  1. Capacity of the wireless network
    Usually, the performance of the wireless network renders unusable if you add too many nodes (huge delay and low throughput).
  2. Memory footprint
    Each node in the mesh network holds information in memory about every other node, so little memory might limit the number of nodes.
  3. Protocol overhead
    Each node sends "here-I-am" messages to the entire network at a regular interval. These messages are aggregated when possible, to reduce the overhead.

How do I announce IP subnets using batman-adv?

batman-adv is a layer2 routing protocol and it does not handle IP subnets at all. If you want to do IP subnetting, the suggestion is to split the mesh network in different sub-meshes (e.g. different ESSID/BSSID), and run a batman-adv instance in each of them.

As shown in the picture, the result consists in having multiple meshes working independently from each other. In particular the border nodes like C, D and E will participate in more than one mesh network and will consequently have more than one batman-adv interface (e.g. bat0 and bat1): each of them assigned an IP belonging to a different subnet.

At this point the border nodes can run an instance of any dynamic IP routing protocol (e.g. OSPF or BGP, both implemented in Quagga) which will see each of the batman-adv mesh network like a single link towards the other (border) nodes in that network.

Note that also nodes connected to the Internet like A and B can be considered border nodes (this is configuration dependant) and can eventually run the IP routing protocol instance too.

It is extremely important to do not run any layer3 mesh routing protocol on top of nodes using batman-adv: this would result in wrong link quality computation by the overlying protocol which will see the whole batman-adv network as a single link (even if a path to a node is made up by multiple hops).

However the interaction of Quagga with the mesh network will be "batman-adv-agnostic" since there is no way to exchange information between the two. The creation of a batman-adv plugin for Quagga could help in this direction by letting Quagga extract TQ (the metric used by batman-adv) information to compute link qualities towards other border nodes in the mesh network. This would avoid the IP routing protocol to choose bad mesh nodes as next hop in the IP routing. As extracting/using TQ in other protocols is just an idea/proposal right now, please contact us if you want to do that.

batman-adv - bridge loop avoidance questions

Why do we need BLA II if we can just use mesh on Ethernet?

Or: Under Discussion -> Features you say "no BATMAN packets on the backbone".
Why would you want to use the mesh (which never has enough bandwidth anyway) if you have a fast, reliable backbone link between some of the nodes. Wouldn't it make more sense to get as much done through the backbone as possible?

You can explicitly use batman-adv on the mesh if you want to - batman-adv allows adding Ethernet interfaces as well. This is a good idea if you have full control over your LAN. However, there are users who don't want to see batman-adv ethernet frames (with its special ethertype 0x4305) on their LAN, because some firewalls recognize it as malicious traffic. Therefore, one design goal of blaII was to keep batman-adv packets out of the backbone LAN in the default case.

What about two meshes interconnected by a LAN?

Or: So, does this mean that with current blaII, two meshes connected solely by ethernet backbone (which can't overhear each other OGMs through wifi) only know which macs are "on the other side of the ethernet backbone" so as to keep the single broadcast domain united, but are fragmented in terms of VIS data, gw, TT, and orig table?

Yes, there are two separate meshes, and the only stuff which is supposed to be shared is the users payload traffic.

What about DHCP server for separate meshes?

Or: Then, how can I make two separate meshes use a single DHCP server (using gw_mode feature) in current blaII design?

Each node at the edge to the wired network may announce itself as a gateway, provided that a DHCP server is available in the LAN (or any network behind it, e.g. a mesh). From a concept view, a gateway (or maybe even multiple gateways) in mesh2 will not automatically announced in mesh1 - this must be configured manually, or let batman use Ethernet if this is explicitly required.

batmand related questions

Understanding the version and compatibility number

The version number (defined as SOURCE_VERSION in the source)is the one displayed when launching the batmand in debug mode. It indicates the state of your code.

The compatibility number (defined as COMPAT_VERSION in the source) is transmitted with every broadcasted OGM to guide other batmand instances receiving this OGM whith the decision about incompatible protocol versions.

Why are multiple interfaces problematic?

The internet (and most network technology today) was designed with the idea that every interface on a given system has a unique broadcast adress. When a packet enters a system the kernel has to decide where it should be routed to. While using the same broadcast adresses on different interfaces you provoke an undefined situation as this should not happen (by design) and the result is unpredictable. In that case the Linux kernel will send all your packages to the first interface (in the routing table) with that broadcast address.

A solution to that problem is the usage of the Linux kernel option "BINDTODEVICE" which allows to specify an outgoing interface for a packet. Unfortunatly this option is a Linux-only feature (as far as we know). Therefore you won't be able to use multiple interfaces with the same broadcast addresses on other operation systems than Linux.

Log larger amounts of debug messages

First, install netcat on your device. On a OpenWRT based distro you can try this (packet version may vary):

ipkg install http://www.linuxops.net/ipkg/netcat_0.7.1_mipsel.ipk

Then start batmand and pipe the output into netcat:

batmand -d 4 <your_interfaces> | nc -l -p <any_unused_port>

Finally start the netcat client on your logging server and save the output:

nc <IP_of_your_device> <your_unused_port_from_step_2> > batman.log

If you use a firewall, NAT or any other problematic network setup you can swap the netcat server position. Beware: Your netcat server has to be started before you start your netcat client.

Update many Openwrt based systems

1. Download the update script: update script
2. Edit the the variables in the configuration section of the script to match your needs.
3. Run the script. ;-)

Note: The HOSTS_TO_UPDATE variable in the script expects SSH host names which must be configured in your ~/.ssh/config file.

Tip: Use key based access to authenticate your login request on your machines to avoid typing your passwords too often. If you use encrypted keys you can enable the ssh-agent to manage your passwords.

What is the batgat kernel module good for?

The batman daemon maintains a tunnel connection to every "batman internet client". Every packet that goes to the internet or comes back has to go through this tunnel. As it is a user space tunnel a lot of copying between user space and kernel land is necessary. Depending on the number of clients and the CPU power available this might be a bottleneck.
The batgat kernel module tries to overcome this limitation. Once loaded the batman daemon will detect its presence automatically on startup. The daemon will activate the kernel module to let it handle the tunneling, hence avoiding the expensive copy operations. There is no difference between the daemon tunneling and the kernel tunneling other than that.

quagga_integration.png (86.7 kB) Simon Wunderlich, 10/17/2012 10:36 pm