finally the big release day has come. As of this moment B.A.T.M.A.N. 0.2 final
is released and can be downloaded from open-mesh.net/batman/downloads. The
most important added features since the release of 0.1 include:
- many cpu and memory usage optimizations
- ability to give access to the various debug levels without restarting the
- Big Endian / Little Endian support added
- 64 Bit compability added
- a lot of tweaks to the algorithm in order to ensure a smoother experience
- download store which automatically generates ready to install packets for
- support for sending neighbor-connectivity data to a central visualization
Regardless of the mentioned release, the developement process didn't stop
there. So, in addition to version 0.2 final, we are very proud to announce
the release of B.A.T.M.A.N. 0.3 alpha. Major changes and improvements are:
- debug level 5 added which shows memory or cpu usage if the compile option
- harden batman against any clock changes whatsoever
- 3 different routing tables are used: table 65 for announced networks, table
66 for batman host routes and table 67 for the default route
- the batman default route is not shared with other wireless nodes any longer
- a batman gateway acts as a tiny DHCP server and hands out IPs to gateway
- the gateway tunnel is now a fully enabled tunnel which transports the data
to the gateway and back as well
Our ambition brought us even beyond this point, all the way down to layer 2.
B.A.T.M.A.N. Advanced was created. This new approach to wireless networking
does no longer operate on the IP basis. Instead 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. You can theoretically run almost any protocol above
B.A.T.M.A.N. Advanced, prominent examples are: IPv4, IPv6, DHCP, IPX. Due to
this highy developmental technique of layer 2 based routing there are no
experiences we can build upon and hence would be very grateful for intensive
testing and information exchange, as we do not possess the capabilty for a
full-blown testing environment ourselves and always apreciate the input given
by our very active community and trust the very good experiences we had.
Since the nodes participating in the B.A.T.M.A.N. Advanced switch are
completely transparent for all protocols above layer 2, we needed to build
our own diagnostic tools which are also released today. These tools contain a
layer 2 version of ping, traceroute and tcpdump. Further information can be
found in the enclosed README file.
As layer 2 routing is somewhat of a blackspot on the landscape of mesh
networking we plan a workshop i.e. demonstration evening about how and why
B.A.T.M.A.N. Advanced works. In order to make it a useful event for all
parties involved we would like to decide on the topics covered not for, but
with you. So, if you have ideas, critique or general advice please share your
thoughts with us.
someone kow, how i'can compile the VIS Server to a FREEBSD System?
have a nice day,
The box said: Requires Windows VISTA or better. So I bought a Macintosh.
we are VERY pleased to hear that there are quite a few people from outside
Berlin considering to come to the release party. Of course these pionieers
are not coming without expectations.
Therefore we want to reserve and announce some extra time now (besides the
usual gathering and celebrating) for an open discussion and the exchange of
experience related to the batman routing protocol.
The gathering will be integrated in the regularly Waveloeten workshop
( http://wiki.c-base.org/coredump/WaveLoeten ) which happens every Wednesday
at the C-Base ( http://c-base.org/ )in Berlin.
For the discussion we propose to start at 8:15 pm
( 20.6.07 Rungestrasse 20, 10179 Berlin )
A list of topics may include but is not limited to:
* Why BATMAN at all? After many years of optimization OLSR seems to be quite
* Does BATMAN really redeem what it claims?
* What means exist to allow a smooth migration from an existing routing
protocol and which problems can be expected.
* The one-does-it-all solution (Eierlegende Wollmilchsau) does not exist so
what are the disadvantages.
* Which skills are needed to set up a somehow working or a productively usable
* Which parameters exist to better adapt the batman implementation to local
* Do user prefer an aggressive or a conservative revision and versioning cycle
* What is missing (besides documentation)
* Please feel free to add your topic here!
What would you expect to hear from a decent batman / batman advanced
presentation / workshop ?
looking forward to see you,
the B.A.T.M.A.N. development team
I got a interessting paper forwarded which discussed routing in tcp on
ad-hoc networks (especially tcp vegas). The idea was like that:
If the routing protocol notices the tcp stack that the route has
changed, it can recalculate some of its parameters (here the BaseRTT
value) to optimize speed.
Implementing meshferry, a tcp over udp proxy to surround most of tcp
problems, I can see a lot of usage for this. Because batman doesn't know
the topology itself, i thought about a mechanism to detect route changes
without knowing topology itself.
All batman originator packets would become an additional flag, lets say
uint32. When batman starts, it generates a random uint32 for its
On a new broadcast message, it sets this new flag to his own random
value. If it rebroadcasts a message, it used the original value XOR its
own. This mechanism detects route changes very likely and even batman
If the this new flag changes, the route somewhere in the network has
changed, it can't say where, but it doesn't have to.
The operations are cheap, the overhead is small. And allows analysis if
routes are more static or switching (would be interessting to see).
Long term I was thinking about a socket interface between routing daemon
and transport daemon. For the case of switching routes, batman would
then notify the route to host x has changed somehow, so he can optimize
-----BEGIN PGP SIGNED MESSAGE-----
another feature i forgot in the last mail :)
It would be great if batman allows to dynamic add and remove announced
networks via the unix socket interface.
# adds new announced network
batmand -c -a someip/mask
# removes some announced network
batmand -c -A someip/mask
we are working on the posibility to give a computer in the mesh a unique
ip, besides the network the node is serving. if you assign a unique ip
to a computer, and get a dhcp lease of another node, the node would then
add your ip as a hostroute announcement to batman, which would overwrite
the default place: your home network. this would mean real mobile ip
without the overhead of sending the traffic to your home router and then
forward to your actual position.
besides this, it would allow better integration into bgp by simply
spawning a script to add/remove routes via zebra.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
i'm new in this list, and i'was like to say everybudy hello ... I'm
from germany naer Magdeburg. my age is 42 and i'm male ;)
what i'want here? of'course know more about b.a.t.m.a.n to build and
make our local mesh-net better. here, we dont get some
dsl line or somthing like that, so we have to help us self. her we
have a fast direct wlan connection to Magdeburg with 5ghz hardware.
and local we use at the this moment olsr for our mesh-net. i'was try
batman and i'was get the feel, he is runing better. so it's means
i'like to try a clear batman mesh-network. without any olsr. so, for
that i'm here ;) and maybe it is possible.
so, my english is not so mutch perfect ... but i'hope, not to mutch
have a nice day
B.A.T.M.A.N.-Release-Party Wednesday 20. june at the C-Base in Berlin.
The B.A.T.M.A.N.-developer team would be happy to celebrate with YOU the 0.2
release of B.A.T.M.A.N. at the C-Base (in Berlin). FYI, there will also be a
free barrel of cool beer waiting to be flushed.
Version 0.2 can reasonably be called stable now. It works quite performant,
supports multiple interfaces, has a low CPU-load, a robustly working
algorithm underneath, and autonomously negotiates UDP-Tunnels to GWs which
ultimately enables long-term and stable internet connections.
A number of users reported quite excitedly about the amazing experiences they
made with this protocol. Well, we want to stay neutral so join in to hear
them and try batman for yourself.
Currently B.A.T.M.A.N is available for Linux only. The ports for Mac OS-X and
BSD have fallen asleep and are waiting for a diligent bee ... Maybe there
will once also exist a windows port.
Many thanks to all the people who helped to realize this in such a short
amount of time.
We are thinking about printing further T-shirts with the B.A.T.M.A.N.-Logo (as
you can see on http://open-mesh.net/batman ) and sell them at the cost of
expenses. Unfortunately the price is not clear by now but will be about or
less than 15 Euro. If you are interested please send a mail with your size
and the limit you are willing to pay.
Considerations for the parallel operation of OLSR and B.A.T.M.A.N.
In Berlin we are now facing a phase in which both routing protocols will
be used in parallel. Currently we are aware of one issue where this can cause
problems. This is in case of OLSR-Internet traffic passing a dual-stack (OLSR
and B.A.T.M.A.N.) node where the B.A.T.M.A.N daemon is configured for
tunneled GW selection. Then each OLSR-towards-internet packet will be
magically caught and warped to the currently selected (and maybe several hops
away) B.A.T.M.A.N. GW. where the packets pop-up again and follow their usual
path through the internet to their final destination. This has caused
confusion since also programs like traceroute do not show the intermediate
hops which the packet has passed (tunnelled) between the related
B.A.T.M.A.N. node and the GW.
This is because such a dual-stack mesh node (where the B.A.T.M.A.N daemon is
configured for tunneled GW selection) consequently has two default routes.
One due to OLSR and another due to B.A.T.M.A.N.. The thing is, that both are
ending up in the same routing table and one of them (the latter) has a higher
priority than the other. So every packet passing along with a destination
address matching only the default entry of the routing table will end up in
the tunnel to the currently selected B.A.T.M.A.N. GW.
The Internet-GW selection mode of B.A.T.M.A.N. is optional and should be
disabled or used with care especially on nodes with a dedicated RF-postion
(and such used by many others as an intermediate hop) like churches and other
high buildings. Enduser using Notebooks or PDAs should be able to use this
feature without causing trouble.
In order to make the parallel deployment of both protocols even more smoothly,
a number of new features have found their way into 0.3. Then it will also be
possible to maintain and use a the OLSR and the B.A.T.M.A.N. default route in
Therefore we will also release the first version of the upcoming B.A.T.M.A.N.
generation (0.3 alpha).
At the same time we already began working on the next generation of
B.A.T.M.A.N. which will be called B.A.T.M.A.N. Advanced. It works on Layer 2
and creates a virtual network switch of all nodes participating. It offers a
bunch of new possibilities and features which wait for you to be explored. To
offer you a stable plattform you can experiment with we will release 0.1
alpha. We will also provide a set of tools (the B.A.T.M.A.N. toolchain -
battool) to bring you in the position to observe the magic and to debug your
setup or our daemon. ;-)
see you june 20th,
the B.A.T.M.A.N. development team
I have setup a testbed to try out the batman routing protocol and
hopefully learn a little about it. I have installed it on 4 machines
and they all seem ok but when I try to run batman with:
#./batmand interface ath0
I simply get another command line #. Then when I try a:
I cannot see batman running as a process anywhere. Is there something
that I am missing?
My systems are all: Debian Sarge (kernel 2.6.8-3)
P3 800 with 256 Mb RAM
I am using the latest release of Batman:
B.A.T.M.A.N. III 0.2.0 rc2 (compability version 3)