Project

General

Profile

News

Open-Mesh: Google Summer of Code 2011 - status update

Added by Marek Lindner almost 13 years ago

As announced earlier this year the B.A.T.M.A.N. project participated in the GSoC 2011 amongst other organizations under the Freifunk umbrella. We were granted two slots which we filled with interesting project proposals. Both students have started working on their project a couple of weeks ago. We asked each of them to introduce themselves and speak about their project goals:

Hello everybody, I'm Antonio Quartulli from Brindisi, Italy (usually 
UTC+1). I am 24 years old and I'm currently attending the second year 
of the Master's Course in Computer Science at the University of Trento 
(Italy). I'm specializing in "Systems & Networks" (that's the name of 
my current specialization :-) ) and I should get awarded at the end of 
September.

I entered the Wifi Mesh Network world about one year ago when I 
started to study for the "Nomadic Communication" university course. 
Later I participated to the WirelessBattleMeshv3 in Bracciano (Rome - 
Italy) and there I had the possibility to meet various people which 
work on mesh networking and on several open-source routing protocols. 
Getting in touch with the community has been the first step which 
convinced me to deepen this field and B.A.T.M.A.N.-Adv was the
protocol which most attracted me. 

I've been around in the B.A.T.M.A.N.-Adv community for about one year 
and this gave me the possibility to understand the protocol and the 
details behind it (of course I still have to learn A LOT!!).

Several ideas have been presented in the last period which are meant
to bring improvements and new feature to the protocol. Most of those 
are only concepts and still need an implementation so I did a step 
forward and decided to apply for a student slot in the Freifunk 
organization.

This is my first GSoC experience and I am really happy to participate 
as student. My project concerns B.A.T.M.A.N.-Advanced, a mesh network
routing protocol, and the ARP request/response mechanism.

Basically, before starting the first IP communication, every host in 
the network needs to retrieve the destination Layer-2 address and this 
operation is executed by means of broadcast messages. It is easy to 
understand that in medium/large networks this could lead to high delay 
due to packet losses, so delaying the IP communication.

Here comes the idea of using a Distributed Hash Table to store Layer-2
addresses in the network: nodes will not need to use broadcast packets
anymore, instead they can use unicast packets to reach the node which 
is known to store the requested information in the DHT.

More details and up-to-date news are available on this page:
https://www.open-mesh.org/projects/batman-adv/wiki/DistributedArpTable

Stay tuned :-)

Hi folks,

I am Linus Luessing from Luebeck (ok, some 'L's too many, but not 
necessarily my fault ;) ), a city in Northern Germany at the Baltic 
Sea. I am 23 years old and currently a Bachelor's degree student in 
Computer Science - which actually did not involve any mesh networking
so far at all. However I've been fascinated of the Freifunk idea since 
I first heard of it.

Therefore I got in touch with B.A.T.M.A.N., especially the kernel 
module B.A.T.M.A.N. Advanced, about three years ago where we have 
been playing a little with this kind of new technology and 
implementations and trying to guess what kind of weird stuff this 
tricky wifi layer was doing. And it was also a very vibrant impression 
of being somehow involved in an Open Source Software Project for the 
first time. I was quite astonished about the direct, personal support 
and open way of sharing experiences and giving feedback.

During the last years I got more and more addicted to this and also 
tried to join several events, like the Chaos Communication Congress,
the Wireless Battle Mesh or the Chemnitzer Linuxtage. For a lot of 
new, conceptual ideas it was just more feasible to chat about it 
face-to-face. And there were a lot of ideas in this still kind of new, 
experimental field :).

It has been much fun so far and it is a great opportunity and an 
honour to be able to make some more of these ideas a reality during 
the Google Summer Of Code 2011 and to contribute to the Linux 
kernel, meshing, the community and Open Source Software in general.

During the GSoC 2011 I am working on some modularization of the core
routing protocol, splitting the OGM protocol as known of BATMAN IV
into an ELP (Echo Location Protocol, responsible for link, one hop 
tasks), OGM (will be responsible for the routing between nodes only, 
without the knowledge of separate links underneath) and a new MGO 
protocol (Message Guided towards Originator, a mechanism to be able
to recover from sudden path degradation quicker) in BATMAN V.

The protocol specs (work in progress!) can be found here:
https://www.open-mesh.org/projects/batman-adv/wiki/ELP
https://www.open-mesh.org/projects/batman-adv/wiki/OGM

Let's make the world a better place, bit by bit :).

Cheers, Linus

Happy routing,

The B.A.T.M.A.N. team

Open-Mesh: Batman-adv 2011.2.0 released

Added by Marek Lindner almost 13 years ago

The B.A.T.M.A.N. team is publishing its latest edition, 2011.2.0, primarily focusing on bug fixes and compatibility plus some smaller features. 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:

https://downloads.open-mesh.org/batman/releases/batman-adv-2011.2.0/

as well as prepackaged binaries in your distribution.

Important changes

A series of patches has been merged that replaces all occurrences of 'HNA' by 'TT' (standing for 'translation table'). Originally, batman-adv inherited the term 'HNA' from our layer 3 implementation which caused some confusion as people expected it to behave in the same way. The new name is meant to outline the difference. Scripts / tools expecting the string 'HNA' in the debugfs / batctl output need to be adjusted.
This renaming is the first step in a number of changes regarding the client announcement mechanisms. Expect more to come with the following releases.

Thanks

Thanks to all people sending in patches:

and to all those that supported us with good advice or rigorous testing:

batman-adv

In the aftermath of the orig hash lock removal released with 2011.1.0, batman-adv underwent a stabilization phase in which fixing bugs was the highest priority. Unsurprisingly, the transition to fine grained locking required further attention such as properly protecting data structures with rcu locks. During the debugging phase race conditions were fixed, duplicate code removed, memory leaks eliminated and reference counting imbalances addressed.
The backward compatibility with older kernel versions as well as the support of upcoming kernel releases has been thoroughly tested and improved. The local and global translation table output is reflecting the HNA to TT conversion. Adding support for multiple vlan ids to the bridge loop avoidance code is the only noticeable new feature coming with this release.

batctl

The batctl tool also has been affected by the renaming: the vis data option '--no-HNA|-H' has been renamed to '--no-TT|-T' and the vis data output prints 'label=TT' instead of 'label=HNA'. To be compliant with the JSON Schema the JSON vis data output has been slightly modified.

Happy routing,

The B.A.T.M.A.N. team

Open-Mesh: Batman-adv 2011.1.0 released

Added by Marek Lindner about 13 years ago

The B.A.T.M.A.N. team is publishing its second 2011 release - 2011.1.0, containing major code changes under the hood to improve performance and scalability plus the usual set of bug fixes. 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:

https://downloads.open-mesh.org/batman/releases/batman-adv-2011.1.0/

as well as prepackaged binaries in your distribution.

Thanks

Thanks to all people sending in patches:

and to all those that supported us with good advice or rigorous testing:

batman-adv

The principal objective while working towards this release was to remove the originator hash lock (also known as the batman-adv private "big kernel lock"). It was introduced in the very early stages of the batman-adv development which proved to be a simple and effective way to protect all originator node information from parallel access. As time went on, the module grew and gained more features - most of them making heavy use of the aforementioned originator hash lock as it safeguarded the module's central pool of data. It thereby became a major bottleneck because almost every piece of code had to acquire this very same lock. An extensive effort was necessary to replace the originator hash lock by fine grained locking which only locks the bare minimum of data to improve the module's performance and scalability.
Other parts of the code received attention too: After learning about bufferbloat in one of Jim Getty's talks we revisited our own buffering settings and decided to set the txqueuelen to zero. Fragmented packets are now properly linearized upon receipt to avoid a crash if the network card splits the packet into smaller chunks. The fragment numbering became more robust and several spelling mistakes have been corrected.

batctl

To render batctl more versatile packet dump functionality support for raw WiFi packet decapsulation was added. This allows to keep an eye on your network using interfaces in monitor mode which output packets including all WiFi headers. The bug causing to display an erroneously warning message when changing gateway settings has been squashed. Unused code and the last trace of our subversion integration in the Makefile have been removed.

Happy routing,

The B.A.T.M.A.N. team

Open-Mesh: Google Summer of Code 2011

Added by Linus Lüssing about 13 years ago

Since last Monday the student application period for the Google Summer of Code 2011 has opened. A chance for any student to get their hands dirty on their favorite OpenSource project and getting its development process and code base to know better during these 2 months - while getting payed for it! And guess what? This year, you can play with Batman - ehh, B.A.T.M.A.N. Anyways, they both want to save the world of course ;).

As the application of OpenMesh as a mentoring organization was sadly rejected last year, we decided and agreed on applying via Freifunk this year, which serves as an umbrella organization for various projects dealing with wireless mesh networks.

If you are interested in mesh networking and B.A.T.M.A.N. and if you also love OpenSource software and would like to become a more firm part of it, then get in touch with us via mailinglist and/or IRC. So far the following ideas have been collected which you may apply for:
https://wiki.freifunk.net/Ideas#B.A.T.M.A.N.
But feel free to tell us your own suggestions and ideas, too.

*****                                                 ****
*** Student application deadline is the 8th of April!! ***
****                                                 *****

Happy routing,

The B.A.T.M.A.N. team

Open-Mesh: Transition to git

Added by Marek Lindner about 13 years ago

With our ongoing integration into the Linux kernel community we started having a closer look at git and soon after decided to switch from SVN to git entirely. After having used SVN for quite a while the transition was a rather cumbersome task. We opted for a slow migration to not risk an interruption in our development process:

As a first step we launched https://git.open-mesh.org to serve as a starting point into the new git world. Each SVN commit was automatically synchronized into the corresponding git repository to allow the developers to familiarize themselves with the new tool without making it a hard requirement. At the same time all services depending on subversion were converted to use the git repository. This includes: IRC bots, man page generators, distribution packages, commit mailing lists, code style checks, sparse checks and, finally, trac. While we were not unhappy with trac at all, the performance of its git plugin proved to be fairly poor. Therefore we migrated to redmine - all tickets, wiki pages and links were converted in the process.

The switch to git is now complete with the trac system being the last SVN dependency to remove. In the foreseeable future the SVN repository will continue to exist to allow a smooth transition for all those still having old build environments. However, write access has been turned off as all changes from this point on go into the git repository only.

We went through all services & webpages to ensure everything is working as expected. Feel free to inform us if we managed to overlook something.

Happy routing,

The B.A.T.M.A.N. team

Open-Mesh: Batman-adv and the Penguin join forces

Added by Marek Lindner about 13 years ago

The Linux kernel 2.6.38 (released 2 days ago) is the first Linux version officially shipping the batman-adv kernel module. Although the code already entered Linux space in 2009 as part of the Linux staging tree (place for preparing kernel modules to be officially accepted). In late June 2010 Greg Kroah-Hartman, our tree maintainer, gave us his blessing to leave the Linux kernel staging tree and move to a more suitable location. It took several sessions of code review and changes with David Miller before he made us an early Christmas gift by merging the batman-adv module into the Linux kernel net tree. Since then an often asked question is: What did it take to make the kernel module "acceptable" by the Linux kernel hackers and which parts of the code did you have to change in the process?

Of course, being Linux kernel coding style compliant and the code refactoring that comes with it definitely was one of the larger chunks on the way into the Linux kernel land. There always has been a lot of discussion about whether or not the Linux kernel coding style rules are (partially) old fashioned, too strict or a burden but consider this: Even hundreds of contributors for each release manage to work on the same code base to produce a coherent piece of code that is relatively easy to navigate, once you understood the coding style, taking into account its enormous size. To achieve the "Linux kernel natural" feeling we also had to adjust the administrative handling of the project, like making small and digestible patches which have to go through our mailing list while enforcing the Linux kernel patch submit "regime". At some point every patch will be forwarded to our tree maintainer who may reject the patch if it did not meet the style requirements. Having the same requirements in place helps avoiding rejected patches. Our release process underwent major changes too: The different branches now contain patches for the current stable release / the upcoming Linux kernel respectively. The 3 months release cycles & feature freezes have become a regular event, the heartbeat of the project.

The technical aspect required much attention too: Each citizen of the wide Linux kernel land is expected to re-use existing infrastructure and to avoid code duplication at all costs. This includes employing kernel constants instead of hard-coded numbers or own definitions (e.g. ETH_ALEN, NET_RX_SUCCESS, NETDEV_TX_OK, ..), kernel provided functions instead of manually written counterparts (e.g. hweight_long(), compare_mcast_addr(), min() macro, msecs_to_jiffies(), ..) or even integrating whole "libraries" like the list implementation, reference counting or rcu locking. Next to the obvious advantage of reducing the binary size it bears the appealing characteristic that this code is better debugged and optimized as it is shared among a large group of developers and users. Absolutely forbidden are Linux kernel version checks in the code base, something that was found everywhere in our code to cope with API changes because we wanted our module to also be compatible with older Linux kernel versions. The solution was to concentrate all incompatibility workarounds in a single file (compat.h) which is only part of the external release tarballs. Another no-go was the in-kernel support for specific output formats our mesh graph visualization offered. This formatting can easily be handled in user space. As a result the batman-adv kernel module now outputs a single neutral format. The batctl user space tool showcases how to convert this output into other formats. The initial and somewhat simple procfs configuration and debug interface had to be migrated to sysfs (the settings) and all debugging related functionality moved to debugfs. Since we reside in the official Linux kernel source tree our code has been analyzed by static analyzers (Coccinelle/sparse), we received patches for API changes on multiple occasions and insightful code review feedback.

We are very excited about the results. This was quite an experience which helped to improve the overall code quality while helping us to understand the Linux kernel better. However, this is just the beginning. Many more patches and features are already in preparation and will shape future releases.

Happy routing,

The B.A.T.M.A.N. team

Open-Mesh: Batman-adv 2011.0.0 released

Added by Marek Lindner about 13 years ago

The B.A.T.M.A.N. team is excited to announce its latest release, 2011.0.0, mainly fulfilling popular feature requests but also delivering bug fixes and performance enhancements as well as modifications under the hood. 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:

https://downloads.open-mesh.org/batman/releases/batman-adv-2011.0.0/

as well as prepackaged binaries in your distribution.

Important changes

The "gateway support" coming with this release manipulates the DHCP request / reply behavior once activated. It is strongly suggested that you read our documentation before you make use of this feature to avoid surprises.

Thanks

Thanks to all people sending in patches:

and to all those that supported us with good advice or rigorous testing:

batman-adv

This release brings the long awaited internet gateway support: Batman-adv nodes in a network can be declared 'gateways' with a certain bandwidth at their disposal. All clients learn about these gateways and can choose their preferred gateway based on link qualities / bandwidth. The decision is 'propagated' to the higher layers by manipulating the DHCP requests. Furthermore, batman-adv implements a bridge loop detection & avoidance that aim to allow multiple batman-adv nodes connected to the same LAN segment without provoking a loop.
The initial layer2 fragmentation implementation that was included in the last releases was further enhanced. Batman-adv nodes forwarding other nodes' traffic inspect the to be transfered packets to automatically fragment the packet if the MTU of the outgoing interface does not allow a normal forward. Fragmented packets are reassembled whenever possible to keep the overhead as low as possible. Also new is the possibility to configure the hop penalty at runtime (via sysfs).

The internally used hash implementation has been reimplemented after David Miller pointed out major deficiencies. These changes gave the batman-adv module a 10% speedup when forwarding payload traffic as these operations heavily make use of the hash code. The Linux kernel bit operation functions replaced the custom functions in batman-adv which are better debugged. The cleanup of the sysfs code greatly reduced the code size and makes this code more manageable.

batctl

The support for the new gateway sysfs API was among the biggest changes for this release. It allows to easily turn the gateway mode on/off and displays all known gateways including their announced bandwidth. To monitor the bridge loop avoidance batctl offers a new parameter to display the the bridge neighbor table while highlighting the 'gateway to LAN'. The bisect component now can deal with the 32Bit sequence numbers in the OGMs and the bat-hosts parser became more robust while replacing MAC addresses with bat-host names.

Happy routing,

The B.A.T.M.A.N. team

Open-Mesh: WirelessBattleMeshv4 Announcement

Added by Marek Lindner about 13 years ago

The announcement for the WirelessBattleMeshv4 just came over the list and stirred up quite an excitement. This annual gathering has evolved into a "can't miss that event" over the past 2 years. Again, wireless communities from all across Europe are expected to get on the their way to Barcelona / Spain. The people from guifi.net, who created one of the largest wireless networks in Europe (more than 4000 nodes), are this year's host and have organized the event. We, the people behind the B.A.T.M.A.N. project, will definitely not miss the opportunity to enjoy a full week with wireless hackers to discuss & develop on the latest hot new stuff. Details about the event's registration / locations / costs can be found in the announcement text below.


==========================================================
     Announcing the Wireless Battle Mesh v4
   (16-20 March 2011, Sant Bartomeu del Grau, Spain)
==========================================================

The next 'Wireless Battle of the Mesh' will take place 
from Wed 16th till Sun 20th of March in Sant Bartomeu del 
Grau (80km far from Barcelona), Spain. The event aims to
bring together people from across Europe to test the
performance of different routing protocols for ad-hoc
networks, like Babel, B.A.T.M.A.N., BMX, and OLSR.

If you are a mesh networking enthusiast, community
networking activist, or have an interest in mesh networks
you have to check this out!

Informations about the event are gathered at:
http://battlemesh.org/BattleMeshV4

Location
========

The event will take place in the Can Roca turistic resort
in Sant Bartomeu del Grau, Catalunya, in the pre-Pyrenees
Lluçanès area, 80 km far from Barcelona.

Registration
============

Registrations will be available at different hackerspaces
(Fusolab, HSBXL, /tmp/lab, metalab, CCC, ...) and on the
official website for the event at
http://battlemesh.org/BattleMeshV4

Fees
====

Every participant needs to donate 50 EUR (this should 
cover the costs for accommodation and infrastructure). 
To finance this event, we ask you to pay when subscribing
(bank transfer or cash).

Contact
=======

* Web: http://battlemesh.org/BattleMeshV4
* Email: wbmv4_aatt_exo_dot_cat
* IRC: irc.freenode.net #battlemesh

Happy routing,

The B.A.T.M.A.N. team

Open-Mesh: B.A.T.M.A.N. V status update

Added by Marek Lindner over 13 years ago

In November 2009, when batman developers and wireless enthusiasts came together in Brussels (WBMv2) the first concepts ideas on how to improve the BATMAN IV routing algorithm emerged and after a couple of days of healthy discussion a first draft came to light. One year later, it is time to ask: What has been accomplished since then ? What is working right now ? Where are we going from here ?

This overview tries to present the state of development regarding the various B.A.T.M.A.N. V ideas/concepts. Some are already part of a release, others are in the design / implementation phase and a couple more are in the state of "vague idea". Feel free to join any topic and discuss with us to get your idea heard as well!

Mesh bonding mode

Status: implemented/stable

The bonding mode was one of the first B.A.T.M.A.N. V features to be implemented. It was tested during the WBMv3 in Italy and found its way into the 201010 release.

However, our tests have shown that bonding mode achieves maximum throughput over single hops only. For multi-hop paths interface alternating (see the next section) provides better performance results.

Incoming interface based routing / Interface alternating

Status: implemented/stable

Our original concept of how the incoming interface based routing (later called "interface alternating") should work turned out to be susceptible to routing loops, therefore the ideas had to be revised. While implementing the bonding mode it became apparent that these 2 features share the same base problem: Finding a neighbor which also has several interfaces that a node can communicate with simultaneously. As a result the same functionality was achieved by simply devising the interface alternating as a variation of bonding. Consequently, bonding mode and interface alternating were released together. Check our documentation section if you are interested to find out how to use these features and how they work internally.

Neighborhood Discovery Protocol

Status: implemented/experimental

B.A.T.M.A.N. IV uses a single message type (Originator Message - OGM) to solve two problems: Measuring the link quality to direct (single hop) neighbors and propagating the path qualities through the mesh. Albeit being simple, this approach leaves room for optimizations, especially in dense and/or mobile networks (see "overhead reduction" in the outlook). B.A.T.M.A.N. V introduces NDP, in addition to the OGMs. NDP takes care of the link quality measurements while OGMs take care of propagating the path qualities. This has the following advantages:
  • Modularization of the code
  • The delta changes between two OGMs can be increased with an NDP interval faster than the OGM interval, resulting in a higher influence of a single OGM.
  • Seperate optimization strategies can be used for NDP and OGMs individually then.
  • The more sparse the network is (number of single hop neighbors significantly smaller than the number of all nodes), the faster the NDP interval can be chosen relative to the OGM interval, resulting in major convergence speed improvements in sparse networks.
  • As NDP messages are never rebroadcasted it also helps to reduce the overhead in dense networks (many single hop neighbors).
  • (Mobile nodes can chose a faster OGM + NDP interval then. It directly improves their transmit path - which was not the case with the OGM LQ measurements due to the echo-quality dependency,
    and indirectly improves their receive path a little, due to the asymmetric penalty)

The first set of patches has been posted but the work is not complete yet. We hope to have it ready for the WBMv4.

Weighted LQ measurements

Status: design phase

Currently, B.A.T.M.A.N. IV is using a normal window for counting received packets and calculating the link quality from this information. However, these link quality measurements turned out to be the major convergence speed issue (with the default values, batman-adv needs 64 seconds to get from 0 to 100% link quality). The idea is, to give newer packets more importance in the counting and measuring process, either via a weighted window or an exponential weighted average.
  • Improves convergence speed due to more responsive link quality measurements in mobile scenarios.
  • NDP with faster intervals + weighted LQ measurements complement each other nicely for faster LQ measurements.

Dead node fast path switching/invalidating

Status: vague idea

When a node notices the breakdown of a neighbor (see routing scenarios to get an idea about the conditions), this node could send any data packet, which it would usually send over this neighbor to either its second best hop if available (which does not always have to be the case due to OGM forwarding policies). Or it could send the packet back to the next hop towards the source again. With the help of sequence numbers, any node on the 'backtracking' path (the backtracking path can be different from the usual path in case of asymmetric links) could notice that a path became invalid very quickly.
  • Quick response in case of node/link failures
  • Avoiding packet drops in case of rapid link failures

Host Network Announcements (HNA) and Roaming

Status: "(partly) implemented/experimental"

So far, every host's mac address in the mesh network (either of bridged-in hosts or the batman-adv node itself on bat0) are being announced proactively, periodically: Those mac addresses are just
attached to every OGM. A (semi-)reactive approach shall be introduced, as the HNA information usually do not change that frequently. It further has the following advantages:
  • Minimizing size of OGMs, reducing overhead
    -> Reduces overhead a lot in case of whole wired networks being bridged into the mesh network
  • Allowing many, many, many more hosts being bridged into the network without affecting the routing protocols performance in a negative way.
  • Fast HNA handover: Instead of having to wait for a new OGM and its HNA entries to notice the roaming of a host, a reactive technique shall minimize this time frame needed for the roaming.
  • Any layer 2 implementation (such as batman-adv) would be able to use this new mechanism to reduce the hand-over time to nearly zero as packets can be safely redirected from the old node in charge of the host to the new one (usually the new node in charge will notice the roaming earlier than the sender of data, as the new node is usually physically closer to the old node) until the mesh is in sync again.

This task is work-in-progress - a first draft describing full mechanism has been posted.
-A second draft describing full mechanism has been posted

Multicast optimizations

Status: implemented/experimental

B.A.T.M.A.N. IV has no explicit multicast support, therefore batman-adv does not treat multicast packets any different than broadcast packets: They just get flooded through the mesh. To make services like audio/video transfer feasible, the retransmissions should be reduced. 2 different approaches have been proposed around the same time:
  • The first scheme offers the possibility to 'flood' multicast packets on the according unicast paths only for nodes which are both sender and receiver of the same group.
  • The second multicast optimization approach is non-group-specific and works for both multicast and broadcast packets.

Both approaches share similar concepts but are not identical. These two groups exchanged many ideas and probably merge the best of both approaches in the weeks to come.

Thanks again for the tremendous input and sharing of experiences, ideas and code! Seeing all these ideas coming together is what makes this project worthwhile!

Happy routing,

The B.A.T.M.A.N. team

Open-Mesh: Batman-adv 2010.2.0 released

Added by Marek Lindner over 13 years ago

The B.A.T.M.A.N. team proudly presents the last batman-adv release in the year 2010, carrying the version number 2010.2.0. This release contains a mix of new features, Linux kernel compliance and bug fixes. 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:

https://downloads.open-mesh.org/batman/releases/batman-adv-2010.2.0/

as well as prepackaged binaries in your distribution.

Important changes

The batman-adv module now supports multiple mesh clouds simultaneously which made changes to the 'bat0' interface behavior necessary: Mesh interfaces (such as bat0) are created only after 'real' interfaces (e.g. wlan0) have been assigned. Mesh interfaces that have no real interfaces assigned are removed from the system. Furthermore the mesh interface can be freely named such as bat5, mesh0, etc, therefore batman-adv might be active even though bat0 does not exist. More details can be found below as well as in our documentation.

Thanks

Thanks to all people sending in patches:

and to all those that supported us with good advice or rigorous testing:

batman-adv

The work that nearly a year ago began has finally come to an end: Multiple mesh cloud support has been completed. This allows one host to participate in multiple meshes at the same time via different interfaces. This often requested feature is particularly useful to segment large batman-adv installations, thereby reducing overhead. Each mesh cloud can be individually configured, deals with its traffic flow independently and possesses its own batX interface. Also added was a layer 2 fragmentation for unicast data flowing through the mesh which will allow to run batman-adv over interfaces / connections that don't allow to increase the MTU beyond the standard Ethernet packet size of 1500 bytes. This initial fragmentation only supports splitting the large packets at "the beginning of mesh" whereas an extension which allows fragmenting "on the fly" anywhere in the mesh network will be included in the following release.

As usual, many improvements happened under the hood: The module uses the kernel supplied functions for network buffer manipulations instead of re-implementing them and takes advantage of the optimized kernel functionality for OGM counting. The RCU protected lists have been revamped and enhanced with referenced based counting which squashes quite some race conditions. The HNA handling needed some fixes too when it was stress tested with a very large local network. Many minor bugs such as false warnings, reduced memory usage and coding style issues were addressed.

batctl

To support the "multiple mesh clouds" feature batctl received a new (optional) parameter '-m' to specify the mesh cloud interface in order to query the mesh cloud of interest. If '-m' is not specified batctl will assume 'bat0' as mesh cloud interface which maintains backward compatibility and suits most users. The newly added fragmentation on/off switch also was added as well as batctl tcpdump support for fragmented packets. In addition, the batctl tcpdump can deal with multiple header encapsulation (e.g. HTTP in VLAN in BAT UNICAST in VLAN) and the batctl ping utilities' '-i' option is not silently ignored any longer. Various cleanups took place and a crash fixed if the HOME environment variable is not set.

Happy routing,

The B.A.T.M.A.N. team

(91-100/116)

Also available in: Atom