The Ninux.org team announced the first “Ninux Day”, a weekend with about and for wireless communities. You will meet software and hardware hackers, geeks, nerds, engineers, artists, the curious and academics. Experts from all over Europe offer technical and social presentations in the area of wireless community networks.
Join the Ninux Days in Rome, Italy, from November 27-29, 2009.
More Info here:
* http://wiki.ninux.org/NinuxDay2009en (English)
* http://wiki.ninux.org/NinuxDay2009it (Italian)
* Announcement: http://blog.ninux.org/2009/09/03/ninux-day-2009
* Ninux Blog http://blog.ninux.org
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 ninux.org who was the mentor for this projet.
HackerSpaceBrussels (HSB) announces the second Wireless Battle Mesh, which aims to test 3 popular WiFi routing protocols (OLSR, Batman and Babel), in Brussels on Saturday and Sunday 17-18 October 2009.
Wireless Mesh Battle: OLSR vs. BATMAN vs. Babel
We setup some IRC meetings to prepare the configuration: IP's, versions, and everything that took too much time at WBM v1. The meetings will be held on the tuesdays of 15 and 22 September and 06 October at 21:00 CET on irc.freenode.net channel #hsbxl. People from Brussels and around are invited to join us at the hackerspace.
The event is free. We'll kindly ask you for a donation to cover some costs.
Space is limited, so we ask you to register in advance by registering:
Tel (ptr_): +32 493 52 50 09
Tel (zoobab): +32 484 56 61 09
24c3, Chaos Communication Congress: Aaron Kaplan from the OLSR developing team and member of the Austrian funkfeuer community had a short lightning talk on the recent improvements of the OLSR protocol, which they now call OLSR-NG.
The whole lightning talk session can be downloaded via the torrent network (torrents below).
Marek Lindner and Simon Wunderlich from the Berlin freifunk community gave a talk on Wireless Kernel Tweaking and the B.A.T.M.A.N. routing protocol at the 24c3 Chaos Communication Congress. The video is now available on the torrent network.
Kernel hacking definitely is the queen of coding but in order to bring mesh routing that one vital step further we had to conquer this, for us, unchartered territory. Working in the kernel itself is a tough and difficult task to manage, but the results and effectivity to be gained justify the long and hard road to success. We took on the mission to go down that road and the result is B.A.T.M.A.N. advanced which is a kernel land implementation of the B.A.T.M.A.N. mesh routing protocol specifically designed to manage Wireless MANs.
During the last years the number of deployed mesh networks has increased dramatically and their constant growth drove us around the edge of what we thought was possible. To cope with this rapid development we had to leave the slow and limited track of tweaking existing approaches and take an evolutionary step forward by porting the B.A.T.M.A.N. protocol into the kernel land and going down to layer 2. Using B.A.T.M.A.N. advanced as a showcase we will, in our lecture, deliver a detailed review on how one can go about developing linux kernel modules, give insights in what difficulties to expect and provide practical tips on how to go about this challenge without experiencing a damaging kernel freeze in due process.
We will describe what problems we faced migrating down to layer 2 and how we went about solving them for example how we moved away from the kernel routing and handle the actual routing and data transport in B.A.T.M.A.N. itself. Also moving to layer 2 meant to leave IPs behind and solely rely on MAC-routing enabling features like DHCP, IPX, IPv6, etc which up to now was not possible and therefore comes as a big plus. On the other hand there were little if none diagnostic tools at all for routing on that level so we had to go back one step and develop the tools we needed ourselves.
These and other things we will cover in our presentation and also give an outlook into the future of mesh-routing, which will bring it even closer to the source of wifi - the wireless stack and its drivers and thereby improving the overall performance even more.
Schon in Chaosradio Express 016 hat Elektra einen tiefen Einblick in Wesen und Form des Mesh Networking geboten. Im Gespräch mit Tim Pritlove werden nun die neuesten Erkenntnisse der Entwicklung berichtet. Kern der Neuigkeiten ist der Nachfolger des OLSR-Protokolls namens B.A.T.M.A.N. Elektra erläutert, wie B.A.T.M.A.N. im Deatil funktioniert, welche Erfahrungen und Erkenntnisse seinem Design zu Grunde liegen und wie man sich das alles vorstellen muss. Ein Teil der Diskussion betrifft auch die geplante Mesh Networking Technologie im OLPC (XO) Laptop. (20.9.2007, http://chaosradio.ccc.de/cre045.html)
Am letzten Sonntag liefen auf Rundfreifunk Interviews von der B.A.T.M.A.N.-Release-Party. Die Party fand auf der c-base in Berlin statt. Die Sendung findet man nun auch online unter http://www.public-ip.org/sendung-170.html. Darin unter anderem Interviews mit: Elektra, Sven-Ola., Tetzlav, Ludger und Poelzi zu OLSR, BATMAN, Firewalls und Puffer-/Pollraten...
Viel Spaß beim Hören!
Die Freifunk-Community traf sich auf dem 23. Chaos Communication Congress in der Wireless Corner. Am Rande des Congresses sprechen Elektra und Sven Ola über das vergangene Jahr und geben einen kleinen Ausblick, wie es mit Freifunk weiter geht. Was ist passiert und wohin geht die Reise mit der Community, der Freifunk Firmware, OLSR und dem neuen B.A.T.M.A.N.-Protokoll?