Archive | Uncategorized RSS for this section

Brief notes on Batman-adv

Theoretical Ideas

Batman-adv is a distance-vector mesh routing protocol which acts completely on L2 (or 2.5 as it is said often).

  • “Batman-advanced operates on ISO/OSI Layer 2 only and uses and routes (or better: bridges) Ethernet Frames. It emulates a virtual network switch of all nodes participating. Therefore all nodes appear to be link local, thus all higher operating protocols won’t be affected by any changes within the network.” [3]
    I guess that the topology info for the vis-server is propagated using the protocol so does not add significant overhead
  • “In dense node areas with low packet loss B.A.T.M.A.N. III generates quite some packets which increases the probability of collisions, wastes air time and causes more CPU load. Each OGM being 20 Bytes small, B.A.T.M.A.N. IV introduces a packet aggregation that combines several distinct OGMs into one packet.” [1]
    But still the problem exists in dense node areas no matter the aggregation since it is inherent of dealing with the environment.
  • “A virtual interface is provided (bat0), which can be considered as a usual ethernet device (probably with a little more packet loss 😉 )” [1]
  • “From a couple of years B.A.T.M.A.N. has moved from a layer 3 implementation to a layer 2 one (2.5 would be more correct as it resides between the data-link and the network layer running in kernel and not on NICOS but using MAC addresses) without changing the routing algorithm. B.A.T.M.A.N. now represents a new level in the network stack, with its own encapsulation header and its own services. It became totally transparent to the IP protocol since it now works like an extended LAN with standard ethernet socket exposed to the IP layer.” [2]
  • “at the IP layer, every packet sending operation is seen as a one-hop communication” [2]
    Would we need a L3 protocol then, in case there is no communication with the external world (other networks)?

Technical Facts (that were usefull to me)

  • The batman-adv module on the debian wheezy repo uses the built 2011.4.0 which runs the Batman-IV routing algorithm.
  • Batman-adv module cannot be loaded separately inside LXC for each container because cannot insert modules so it can be simply associated to a namespace. Therefore, the virtual interface should be created in the host and be used somehow by all the containers. Specific integration with from the part of batman-adv module does not exist.
  • Upto the version 2013.2.0 (current) vis functionality was part of the kernel module. This was changed as mentioned here: “This is replaced by a userspace program, we don’t need this
    functionality to bloat the kernel.”


In 2010 it had problems with node-failure, while 802.11s dealt very good.[1]

We can note that batman-adv is generally more stable.[1](than 802.11s in terms of links)

networks performance decreases sharply after two hops for both voice and Ethernet sized packets.[2]

BATMAN was proven to work as well in an environment with significant interference and longer distances between nodes as in a friendlier setting. In contrast, AODV often failed to provide stable routes in cases where multi-hop communication was necessary[3]

Since it’s third version (v.2011.3.0) batman-adv has much improved performance.[4] (after the evaluation papers were written )

Batman can be used for any kind of interface.

Final thought

Finally, I want to share with you a interesting article, presenting a different motivation beside mesh-netorking: Mesh networking with batman-adv


Ultra-short LXC troubleshooting

Not mounting the directories

The sys_admin capability should be enabled in order for the filesystem to be mounted correctly when the container boots.

Not connecting to the console and respawing

The ttys should be allowed in the config file.
An example working config file can be found here
Looking at the file rootfs/etc/inittab the tty device that is spawned after the initialization can be found. In order to start tty1 and tty2 something like this should exist:

1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2

These ttys should also exist in the roots/dev folder or should be created:

root@sth#mknod -m 660 dev/tty1 c 4 1
root@sth#mknod -m 660 dev/tty2 c 4 2

Then a connection to the console should be started:

lxc-console -n myfirstcontainer -t 2 # Number of tty

Remote Mininet VM with Virtualbox in Debian Host

Mininet before version 2.0 did not come with an easy way to reach the Internet through the mininet VM. Mininet 2.0 VM comes by default with connection to the network of the host, overriding this problem.

I am now going to describe how to invoke mininet to a remote Debian host through ssh and rdesktop using VirtualBox in a headless mode. Virtualbox is assumed to be installed.

-Get Mininet image (>2.0)

# Download Mininet 2.0 ubuntu image
# Extract

-Prepare Virtualbox and import VM

# Get and install vbox extension pack for vrde support (remote desktop)
# Get a version corresponding to your vbox version
vboxmanage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.2.12-84980.vbox-extpack
# Import vm, the name of the vm will be "vm"
vboxmanage import mininet-vm.ovf
# Turn vrde on 
vboxmanage modifyvm vm --vrde on
# Set authentication using hosts credentials
vboxmanage modifyvm --vrdeauthtype external
# Start vm with vrde running in port 5001
vboxheadless --startvm vm --vrde config

-Connect through with rdesktop through Linux client

# Connect to the vm with host IP (, username and password
rdesktop -a 16 -u user -p password -N

To connect with the windows client mstsc.exe a .rdp should be created which should contain the username and password (help).

-Enable ssh

# Enable ssh to port 8082
vboxanage modifyvm vm --natpf1 "ssh,tcp,,8082,,22"

Now mininet is ready for remote use through remote desktop or ssh ;-).