Project

General

Profile

News

WirelessBattleMesh in Bracciano

Added by Marek Lindner over 9 years ago

After the 2 successful WirelessBattleMesh gatherings in 2009, the interest in CommunityWireless events with focus on meshing and idea exchange was growing and resulted in the 3rd WirelessBattleMesh. Due to lack of time and space to deploy a decent test network during previous events, we decided to get together at the camping site in Bracciano / Italy. The owner was a big fan of the FOSS movement that allowed us to deploy the nodes wherever we wanted and helped us in many occasions. The guys from Ninux made sure we had all the things we needed (for example a broadband symmetric wireless internet uplink across the lake) and managed to make this event a great success. Thank you guys!

We managed to flash, configure and deploy roughly 40 nodes (in a rather random manner) across the camping site. All nodes ran 5! routing protocols simultaneously, thus creating quite a "wifi warzone". The good news is: All protocols ran without major problems - we had no crashes, memory problems, etc. Some people were measuring protocol traffic, cpu overhead and so on which were published towards the end of the event. This is a major step forward, since the previous events never managed to get a big test bed running to perform these kind of tests. Unfortunately, this test bed was rather chaotic and delivered unreproducible test results. If the same test was performed twice with a 5 minute pause in between the results were totally different. We hope that future events will focus on a more predictable environment.

Map of the camping site with node positions (photo by hispanic)

For us batman developers it definitely was a worthwhile event. Apart from meeting a lot of interesting people from other projects we also met some of the Italians who wrote papers about the B.A.T.M.A.N. protocol. As we noticed recently our protocol became quite popular in Italy (go to google scholar and see for yourself), so we used the chance to see some of the faces and chat about future improvements & collaboration. Some cool things might show up over the next couple of months. Furthermore, we had the time to discuss our release cycle. The result of this discussion can be read here.

Next to the "regular" testing we organized some specialized batman tests on our multi-radio wifi hardware. Since a while a new feature called "alternating/bonding" is in preparation which needed some more testing before it could be finalized. The idea of this feature sounds simple: Using multiple (wifi) interfaces to avoid the bandwidth killing store & forward mechanism which one usually encounters when forwarding traffic over multiple hops on the same channel. First, batman would have to detect that the other end has several interfaces connected to the mesh. Then this could be used to send data to one interface and forward it via another one (which we call alternating) or use both interfaces to send & forward at the same time (which we call bonding). If you are interested how the protocol detects it, please see this document.

This graph shows a 3 node setup each with 2 802.11abg wifi interfaces connected to the mesh network (1x 2.4GHz and 1x 5.8GHz). As you can see the alternating mode is able to maintain the performance. The old default behavior sometimes manages to maintain a similar level of performance but is rather unstable.

As the alternating mode proved to be so effective, it will be activated by default (if multiple wifi interfaces are available). This feature will be part of the September release but if you want to test it now, check out the trunk and let us know about your results!

We are looking forward to the Wireless Battle Mesh v4,

the B.A.T.M.A.N. team

Scheduled server downtime

Added by Marek Lindner almost 10 years ago

Our service provider (Hetzner) will move this server to a new location. It will be necessary to shutdown all offered services for a couple of hours until the server hardware has moved to its new home. Since the entire server infrastructure is going to move no URLs / DNS records / etc will need to change. The downtime is scheduled for:

May 11th 10.30pm till May 12th 7.30am (CET)

We hope this will be a smooth ride but as you know, things might get delayed because of unforeseen events. Don't grow impatient if it takes a couple of hours longer. Keep in mind that this will affect the repos (svn & git), the mailing lists (batman & batman-commit) and its archives, the wiki as well as downloads. Please, make all necessary preparations to get over this period without hassle.

There will be another reminder on the batman mailing list once the event comes closer. If you have questions or concerns feel free to contact us.

[Update: 12/05/2010]
Our server successfully came up after being moved to the new location and all services came back online.
[/Update]

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

Batman-adv 0.2.1 released

Added by Marek Lindner almost 10 years ago

The B.A.T.M.A.N. team hereby announces the release of the first bugfix milestone for the batman-adv 0.2 branch which focuses on stability but also brings improvements and small 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:

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

as well as prepackaged binaries in your distribution.

Important changes

The batman-adv logging facilities underwent structural changes to fully integrate into the standard Linux logging mechanisms. Please study the README to get further details on how to access the debug logs. In addition, the "vis" /proc file has been split up into two files: vis_server and vis_data. The vis_server controls the vis server status whereas the vis_data file exports the visualization "raw"
data which can be easily parsed by user space tools. Again, details can be found in our documentation.

Thanks

Special thanks go to:

  • Andrew Lunn for going through the entire code base to refactor the code and adjust the coding style to match standard Linux coding style guidelines
  • Linus Luessing for his restless testing in so many scenarios and sending a lot of patches and suggestions.
Thanks to all people sending in patches:

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

batman-adv

Albeit being a bugfix release we dared to include some bigger changes because we felt their gain outweighs the risk. For instance, we replaced the packet handling thread which was responsible for routing the payload data through the mesh by an advanced skbuff handling technique. Now, packets are received directly by registering the Ethernet type and handling skbs instead of
self-allocated buffers which boosts the performance considerably and reduces latency.

On the other hand batman-adv is moving towards full Linux kernel integration which requires some significant changes under the hood as well as on the surface. Batman's own logging facility has been removed (the standard Linux logging is used instead). The vis output comes now in a neutral format, easily parsable by user space applications. Since the module entered the official Linux realm several
people threw static code analyzers (e.g. Coccinelle, sparse) onto the code to find bugs. Some (possible) memory leaks, optimizations and a false alarms have been found and dealt with. Many more bugs, race conditions and crashes have been fixed. Now, it also is possible to change the MAC address on bat0.

batctl

Since the vis output format has changed, batctl received a parser for the neutral format to convert the output into either dot draw or JSON. If you wish to write your own parser, please see our documentation and/or the batctl code as an example. The batman-adv debug log will show up in the standard kernel logs of your system, hence to access the logs "batctl log" is not needed any longer. Please use the tools provided by your distribution (dmesg/logread/syslog/etc). However, "batctl log" remains available and can be used to filter existing logfiles for batman-adv output
and to replace the mac addresses by bat-host names.

Happy routing,

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

B.A.T.M.A.N. at the WirelessBattleMeshv3

Added by Marek Lindner about 10 years ago

It has just been made official - we will have a WirelessBattleMeshv3 in Italy (mainly organized by the guys from Ninux/Italy). After participating in the first WirelessBattleMesh in Paris as well as the second WBM in Brussels we definitely won't miss the next one. Due to the success of the past events, Wireless Communities across Europe have shown interest in a larger gathering in Italy (50-100 people are expected). To coordinate the various efforts an official "Wireless Battle of the Mesh" website has been created: http://battlemesh.org/

Most of the B.A.T.M.A.N. developers already confirmed that they are going to be there. Despite what the title might imply it is a very peaceful event which has a lot of room for talks & discussions, coding & debugging or just having fun. So, if you want to meet / chat / hack the code with us - come to Italy! Details about the event's registration / locations / costs can be found in the announcement text below.

Announcing the Wireless Battle of the Mesh v3

(02-06 June 2010, Bracciano, Italy)

The next 'Wireless Battle of the Mesh' will take place from Wed 2nd till Sun 6th of June in Bracciano (near Rome), Italy. 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., and OLSR. This third WBM will be improving the testbed conditions for mesh protocols with standardized testing procedures that will be reported after the event for the wireless communities.

On the development side, a flashing tool will be presented to simplify the deployment of such wireless networks based on OpenWrt stable release and packages for each protocol.

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/

Location

The event will take place in the camping Porticciolo in Bracciano, Italy. along the border of the lake of Bracciano, just North-West of Rome.

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

Fees

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

Contact

Web: http://battlemesh.org/BattleMeshV3

Email:

IRC: irc.freenode.net #battlemesh

Retrospect - B.A.T.M.A.N. in 2009

Added by Marek Lindner about 10 years ago

Now that the end of the year is close, it is time to lean back for a moment and review the events & achievements happening throughout the past year.

We published 2 bugfix releases of our batmand [layer 3] branch (batmand 0.3.1 and "batmand 0.3.2::/news/5) as well as a major milestone of our batman-adv [layer 2] kernel module (batman-adv 0.2). Deprecated branches (batman-advanced userland version and vis-advanced) were removed from the repository because their functionality was replaced by the kernel module. The newly created tool 'batctl' (former battools) matured enough to be added to the standard release.

The trac based webinterface celebrated its first birthday a few days ago. Especially in the first months of 2009 we spent quite some time to ease the transition and improve the setup to serve better the growing needs of the project. During the late summer git.open-mesh.org was born which plays a crucial role in our efforts to merge the batman-adv kernel code into the linux kernel. The git repository got up to speed in autumn and the first set of patches was accepted during the 2.6.33 merge window.

In April we took part in the Paris WirelessBattleMesh meeting with French hackers and other routing protocol developers to swap ideas and to get up to date with each others' latest improvements The follow-up meeting in Brussels was a very good occasion to prepend a BATMAN developer meeting in which we squashed bugs discussed the current development strategy upcoming releases and BATMAN V. At the 26C3 we are going to come together again - drop us a mail if you want to meet us there.

In 2010 B.A.T.M.A.N. will continue to evolve. Expect more linux kernel integration, another batman-adv major release as well as B.A.T.M.A.N. V.

We wish you all a successful 2010,

the B.A.T.M.A.N. team

B.A.T.M.A.N. V outlook

Added by Marek Lindner about 10 years ago

Now that B.A.T.M.A.N. IV is out there and works quite well, it is time to merge our gained experience and work towards B.A.T.M.A.N. V. This page contains the first collection of ideas of what the improvements could look like. To keep the list size in a digestable format we had to draw a line somewhere. Therefore it only contains items which come with a plausible concept or (even better) a proof-of-concept patch. Nevertheless, it is not final yet. Over time some ideas might proove to not work or new ideas might arise. Feel free to contact us] if you want to [[Contribute.

Convergence speed:

In order to increase the convegence speed B.A.T.M.A.N. IV forwards all valid OGMs coming by and thus increasing the probability of more packets coming through. To avoid routing problems it fixes the TQ and TLL values of packets not coming from the best neighbor. It turned out this behaviour of forward and replace may cause transient routing loops under certain conditions and the convergence speed leaves room for improvements.
B.A.T.M.A.N. V will forward packets from the best neighbor only without replacing any values. Furthermore, in case of packet loss it will detect when an OGM packet from its best neighbor did not arrive and will then broadcast the missing packet by itself (using the last known sequence number & TQ value). That way, B.A.T.M.A.N. increases the probability of transmitting OGMs over a longer chain of nodes. B.A.T.M.A.N. V could send the originator interval along with the OGM to let other nodes determine whether an OGM was missed or not.

Overhead reduction:

The traffic B.A.T.M.A.N. IV generates to discover the best path through the network is quite low compared to other protocols, but especially when B.A.T.M.A.N. has many single hop neighbors which rebroadcast each others OGMs we see room for improvements. B.A.T.M.A.N. V will split the well-known originator message into two different message types. The OGM will remain but only be used to flood the TQ throughout the network. The new message type (a name needs to be found) will contain the link qualities of the single hop neighbors only. This message won't be rebroadcasted and just reaches the local neighborhood. These local message can be sent much more often than the global TQ messages and thus reduce the traffic [nearly just create a linear growth of traffic with more nodes in the local neighborhood instead of a squared amount].

Starving mode:

Fast moving nodes always have the problem of adjusting their routing information in time. They can choose to send more routing information, so that their environment can adjust to them but stationary nodes won't do the same and increase the mobile node's adaption time greatly. However, when a B.A.T.M.A.N. V node detects that his local environment changed quickly he will enter the starvation mode. In this mode the node will actively try to confirm a working route as fast as possible by sending a "batman ping" to its new neighbors. Each B.A.T.M.A.N. neighbor will try to forward the message to its destination, once arrived there it will travel back. If the mobile node receives the reply it can change its route towards the new neighbor without waiting for OGMs as the route has been verified.

Mesh bonding mode:

In certain setups it might be desirable to use 2 or more dedicated wifi links (towards your direct neighbor) at the same time to increase the bandwidth. B.A.T.M.A.N. V will provide the mechanisms to automatically detect neighbors it could bond with and establishes the bonded connection.

Incoming interface based routing:

B.A.T.M.A.N. IV will find the best route through the network which does not fully utilize the capabilities of "multi-link nodes". If a single node is able to maintain several connections via its various interfaces to its neighbors the protocol should consider switching the interfaces in order to reduce latency and increase bandwidth. To achieve this B.A.T.M.A.N. V will create a routing table on a per interface basis. Whenever a payload packet arrives at the node it will lookup the path using the routing table for that interface. Imagine a network full of nodes having 2 wifi interfaces - B.A.T.M.A.N. V would try to make use of all existing interfaces to avoid interference and maximize throughput.

There are numerous other ideas such as faster HNA handover, optimized multicast support, etc which need to mature before they can be added to the list.

Wireless Battle Mesh (Brussels) - the 2nd encounter

Added by Marek Lindner over 10 years ago

This time, the Wireless Battle Mesh was held in the Belgium hackerspace 'OKNO' (Brussels). The techy and artistic environment provided a perfect athmosphere for both development and testing as well as convivial talks and discussions. We (the batman developers) used the occasion to gather some days before the official events started to dedicate that time entirely to B.A.T.M.A.N. related topics. Unfortunately, it was not possible to get all batman developers to join the event.

We prepared the (at that time) pending batman-adv 0.2 release, spoke about remaining issues and fixed outstanding bugs. One of the bigger problems were the temporary routing loops Andrew & Yang discovered. The tricky part was the number of nodes required to trigger the problem combined with the amount of logfiles to be analyzed before we could get even close to a solution. Simon grabbed the first part of the problem and developed a setup that would allow us replaying the situation to retrieve logfiles and test patches. His setup works great and will allow us better testing in the future (besides, he fully documented his work). Marek worked on the other side of the story and created "batctl bisect" which is able to parse large logfile sets to search for routing loops, reconstruct the OGM flow throughout the network, etc. That ultimately put us in the position to fix the issue.

Another big topic was the upcoming linux kernel integration and its impact on the project itself. Getting your code "mainline" is much more than "just" coding style changes. We discussed several kernel interface changes that will need to be implemented in the near future to keep the kernel hackers happy. To a certain degree it definitely has its advantage because some areas were a proof of concept at the beginning, meant to be cleaned later on which did not happen until now. Together with Andrew (who is driving the kernel integration process) we came up with a todo list that you can find at the bottom of this page.

Nico from the OpenWRT team had developed a neat configuration deployment tool that could reconfigure a whole bunch of routers to run a certain configuration. Linus fine tuned a configuration set for an easy batman-adv deployment which includes a vis server configuration as well as remote logging (to bisect it later on). You can grab this configuration from the hackerspace.be wiki. In combination with Nico's deployment tool it should allow us/you to spend more time on testing (instead of configuring) at the next Wireless Battle Mesh. ;)

For the testing the Belgians prepared a bunch of "portable outdoor boxes" plus mobile power supplies that allowed rapid deployment. They were mainly used to deliver test results regarding the question whether 2 single radio nodes (both 2.4GHz) connected via ethernet would be able to boost the performance by using both wifi devices in different channels or whether the short range interference would decrease the performance. The guys from Italy (Saverio Proto and Claudio Pisa) created a document explaining the setup and test method as well as the results. The full report from the WBM organizers also is worth reading.

Many thanks also go to the guys from Belgium, who had been organising everything and offered places to sleep at their hackerspace and also showed us some of their pubs and restaurants with their delicious food and beer :).

Cheers,

the B.A.T.M.A.N.-team

The batman developers that could make it to Brussels (from left to right):

Linus, Marek, Simon & Andrew

Batman-adv 0.2 released

Added by Marek Lindner over 10 years ago

The B.A.T.M.A.N. team is pleased to announce the availability of the second batman-adv release which brings major improvements, new features, changes along the way and a series of bugfixes. As the kernel module always depends on the kernel it was compiled against it does not make sense to provide binaries. However, you will find signed source tarballs for the module and batctl:

https://downloads.open-mesh.org/batman/stable/sources/

Important changes

With this release we believe that the kernel module is fully capable to replace a routing daemon feature wise as well stability wise. Therefore the batman-adv user space daemon (which was marked deprecated since the last release) as well as the vis-adv daemon have been removed from our repositories as they are no longer supported. We urge all remaining users to consider a migration towards the the kernel module.

Thanks

Special thanks go to:

  • Sven Eckelmann who continuously provides us with patches and advice whenever problems show up
  • Andrew Lunn & Yang Su for their analysis of the routing protocol which helped us to identify temporary routing loops in the code
  • Linus Luessing & Freifunk Luebeck for the rigorous testing & bug reporting of all (im)possible race conditions they encountered
  • Jacob Marble who tried to find a new home for our extravagant mailing list requirements and gave birth to the batctl idea

Thanks to all people sending in patches (in no particular order):

batman-adv

The module has undergone some major changes to better fit into the event based nature of the kernel. We removed a number of timers (e.g the new interface detection) which also greatly reduces the risk of race conditions. Also new is the packet queue that allowed implementing the aggregation (already known from the user space implementation) as well as transmission retry (ARQ) for payload broadcasts because we noticed most broadcasts vanish in transit. This feature merits some extra attention as it is the first in which the routing module influences the payload traffic directly to enhance the mesh experience. We also spent quite some energy to fix bugs in the routing algorithm that triggered temporary routing loops, squashed a TTL code bug and removed the ghost entries
from the originator table. The whole code received linux coding style adjustments, refactoring & cleanups. Furthermore all kernel version compatibility code has been unified in compat.h. The internal vis server received another output format (JSON) plus secondary interface export functionality in the dot draw format. Numerous small bugs were fixed such as using the random ethernet generator from the kernel for better randomness, exporting the version via /sys/module/batman_adv/version, fixing alignment issues, race conditions and deadlocks.

batctl

Although this is the first release of batctl it carries the same release version as the kernel module (for the sake of simplicity). It is based on the work of Andreas Langer who created the battools which were never officially released. Since then it has been extended to the point that it serves as configuration utility, monitoring and debugging application. It allows to modify the module parameters, reading the logfiles & tables, decapsulate embedded packets on the fly, traceroute to / ping mac addresses, generate sequence number graphs and more. Check the README to get an impression.

road ahead

The batman-adv development lying ahead can be separated into 2 big chunks: The linux kernel integration already started and we began working on batman's move into the linux land (more information can be found on www.open-mesh.org) - expect follow up news in the coming weeks. In the meantime a large number of ideas are flying around how to further improve the B.A.T.M.A.N. algorithm to increase its convergence speed, reduce traffic overhead and much more. A first idea collection will be published soon.

Happy routing,

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

B.A.T.M.A.N. goes mainline

Added by Marek Lindner over 10 years ago

Since its existence the batman-adv kernel module has been residing outside of the linux kernel and needed to be downloaded / compiled / installed seperately. We intend to change this by merging the batman-adv kernel module into the linux mainline tree. Greg Kroah Hartman has agreed to include the module as part of the staging drivers as a first step.

Roadmap

  • Bringing the 0.2 release into staging asap.
  • After gathering feedback from other kernel hackers build patches on top of 0.2 to conform with the linux kernel coding style & rules. The result will be version 0.2.5.
  • In parallel we will start the 0.3 branch in which new features can be included as well as the linux patches from the 0.2.5 branch.

How are we going to tackle this ?

As the kernel developers prefer git over SVN we created our own git repository which imports all changes from our SVN to make backporting changes as easy as possible. git allows us to manage different patchesets for the kernel hackers. Checkout https://git.open-mesh.org to get the git repository and learn how to use it.

Status

We maintain a TODO file in the git repository that you can see here:

https://git.open-mesh.org/TODO.html

If you are interested in helping us out you can grab one item, make a patch and send it to our Mailinglist.

Batman 0.3.2 released

Added by Marek Lindner over 10 years ago

Hi folks,

the B.A.T.M.A.N. team is releasing the second bugfix and maintenance release of the 0.3 batman daemon which also contains smaller enhancements in various areas. It's mostly an update to batman 0.3 and does not contain major routing protocol changes. We offer signed source tarballs:

https://downloads.open-mesh.org/batman/stable/sources/

In the past many new users experienced difficulties using batman to connect to the internet as it was necessary to enable NAT on the tunnel manually. With this release we address this issue. The batman daemon will try to locate the iptables binary to setup the masquerading automatically. This behaviour can be disabled using the "--disable-client-nat" option. If the outgoing packets are not masqueraded (the iptables binary wasn't found / the automatism disabled) batman will switch to the "half tunnel" mode which operates without masquerading. This mode requires the gateway to have a routing entry for each client that accesses the internet (e.g. non-batman clients may be announced via HNA).

The whole HNA code has been rewritten and now supports multiple nodes announcing the same network segment. You may have one non-batman network but several entry points to it. All border nodes can announce the same network. Receiving batman nodes choose their entry point based on the best TQ value available. The packet aggregation that exists since batman 0.3 has been enabled by default.

Thanks to Benjamin Henrions persistence the hop penalty was modified to make use of multi radio interfaces to maximize throughput. Nathan Wharton and Sven Eckelmann debugged alignment issues on Avila boards. Sven also improved the kernel routing communication and contributed many more patches. Antoine van Gelder developed an extension for the vis server that allows the vis server to export its data in the JSON format if it was started using the "-j" parameter.

In the coming months we want to focus on improving the protocol. Therefore we will start the batman 0.4 branch soon.

Happy routing,

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

(81-90/94)

Also available in: Atom