The B.A.T.M.A.N. team is delighted to announce its latest release, 2011.3.0,
introducing major protocol changes for better roaming of non-mesh clients,
gateway convenience features and a pile of bug fixes & code stability changes.
As the kernel module always depends on the Linux kernel it was compiled
against, it does not make sense to provide binaries on our website. As usual,
you will find the signed tarballs in our download section:
as well as prepackaged binaries in your distribution.
The extensive work on roaming improvements for non-mesh clients led to a
protocol change which breaks backward compatibility. Be sure to update all
your mesh network participants to the latest version to avoid orphan nodes.
Furthermore, a change in the networking infrastructure of the Linux kernel
made us drop the support of Linux kernels older than 2.6.29. Maintaining
compatibility would be an uphill battle while not being worthwhile for us as a
Linux kernel project.
Thanks to all people sending in patches:
* Antonio Quartulli <ordex(a)autistici.org>
* Daniele Furlan <daniele.furlan(a)gmail.com>
* David Howells <dhowells(a)redhat.com>
* David S. Miller <davem(a)davemloft.net>
* Joe Perches <joe(a)perches.com>
* Jonathan Neuschäfer <j.neuschaefer(a)gmx.net>
* Marek Lindner <lindner_marek(a)yahoo.de>
* Sven Eckelmann <sven(a)narfation.org>
This release comes with a redesign of one of the oldest code segments /
concepts in batman-adv: the non-mesh client announcement mechanism. When
batman-adv detects a non-mesh client it automatically starts announcing the
client's mac address in the mesh network to make the mesh aware of the
client's location. The new protocol extension mainly deals with the optimal
handling and propagation of these client position packets. Major benefits
include: Only changes (client arriving or leaving) are propagated in the mesh,
thereby reducing the protocol overhead; traffic redirection when a client
roams from one mesh node to the next until the mesh network has converged to
reduce the packet loss while roaming; extensible packet format to construct
more features on top of it.
In addition, batman-adv gained support for informing the user space about
events via uevent (a long-standing feature request). The gateway subsystem is
the first to make use of it by sending signals when a new gateway has been
selected / selected gateway has been changed / the selected gateway has been
removed. Also, when enabled the gateway subsystem will filter out incoming
DHCP renewal requests if they are not targeted at a high quality gateway to
force the client to switch to the best available gateway.
The routing algorithm received a minor tweaking which make it accept delayed
OGM rebroadcasts to avoid bogus routing under heavy load. A bug hindering the
correct broadcast of OGM packets if interfaces were added & removed in a
particular order was fixed. A similar problem affecting the OGM aggregation
was eliminated too. The many smaller bug fixes and code stability improvements
make this release a well-rounded package.
The Makefile received major attention and various cleanups to make packaging
of batctl easier. tcpdump was updated, so that it can analyze the new tt &
roaming packets and was extended by a new option to filter all packets except
the specified types. An additional debug level for all client announcement
related information was added too. A pair of small bugs was squashed along the
way: bisect did not properly initialize a variable which led to a compile time
warning and a potential memory leak in the bat-hosts parser fixed.
The B.A.T.M.A.N. team
I don't understand why when an node gateway switch its channel to
another however it is visible in the by batctl gwl or batctl o command
but with very low link quality and obviously the node is
This is normal?
as some of you already know we are actively working towards the new routing
algorithm. Since it is our fifth incarnation we named it "B.A.T.M.A.N. V". The
major improvements focus on areas like mobility support, less overhead and
faster network convergence. We still are in the early stages of developing the
code and finalizing the concept. Interested parties / early birds may contact
us to get involved. All others should wait until we issue the call for public
testing & feedback.
In order to ensure a smooth transition and efficient testing later, we decided
to offer a choice of routing algorithm at compile time. Those who wish to test
the new code (once available) can choose it whereas the others can stick with
the mature routing code base while enjoying new features / bug fixes outside
of the routing algorithm.
As a first step into that direction I worked on a set of patches to assemble
all B.A.T.M.A.N. IV related routing code in a single file, accessible via a
routing algo API which will also be used by the new code.
Note: Although we have a new file (bat_iv_ogm.c) I kept the previous copyright
information because all I did was shuffling the code around. During the
process I renamed a few functions here and there but no code was changed.
I have two devices, both of them have eth0, wlan0. I followed the
BATMAN quick start guide
The bat0, eth0, wlan0 on both devices were set to 0.0.0.0 and the
mesh-bridge on dev1 was set to 192.168.10.1 and on dev2 was set to
192.168.10.2. Both devices can ping to each other.
When I execute "batctl gwl", I was getting "No gateways in range ...".
My question is, do you have a sample step-by-step procedures to bring
up the batman correctly?.
Gateway mode is something different (read about it in the wiki) -- what you want to look at with batctl is "originators" which show you surrounding nodes with link quality. If you want to do routing you'll have to do something different; batman-adv as you set it up is like plugging your computers into the same switch.
John Tobias <john.tobias.ph(a)gmail.com> wrote:
>I have two devices, both of them have eth0, wlan0. I followed the
>BATMAN quick start guide
>The bat0, eth0, wlan0 on both devices were set to 0.0.0.0 and the
>mesh-bridge on dev1 was set to 192.168.10.1 and on dev2 was set to
>192.168.10.2. Both devices can ping to each other.
>When I execute "batctl gwl", I was getting "No gateways in range ...".
>My question is, do you have a sample step-by-step procedures to bring
>up the batman correctly?.
So, I had a crazy idea the other day:
Normally, when I talk to people about mesh networks, they assume that
there is some central authority assigning IP addresses to nodes
I was thinking, though, that I'd rather have it so that every node could
have the same firmware, and you'd just throw the node up and it'd
negotiate everything for itself, including its IP address.
So I was thinking: What if each node in the network was using
batman-adv, and ran a DHCP client and a DHCP server?
It'd try to get an address thru DHCP. If it failed, it'd choose an
address at random from the network range. Then, any time someone threw up
a new node in range, the new node would try to get an address, and it
would succeed in getting an address from the first node.
Multiple DHCP servers can serve the same, overlapping IP ranges. However,
this depends on the DHCPOFFER and DHCPREQUEST being broadcast to the
network. This is how we avoid having the same IP address assigned to
multiple nodes -- DHCP servers overhear what was assigned to whom by other
DHCP servers, and make a note to themselves not to assign that address
So it seems that a "distributed" DHCP system could work.
The problem is, doesn't Batman-adv munge the DHCP that flows though it,
for its gateway logic? So that the DHCPREQUESTs are unicast? That's
great for gateway logic. But I also want nodes to have IP addresses for
I was thinking of running it like this: Each node has two virtual
interfaces - the mesh interface, running in adhoc mode. Routers use this
interface, and this is where the distributed DHCP runs.
Another wifi interface runs in host mode. This is what laptops and so
forth will connect to.
Once a router gets an ip address from this distributed DHCP nonsense, then
it determines a longer network prefix for its clients on the host-mode
interface. It sets up its HNAs and starts serving DHCP with this longer
prefix to its clients. The machines on the inside run webservers and so
forth that should be available to the inside of the mesh.
Now, what if the network is fractured and the same IP address gets
assigned to a router (and thus is used as a prefix for that router's
clients) on each side of the split? When the segments join up, we'll have
multiple nodes with the same IP address and this will cause problems.
Yes. The lease times will be very short, so this type of problem should
resolve itself quickly.
But, what do I do about how the gateway business interferes with DHCP?
Could I somehow have two DHCP servers serving the same interface? One
that serves out IP addresses and one that deals only with gateways?
Is this idea just too crazy? Why?
Spam detection software, running on the system "dedicated37.virtbiz.com", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: So, I had a crazy idea the other day: Normally, when I talk
to people about mesh networks, they assume that there is some central authority
assigning IP addresses to nodes intelligently. I was thinking, though, that
I'd rather have it so that every node could have the same firmware, and you'd
just throw the node up and it'd negotiate everything for itself, including
its IP address. [...]
Content analysis details: (10.3 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.5 HELO_LH_HOME HELO_LH_HOME
3.1 AXB_HELO_HOME_UN HELO from home - untrusted
-1.5 BAYES_00 BODY: Bayes spam probability is 0 to 1%
1.2 RDNS_NONE Delivered to internal network by a host with no rDNS
4.3 TO_NO_BRKTS_DIRECT To: misformatted and direct-to-MX
2.6 TO_NO_BRKTS_NOTLIST To: misformatted and not a mailing list
Thank you for your answers. I understood clearly how the system should
work, but i´m not using the git repository but the 2011.1.0 version.
I'll try with the repo to see what happens.
> Message: 2
> Date: Fri, 12 Aug 2011 18:02:20 +0200
> From: Antonio Quartulli<ordex(a)autistici.org>
> To: The list for a Better Approach To Mobile Ad-hoc Networking
> Subject: Re: [B.A.T.M.A.N.] Multiple DHCP Gateways
> Content-Type: text/plain; charset=utf-8
> Hello and thank you for sharing your gw experience with us,
> On Wed, Aug 10, 2011 at 02:52:06PM -0300, gtolon(a)inti.gob.ar wrote:
>> However, when the original gateway becomes
>> worse than the alternative, and the client chooses the new one as
>> preferred (observed with batctl gwl) i noticed that the subsequent
>> request DHCP messages are sent to the original server, even if it
>> doesn?t have the best link.
>> I guess that?s because these subsequent DHCP requests are made as
>> Unicast to the original server and so Batman doesn?t redirect them,
> Unicast renewal requests are "dropped" only if the TQ towards the destination is
> smaller than the "current_GW_TQ - GW_THRESHOLD" (GW_THRESHOLD = 50).
> To clarify:
> In your topology you have three nodes: A, B and C. A and C are GWs. A is the
> current best GW for B and B got an IP from the DHCP server running on A. Then
> the link A<--> B becomes worse than B<--> C. At this point Batman-adv will
> drop a DHCP unicast renewal request directed to A
> if and only if TQ(C) - TQ(A)> 50
> Is this condition verified in your topology when your are observing the renewal
> DHCP packets?
> I hope I've been clear. :-)
>> i wonder how this behavior affects the network balance, because the
>> computers would get tied always to the original DHCP and IP default
>> gateway even if they moved, right?
> As above. Clients will keep the same GW as long as the link is still "usable"
> (difference on TQs greater than 50)
>> Thank you very much
> Thank you too,
> Message: 3
> Date: Fri, 12 Aug 2011 19:22:28 +0200
> From: Marek Lindner<lindner_marek(a)yahoo.de>
> To: "The list for a Better Approach To Mobile Ad-hoc Networking"
> Subject: Re: [B.A.T.M.A.N.] Multiple DHCP Gateways
> Content-Type: Text/Plain; charset="utf-8"
> On Friday, August 12, 2011 18:02:20 Antonio Quartulli wrote:
>> In your topology you have three nodes: A, B and C. A and C are GWs. A is
>> the current best GW for B and B got an IP from the DHCP server running on
>> A. Then the link A<--> B becomes worse than B<--> C. At this point
>> Batman-adv will drop a DHCP unicast renewal request directed to A
>> if and only if TQ(C) - TQ(A)> 50
> Be aware that only happens if you use the git repository. The "DHCP request
> drop" feature was not released yet.
> What version are you using ?
> B.A.T.M.A.N mailing list
> End of B.A.T.M.A.N Digest, Vol 56, Issue 15
I am checking the efficiency of my batman-adv network in terms of CPU
usage. My system consists of batman-adv 2011.1.0 enabled 3 laptops.
There is no direct contact between A and C. So, node B is the relaying
node. The systems cpu configuration in all nodes are:
In A : cpu MHz = 2000
In B : cpu MHz = 1000
In C : cpu MHz = 800
When I checked the CPU usage at different nodes (using netperf), I
found the following results.
TCP CPU utilization send local from C to B = 5.84%
TCP CPU utilzation send local from B to A = 2.37%
TCP CPU utilization from C to A (2-hop environment) = 9.19%
UDP CPU utilization send local from C to B = 0.75%
UDP CPU utilization send local from B to A = 3.85%
UDP CPU utilization send local from C to A (2-hop environment) = 4.31%
My questions are why is the CPU utilization so less for UDP case? In
case of TCP cpu utilization, isn't 9.19% a very high value for a
system consisting of just 3 nodes?
Since, B is acting as a relaying node to relay the network from C to
A, what is its impact on total CPU usage?