Babel Wireless Mesh hackathon (Paris, 19-20-21 July 2013)

A hackathon dedicated to the Babel wireless mesh routing protocol will be held during three days in Paris, at the hackerspace. The event primarily aims at testing the new features of Babel (diversity, RTT metric, source-specific routing, etc…) in a real-world environment.


Start: Friday 19 July @ 09:00

End: Sunday 21 July @ 22:00 


  • Setup of a testbed of 20 nodes or more, some of them on batteries
  • Test the new features of Babel in real-world conditions
  • Test interoperability between different implementations and different extensions of the protocol
  • Basic tests inspired by the Wireless Battle Mesh ones
  • Data collection, statistics and reproductibility of the experience
  • Bug hunting (hopefully there aren’t many)
  • Degustation of belgian beers, and probably Attitude Adjustment cocktails too ūüôā


Along with the main events, some talks are scheduled on Saturday and Sunday. Feel free to propose a talk, they will be listed on the wiki page of the event:

More information will be available on LeLoop website:

We provide

  • electricity
  • internet connectivity
  • meeting place
  • coffee and tea
  • toilets
  • if needed, hosting, but get in touch with us before

Do not forget:

* Bring your laptop/computer and european power plug wire (multiprises)

* Bring your compatible router(s) with OpenWRT pre-installed

* Bring your WiFi antenna(s) and connectors

* Bring your sleeping bag, and if you need hosting send an email


Please register as soon as possible on Framadate:

The entrance is free, both as in „freedom“ and as in „free beer“ (although the beer won’t actually be free).


La Gare XP

0bis avenue Lucien Descaves

75014 Paris

Tramway: Montsouris, on T3a

Metro: Porte d’Orl√©ans on ligne 4

RER: Cité Universitaire on RER B

Google Maps:

Open Street Map:–?m




IRC: #babel on


Baptiste Jonglez
Email: baptiste.jonglez at
GSM: (+33) 6 03 72 24 79

Benjamin Henrion
Email: bh at
GSM: (+32) 484 566109

Multicast for OLSR mesh networks: Obamp release by Saverio Proto

Saverio Proto (ZioPRoTo) has the released the olsr OBAMP plugin, that was a freifunk project for the Google Summer Of Code. The OBAMP plugin allows multicast traffic to be forwarded in a OLSR mesh network. OBAMP is an overlay protocol. It first makes a mesh network with overlay links (udp tunnels) between the OBAMP nodes, and then it creates a distribution spanning tree over these mesh links.

This version of the OBAMP protocol, implemented as an OLSR plugin, is a simplified one for Wireless Community Networks, where we assume the nodes to be in fixed positions on the roof of the houses. Protocol features regarding mobility have not been implemented (yet).

To explain how the plugin works consider the scenario in the following figure:

There are 7 routers, where only 5 have the OBAMP plugin working. Router 1 2 and 6 also have an attached HNA network with some hosts.

OBAMP nodes generate OLSR OBAMP_ALIVE messages, these OLSR messages are forwarded in the whole network (also by the nodes that do not understand OBAMP thanks to the OLSR design). Because of the flooding mechanism every OBAMP node has a complete list of all the other OBAMP nodes in the mesh network. Every OBAMP node listens on the UDP port 6226 for OBAMP signalling.

When a OBAMP nodes starts it has 5 timers to periodically start operations:

OBAMP_alive_timer: every obamp node sends alive messages to advertise its presence to the other obamp nodes in the network. In the alive message every nodes states its IP address, and if it has already a tree link or not (we will see later this information is important for the outer tree create procedure).
The OBAMP network must have a member called ‚ÄúCore‚ÄĚ, that starts the TREE_CREATE procedure. The core is the node with the smallest IP address. When the list of known OBAMP nodes changes, the Core Election procedure is eventually called.

mesh_create_timer: every obamp node every OBAMP_MESH_CREATE_IVAL evaluates how far the other obamp nodes are and selects a subset of nodes to keep mesh links with. Note that to reduce signalling and to increase scalability, the overylay mesh links are setup only with a subset of the nearest OBAMP nodes. To select the overlay neighbor the OBAMP nodes first calculates the ETX distance of the nearest OBAMP nodes, and the creates overlay mesh links to every node that are far in the range (minETX,minETX+1)

tree_create_timer: the core of the network every OBAMP_TREE_CREATE_IVAL sends a message called TREE_CREATE on its mesh links. The creation of the spanning tree is very similar to the spanning tree protocol. When a TREE_CREATE message is received a OBAMP node enables a tree link with its parent and forwards the TREE_CREATE on the other mesh links. TREE_CREATE messages are generated only by the core and are numbered, so TREE_CREATE received over loops can be discarded.

outer_tree_create_timer: The mesh_create algorithm may create cluster of OBAMP nodes within the network that are disconnected between each other. This happens if there are groups OBAMP nodes that are far from each other. If this happens only the cluster where the Core is present will receive the TREE_CREATE and will receive traffic from the distribution tree. To overcome this problem if in a cluster there are not TREE_CREATE every OBAMP_TREE_CREATE_IVAL the node with the smallest IP in the cluster will make a long mesh link with the nearest node that has at least a tree link. All the necessary information to perform this procedure is diffused in the OBAMP_ALIVE messages.

purge_nodes_timer: checks expire time of various variables, and deletes nodes or tree links in a soft state fashion

The OBAMP nodes will capture the multicast udp traffic from the non-OLSR interfaces, and will forward this traffic encapsulated in the UDP tunnels of the distribution tree. The other OBAMP nodes will forward the traffic in the tree and will decapsulate it on their non-OLSR interfaces. To avoid duplicated packets the data is carried into OBAMP_DATA messages, that are identified by a sequence number, and the OBAMP source node where the traffic has been encapsulated.

In the figure black links represent real radio links, and red links represent overlay mesh links (udp tunnels). Router 1 2 3 and will create a OBAMP cluster, with two mesh links. Router 6 and 7 will create a mesh link between them. Because the mesh_create algorithm does not create a mesh link between the two clusters, the router 6 (supposing it has the smallest IP address in the mesh) will create an outer tree link with Router 3.

So please download the code and use it . If you find bugs please report them to Saverio and in the Sourceforge tracker here:

Thanks for this great result of the summer. Special thanks also to Nino from who was the mentor for this projet.



OpenWrt team announces OpenWrt Kamikaze 808 Release with Luci Interface

The OpenWrt team (Cph) has announced a new version of its Linux distribution for embedded wireless devices named "OpenWrt Kamikaze 808 Release". I talked to Felix Fietkau already at the WCW. Unfortunately we did not have the time to do an interview at the end. But Cyrus from freifunk Halle gave a short showcase of his interface (in German). The OpenWrt team was also impressed by it and they now announce the enclosure of the Luci interface officially. Congratulations Cyrus!

It has been quite a while since OpenWrt had a new Kamikaze release. The developer team has decided that it is time to get things straight and focus on a new release. This release have the official name: OpenWrt Kamikaze 808 Release.

The schedule will look like this:
*Last day in July – final release candidate: 808 RC-1 808 RC-1 will be a feature freeze, and all changes after this point will be bug fixes.
*Last day in August – final release: OpenWrt Kamikaze 808 Release.

OpenWrt Kamikaze 808 Release will focus on bringing the following:
– Firewall rewrite
– Broadcom 47xx running reliably with the new Kernel, not including wifi
– IMQ and Traffic shaping tested with newer kernels, especially 2.6.25
– Sysupgrade for more platforms (x86 is tested again)
– The new web interface (LuCI, Lua Configuration Interface)
– Attention towards the integration of security updates
– Package maintaining and updates between releases
– Testing, testing and lots of testing…

The 808 Release will also include support for several new platforms/targets. ( )

Open Hardware from Squidbee for Wireless Sensor Networks

A couple of weeks ago I was talking with Alex about meshlium. I found out more about the project now. Last week I did an interview with Jose Luis Marina from Peopleware at a workshop of FOSS Bridge in Hanoi. Peopleware develops Osmius a very advanced monitoring tool to monitor all kinds of devices. He told me about their idea of using the open Squidbee hardware for their sensor networks. They want to be able to transfer data from sensor networks in an easy and affordable way. A scenario I see here is to use mesh networks for the transmission.

SquidBee is a project that uses an open hardware design as well as open-source software as a platform for remote control and sensing: "SquidBee is an Open Hardware and Source wireless sensor device. The goal of SquidBee is getting an "open mote" to create Sensor Networks." SquidBee uses the ZigBee self-organizing low power wireless mesh network protocol. ZigBee operates in the unlicensed 2.4 GHz, 915 MHz and 868 MHz ISM bands with data rates from 20-250 kbit/second, per channel. ZigBee is optimized for super low power operation so that the devices can be operated from battery power for long amounts of time. For long-running outdoor applications, powering the devices from photovoltaic panels would be an obvious technology choice. Using the 1mW XBee power level, the XBee maximum device-to-device range is 100 meters. At the 100mW XBee pro power level, the range is extended to 1KM. Each additional node can extend the range of the mesh network, since data passes through the nodes. (Download, June 16, 2008,

Behind the project is Libelium Comunicaciones Distribuidas, a SpinOff company of the University of Zaragoza (Spain) which has develop the ZigBee communication module. The Libelium team is formed by Marcos Yarza, Alicia Asín and David Gascón. The board has been developed by the Arduino team by David Cuartielles, Massimo Banzi, David A.Mellis and Tom Igoe. They come from different institutions in Spain, Sweden, Italy and New York (compare:


Some more info from the Squidbee wiki:

The main concepts behind SquidBee are:
* Self-powered
* Wireless Comunications
Repeat with me: "Ubiquity, Ubiquity, Ubiquity…"

How does SquidBee work?  

  1. Acquires  values from environment parameters: temperature, humidity, lightness, presence, pressure or (almost!) whatever you can sense.
  2. Operates with these values, when required.
  3. Transmits these values using a low power comsumption wireless technology (ZigBee).
  4. Sleeps until next timeout and repeats from the first stept.

Second step is not always necessary, depending of the calculations needed it may be better to make them in receiver computer to save nodes energy.

An open mote? What does it really mean? It means every part of the mote is accessible and can be studied, changed, personalized, … From the schematic circuit to the source code of the programs that are running inside the mote.

Who is interested in SquidBee? Anybody who is researching in the environment monitoring field. This is also an educational project so that universities can offer to the students a multi-learning device. With SquidBee people can learn at the same time electronic, programation, communications… and everything in just one device.

Who is supporting SquiBee? The board inside SquidBee has been developed by the Arduino team. The communications module wich lets  the node transmit through a ZigBee module has been developed by Libelium. Both components are open hardware and they have a really strong community support. A specialized wiki related to SquidBee and the Sensor Networks  will be created soon. There, all the Arduino and Libelium tutorials and examples will be shared and other research teams will be able to exchange their knowledge with the community.

What can I do with SquidBee? The main concept is: "sense what you want where you want and transmit it".

Two configurations of SquidBee? What is it exactly? Using the same board and communications module we have created 2 kinds of SquidBee: the sensor mote and the gateway. The first one is the self-powered sensor mote and the second is the computer USB connected receiver.

Can I integrate SquidBee into a wireless 802.11 Mesh network? Yes! We have also developed an outdoor Mesh Router: MeshLium which you can use to collect the information using the ZigBee protocol and transmit it to the mesh network using the Wifi technology (802.11). (Version, May 15, 2008, 15.22,

Motorola will Meshnetzwerke bauen

Unter dem Namen Motomesh Duo hat Motorola auf der Hannover Messe verschiedene Ger√§te f√ľr ein City-WLAN-Netz pr√§sentiert. Au√üer der englischen Website habe ich √ľber Motorolas "Meshaktivit√§ten" bisher nicht viel gefunden. Dort gibt es verschiedene Ger√§te und einen MeshManager zu sehen.

MeshManager element management system (EMS) provides a complete
solution for configuration, fault, performance and security management
for all Motorola mesh networks. Consisting of a Java based graphical
user interface (GUI) and a series of software servers, the MeshManager
suite gives you streamlined, point-and-click access to tools needed for
complete network configuration and control. (Motorola MeshManager Website)

In dem Beitrag auf kann man Motomesh und Motorola einfach durch Freifunk ersetzen, dann hat man das, was Freifunker schon seit Jahren machen. 

Eine City-WLAN-Lösung auf der Basis von Motomesh Duo soll nicht nur
die WLAN-Endger√§te der B√ľrger umfassen, sondern ebenso
Verkehrsinformationssysteme, Location Based Services, innerstädtische
Video√ľberwachung und eGovernment-Funktionen integrieren. Wie derzeit
√ľblich, wird auch der Energiespareffekt beworben: "Zudem k√∂nnen
City-WiFi-Netze dabei helfen, Energie zu sparen, indem sie
strombed√ľrftige Anlagen steuern. So k√∂nnen Stadtwerke mittels City-WiFi
Straßenlaternen selektiv steuern und je nach Bedarf ein- oder
ausschalten", heißt es in der Motorola-Mitteilung. Zur Komplettierung
der städtischen Vernetzung will Motorola Sensoren, optische Schranken
und Perimeter-Radarsysteme liefern. Ein mit Motomesh Duo aufgebautes Kommunikationsnetz kann nach Angabe
von Motorola Flächen bis 150 Quadratkilometer abdecken. Auch weiter
entfernte Punkte im ländlichen Bereich können mit der
Punkt-zu-Punkt-Technik von Canopy erreicht werden. Nach eigenen Angaben
hat Motorola f√ľr Internet Provider in Deutschland bisher 20.000 solcher
DSL-Ersatzanbindungen installiert. Die Provider sind es auch, die
Motorola mit seinem Motomesh-Angebot ansprechen will: "Ein
flächendeckendes WiFi-Netz macht die Stadt zum Hotspot", erklärte
Alexander Burghardt, Europa-Vizepräsident der Abteilung professionelle
Funktechnik gegen√ľber heise online. (22.04.2008 13:23, Detlef Borchers,–/meldung/106846)

"150 Quadratkilometer" deckt ein Motomesh-Netzwerk ab. Aha. Wie viele geben denn Freifunk-Netze so derzeit her?

B.A.T.M.A.N.-Kapitel aus dem kompetentesten Buch √ľber freie Mesh-Netzwerke, das es gibt jetzt zum freien Download

Aus dem von elektra verfassten Buch "Mesh", welches Anfang August bei erschienen ist, gibt es jetzt das Kapitel √ľber B.A.T.M.A.N als pdf-Download:
Ausserdem beim EDV-Buchversand das Vorwort als Teaser…!

(via Cven)

Wireless Mesh Networking – Aufbau von freien Netzwerken mit WLAN

Im Chaosradio 16 zum Thema Wireless Meshworking gibt es ein Interview mit Elektra. Originalposting hier:

Teilnehmer: Tim Pritlove (Moderation), Elektra Wagenrad

Ausgabe Nummer 16 von Chaosradio Express widmet sich dem Wireless Mesh
Networking, dem Aufbau von billigen, offenen Netzwerken in
netzwerktechnisch unterversorgten Gegenden in Stadt und Land. In einem
recht geekigen Interview erläutert Elektra die Technik, existierende
Projekte und die Geschichte des Wireless Mesh Networking der letzten
f√ľnf Jahren.