The following commit has been merged in the master branch: commit ade7d9105c262f22880b63e9866f5d5073a20c93 Author: Corinna 'Elektra' Aichele onelektra@gmx.net Date: Sun Dec 17 20:57:21 2006 +0100
* inserted missing newline in verbose output * removed unused and unmaintained output 'internal version' * cosmetics: we used B.A.T.M.A.N with and without . at the end - now it is uniformly B.A.T.M.A.N.
diff --git a/CHANGELOG b/CHANGELOG index 6eb2962..0c925a6 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -1,12 +1,12 @@
-version 0.1 -^^^^^^^^^^^ +version 0.11 +^^^^^^^^^^^^
documentation:
-- english documentation updated to 0.1-rc0 - please have a look at it +- english documentation updated to 0.11 - please have a look at it - german documentation is unmaintained - maybe remove it? too lazy to write a translation at the moment... -- changed the name in the documentation and in posix.c to B.A.T.M.A.N-III, since we made quite some changes in the algorithm +- changed the name in the documentation and in posix.c to B.A.T.M.A.N.-III, since we made quite some changes in the algorithm - added the textfile 'THANKS'
diff --git a/INSTALL b/INSTALL index 28b80cf..53c5e5e 100644 --- a/INSTALL +++ b/INSTALL @@ -1,5 +1,5 @@ ################################# -B.A.T.M.A.N Installation and Use +B.A.T.M.A.N. Installation and Use #################################
Marek Lindner (lindner_marek-at-yahoo.de) @@ -16,10 +16,10 @@ Preface -------
This is still a experimental piece of code to test the viability of the -B.A.T.M.A.N routing algorithm based on initial ideas of Thomas Lopatic +B.A.T.M.A.N. routing algorithm based on initial ideas of Thomas Lopatic and Corinna 'Elektra' Aichele.
-This is implementation 0.1-final of the improved B.A.T.M.A.N-III algorithm. It +This is implementation 0.11 of the improved B.A.T.M.A.N.-III algorithm. It is not unlikely that we still have to fix some bugs, though.
Use - like always - at your own risk! @@ -29,7 +29,7 @@ Use - like always - at your own risk! Features --------
-Improved B.A.T.M.A.N-III algorithm +Improved B.A.T.M.A.N.-III algorithm IP-Tunnels via UDP Gateway classes Multiple Interfaces support @@ -46,11 +46,11 @@ Testing, improvements in the documentation. Support for Free-BSD and Mac OS-X is broken at the moment since we introduced UDP-Tunnels - we hope this will be fixed in the near future.
-Develop B.A.T.M.A.N-Advanced that routes on Layer 2 and creates a Link-Local-Illusion for higher +Develop B.A.T.M.A.N.-Advanced that routes on Layer 2 and creates a Link-Local-Illusion for higher OSI-Layers
Read speed tables from WiFi-Cards to calculate the transfer speed of routes -in B.A.T.M.A.N-Advanced +in B.A.T.M.A.N.-Advanced
------------ @@ -64,7 +64,7 @@ Installation ------------
You need the usual working environment to compile software. In the -B.A.T.M.A.N directory type +B.A.T.M.A.N. directory type
make <press enter>
@@ -92,7 +92,7 @@ ipkg update ipkg install batman-iii
If you use Freifunk-Firmware you can use the web user-interface for -b.a.t.m.a.n: +B.A.T.M.A.N.:
ipkg install freifunk-batman-de
@@ -165,13 +165,13 @@ Usage: batman [options] interface [interface interface] -o orginator interval in ms default: 1000, allowed values: >0
- Note: By default B.A.T.M.A.N keeps track of packets received in the + Note: By default B.A.T.M.A.N. keeps track of packets received in the last 60 seconds (this is called sliding window size). B.A.T.M.A.N will perform it's routing decisions based on statistics about 60 packages for a node with an orginator interval of one second. If a node manages to send us at least 1 message in 60 seconds, it will be in our routing table. If the orginator interval is increased to 3 - seconds only 20 packets will be kept in the B.A.T.M.A.N statistic - + seconds only 20 packets will be kept in the B.A.T.M.A.N. statistic - thus the node must manage to send us 1 out of 20 packets to be in our routing table. If the sliding window size has more space for orginator messages the range of multi-hop links will be longer and @@ -213,7 +213,7 @@ Usage: batman [options] interface [interface interface] Switch the output of runtime debugging messages to a low level if you want to test the software on a slow - embedded - system.
-We would love to see B.A.T.M.A.N in a match against other routing protocols +We would love to see B.A.T.M.A.N. in a match against other routing protocols in existing mesh networks. You can set up a virtual interface on an interface that you run another mesh routing protocol on.
@@ -234,7 +234,7 @@ Now you can check out which protocol works better.
Happy routing!
-The B.A.T.M.A.N contributors +The B.A.T.M.A.N. contributors
diff --git a/LIESMICH b/LIESMICH index db7a0b5..ae46792 100644 --- a/LIESMICH +++ b/LIESMICH @@ -10,24 +10,24 @@ Die deutschsprachige Doku (dieser Text) ist veraltet. Die englische Version HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS ----------------------------------------------------------------------------
-B.A.T.M.A.N-II +B.A.T.M.A.N.-II
BETTER APPROACH TO MOBILE AD-HOC NETWORKING
-B.A.T.M.A.N ist eine v�llig neue Herangehensweise an Ad-Hoc-Routing, deren +B.A.T.M.A.N. ist eine v�llig neue Herangehensweise an Ad-Hoc-Routing, deren Durchf�hrbarkeit wir mit diesem Code testen wollen. Alle bisherigen uns bekannten Routingalgorithmen f�r MANETs (Mobile Ad-Hoc Networks) versuchen -Routen zu berechnen. B.A.T.M.A.N tut etwas v�llig anderes. Es berechnet keine +Routen zu berechnen. B.A.T.M.A.N. tut etwas v�llig anderes. Es berechnet keine Routen - es sp�rt das Vorhandensein von Routen auf, und benutzt sie bei Bedarf.
-B.A.T.M.A.N interessiert sich nicht daf�r wie eine Route verl�uft die es +B.A.T.M.A.N. interessiert sich nicht daf�r wie eine Route verl�uft die es benutzt um mit einem anderen Knoten im Mesh-Netzwerk zu kommunizieren. -B.A.T.M.A.N pr�ft lediglich �ber welchen direkten Nachbarn ein bestimmter -Netzwerkknoten am besten zu erreichen ist. Wer wissen m�chte wie B.A.T.M.A.N +B.A.T.M.A.N. pr�ft lediglich �ber welchen direkten Nachbarn ein bestimmter +Netzwerkknoten am besten zu erreichen ist. Wer wissen m�chte wie B.A.T.M.A.N. zu einem bestimmten Knoten routet, kann das mit
ping -R <Zieladresse> @@ -41,10 +41,10 @@ traceroute -n <Zieladresse> herhalten.
-Ein Knoten in einem B.A.T.M.A.N-MANET interessiert sich nur daf�r, von der +Ein Knoten in einem B.A.T.M.A.N.-MANET interessiert sich nur daf�r, von der Existenz aller anderer Knoten zu wissen die er direkt oder �ber eine Multi-Hop-Verbindung erreichen kann. Um mit einem indirekten Nachbarn zu -kommunizieren muss B.A.T.M.A.N einen Nachbarn in direkter Funkreichweite +kommunizieren muss B.A.T.M.A.N. einen Nachbarn in direkter Funkreichweite bestimmen dem ein Datenpaket �berreicht werden kann, damit dieser es auf dem g�nstigsten Weg zu dem Nachbarn in der Ferne routet. Am besten wird der Vorteil dieser Herangehensweise vielleicht deutlich wenn wir �ltere Ans�tze @@ -105,7 +105,7 @@ ein paar Bugfixes. Schlussendlich st�rt aber der hohe Rechenaufwand von OLSRD in den CPUs der kleinen Meshrouter im Berliner Freifunk-Netz. Das Freifunk-MANET hat die Grenzen des Wachstums mit dem proaktiven OLSR erreicht. Zeit also f�r etwas -einfacheres und besseres: B.A.T.M.A.N +einfacheres und besseres: B.A.T.M.A.N.
Von Antoine Saint Exupery (Autor des 'Kleinen Prinz') stammt dieser Satz:
@@ -113,21 +113,21 @@ Alles menschliche Tun geht den Weg vom Primitiven Einfachen.
-B.A.T.M.A.N ist eine Gruppe von Regeln an die sich ein Router halten muss. +B.A.T.M.A.N. ist eine Gruppe von Regeln an die sich ein Router halten muss.
-##################################### -# Einfachstes B.A.T.M.A.N-Verfahren # -# # -# B.A.T.M.A.N-I # -##################################### +###################################### +# Einfachstes B.A.T.M.A.N.-Verfahren # +# # +# B.A.T.M.A.N.-I # +######################################
-B.A.T.M.A.N verwendet Port 1966 UDP. Dieser Port muss f�r eingehende und ausgehende -Nachrichten offen sein, also darf eine Firewall B.A.T.M.A.N nicht blockieren. +B.A.T.M.A.N. verwendet Port 1966 UDP. Dieser Port muss f�r eingehende und ausgehende +Nachrichten offen sein, also darf eine Firewall B.A.T.M.A.N. nicht blockieren.
1.) Broadcasts
-B.A.T.M.A.N findet seine Nachbarn und entfernte Netzwerkknoten im Mesh (im +B.A.T.M.A.N. findet seine Nachbarn und entfernte Netzwerkknoten im Mesh (im folgenden Nodes genannt) durch Broadcasts die weitergereicht werden. In einem Broadcast steht die Adresse des Erzeugers drin (im folgenden Orginator genannt). Weiterhin enth�lt der Broadcast einen TTL-Wert und eine @@ -136,7 +136,7 @@ jedesmal um den Wert 1 reduziert wird, wenn ein Datenpaket weitergereicht wird. Wird der TTL-Wert 0 ist das Paket zu lange (�blicherweise auf Irrwegen) unterwegs und wird verworfen. Anhand der TTL kann man daher auch sehen wie oft ein Paket schon weitergereicht wurde. Besonders wichtig f�r -B.A.T.M.A.N ist die Sequenznummer. Das sind die laufenden Nummern der +B.A.T.M.A.N. ist die Sequenznummer. Das sind die laufenden Nummern der Orginator-Nachrichten die ein Orginator aussendet.
Broadcasts werden in einem festgelegten Intervall von jedem Node als @@ -204,22 +204,22 @@ bei der TTL entscheidet wer das letzte eingegangene Orginator-Paket zum Zielknoten gebroadcastet hat.
-###################################### -# Verbessertes B.A.T.M.A.N-Verfahren # -# # -# B.A.T.M.A.N-II # -###################################### +####################################### +# Verbessertes B.A.T.M.A.N.-Verfahren # +# # +# B.A.T.M.A.N.-II # +#######################################
-Das einfachste B.A.T.M.A.N-Verfahren hat einen Haken: Es ber�cksichtigt nicht, +Das einfachste B.A.T.M.A.N.-Verfahren hat einen Haken: Es ber�cksichtigt nicht, dass Verbindungen unsymmetrisch sein k�nnen. Die Annahme ist, dass auf dem Pfad auf dem die Pakete von Node A den Node F erreichen auch die beste �bertragung in die Gegenrichtung m�glich ist. Das ist im Fall von unsymmetrischen Links ein Trugschluss. Unsymmetrische Links treten auf wenn ein Router zwar einen anderen h�rt, aber umgekehrt nicht. Es kann sein, dass eine perfekte �bertragung m�glich ist - aber nur in eine Richtung. Das -einfache B.A.T.M.A.N-Verfahren w�rde hier komplett scheitern. Es muss also +einfache B.A.T.M.A.N.-Verfahren w�rde hier komplett scheitern. Es muss also gepr�ft werden ob Links symmetrisch sind und nur Informationen die von diesen kommen d�rfen ausgewertet und verwendet werden.
@@ -255,7 +255,7 @@ Ansonsten w stets ignorieren - weil sie unsymmetrisch sind und bleiben. Und sie w�rden uns ignorieren... Andere Nodes d�rfen indirekt empfangene Orginatormeldungen mit TTLMAX -1 nicht wiederholen wenn der Unsymmetrieflag gesetzt wird - -sonst f�llt B.A.T.M.A.N doch noch auf Broadcasts rein, die von +sonst f�llt B.A.T.M.A.N. doch noch auf Broadcasts rein, die von unsymmetrischen Links stammen.
diff --git a/README b/README index 2a497f3..6f3bf15 100644 --- a/README +++ b/README @@ -1,4 +1,4 @@ -B.A.T.M.A.N-III +B.A.T.M.A.N.-III
BETTER APPROACH TO MOBILE AD-HOC NETWORKING
@@ -6,19 +6,19 @@ BETTER APPROACH TO MOBILE AD-HOC NETWORKING # 1.) INTRODUCTION # ####################
-B.A.T.M.A.N is a new approach to Ad-Hoc-Routing, unlike other algorithms +B.A.T.M.A.N. is a new approach to Ad-Hoc-Routing, unlike other algorithms that we are aware of. Reactive MANET protocols search for routes when a node initiates communication to a remote node. Proactive protocols (all link-state algorithms and some distance-vector algorithms) calculate routes proactively from all nodes to all nodes in the mesh-cloud, whether they are necessary or not - while reactive protocols search for routes on demand. -B.A.T.M.A.N doesn't calculate or search for routes - it continuously detects +B.A.T.M.A.N. doesn't calculate or search for routes - it continuously detects the existence of routes by forwarding and receiving broadcast packets, and it proactively populates the routing-table with nodes in the mesh. The algorithm does not try to find out which path packets follow to a remote -node. B.A.T.M.A.N merely checks which single hop neighbor it has to send a +node. B.A.T.M.A.N. merely checks which single hop neighbor it has to send a package to in order to push it on the best way to a node in the mesh. If you -want to find out how B.A.T.M.A.N routes to a certain node, perform a +want to find out how B.A.T.M.A.N. routes to a certain node, perform a
ping -R <destination address>
@@ -35,27 +35,27 @@ instead. # 2.) EVOLUTION # #################
-B.A.T.M.A.N-III is the third stage in the evolution of the -B.A.T.M.A.N. algorithm - hence the numbering scheme. B.A.T.M.A.N-I +B.A.T.M.A.N.-III is the third stage in the evolution of the +B.A.T.M.A.N. algorithm - hence the numbering scheme. B.A.T.M.A.N.-I didn't check for bidirectional link conditions when forwarding packets. This was an obvious design flaw. We didn't bother to add bidirectional link checks in the first experimental implementation that was meant to merely test the algorithm. The results of -B.A.T.M.A.N-I were however promising, so B.A.T.M.A.N-II was +B.A.T.M.A.N.-I were however promising, so B.A.T.M.A.N.-II was implemented introducing a simple mechanism to check for bidirectional links to perform further tests in real-live scenarios.
-B.A.T.M.A.N-II implemented the bare algorithm with bi-directional link +B.A.T.M.A.N.-II implemented the bare algorithm with bi-directional link checks for meshnodes with one interface only and was tested in the Freifunk meshclouds of Berlin and Weimar. Thank you very much, you are really brave guys! It was working quite nice on PCs, but the quick and dirty implementation was causing high CPU-Loads on embedded systems and even broadcast packet storms!
-We found out that the algorithm of B.A.T.M.A.N-II still had its -flaws. We identified conditions where B.A.T.M.A.N-II would choose +We found out that the algorithm of B.A.T.M.A.N.-II still had its +flaws. We identified conditions where B.A.T.M.A.N.-II would choose routes far from optimal and even could cause routing loops. Hence -B.A.T.M.A.N-III implements changes in the algorithm to cope with these +B.A.T.M.A.N.-III implements changes in the algorithm to cope with these scenarios.
Some new features, namely Internet gateway detection and @@ -66,12 +66,12 @@ server so people can download data from this server to display those fancy three-dimensional meshclouds with s3d or two-dimensional with dot-draw.
-Now B.A.T.M.A.N-III has - in theory - everything to replace other MANET +Now B.A.T.M.A.N.-III has - in theory - everything to replace other MANET routing daemons. As this is a young and experimental development it needs further testing to improve maturity, of course.
-We are having a party today - December 13th 2006 at c-base in Berlin, to celebrate -the release of this milestone as B.A.T.M.A.N-III-0.1! +On December 13th 2006 we had a party at c-base in Berlin, to celebrate +the release of this milestone as B.A.T.M.A.N.-III-0.1!
B.A.T.M.A.N. will have a hard time to gain the same popularity like olsrd from olsr.org. OLSR is now the same for community mesh networks in Europe @@ -90,14 +90,14 @@ the way that B.A.T.M.A.N. goes :)
##################################### -# 3.) MANET THEORY AND B.A.T.M.A.N # +# 3.) MANET THEORY AND B.A.T.M.A.N. # #####################################
-A node in a B.A.T.M.A.N-MANET is only interested to learn about the +A node in a B.A.T.M.A.N.-MANET is only interested to learn about the existence of all nodes that it can communicate with, either in single or multi-hop range, and which single hop neighbor it has to choose as a router to a certain destination. To communicate with a node in multi-hop range a -B.A.T.M.A.N node only needs to know which single hop neighbor is the best +B.A.T.M.A.N. node only needs to know which single hop neighbor is the best to send its packets to, so that the packets takes the best way to the node in the distance. To explain the advantage of this approach it may be best to compare it with other ideas about mesh routing - namely source routing and @@ -182,12 +182,12 @@ B.A.T.M.A.N. is a simple set of rules a node has to comply with.
NOTE: -A firewall must not block B.A.T.M.A.N traffic. B.A.T.M.A.N sends its +A firewall must not block B.A.T.M.A.N. traffic. B.A.T.M.A.N. sends its packets on Port 1966 UDP. This port must be open for incoming and outgoing UDP traffic.
-B.A.T.M.A.N detects neighbors and distant nodes by transmitting, receiving +B.A.T.M.A.N. detects neighbors and distant nodes by transmitting, receiving and repeating broadcasts according to the rules of the B.A.T.M.A.N. algorithm. These broadcasts travel through the mesh-cloud until they are lost or nobody has to rebroadcast them any more. Once a node receives a @@ -243,7 +243,7 @@ looks like this: | | *-------------- E -----------*
-What does B.A.T.M.A.N do now? +What does B.A.T.M.A.N. do now?
Node A broadcasts an originator-message with sequence number 0. B, C, D and E all forward this message. @@ -255,7 +255,7 @@ receives from node C because it receives the same message again. The message forwarded by node E may get lost or come too late to be the first, too.
Using the best path between node A and F the packets travel more -reliable and/or quicker. B.A.T.M.A.N. nodes consider the best path to +reliable and/or quicker. B.A.T.M.A.N.. nodes consider the best path to a destination only as far as to the best next hop (or neighbor) towards the destination. The best next hop is simply identified by gathering statistics about how often and via which neighbor a certain diff --git a/batman.c b/batman.c index 2ac5de1..4d82baf 100644 --- a/batman.c +++ b/batman.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2006 BATMAN contributors: + * Copyright (C) 2006 B.A.T.M.A.N. contributors: * Thomas Lopatic, Corinna 'Elektra' Aichele, Axel Neumann, * Felix Fietkau, Marek Lindner * diff --git a/batman.h b/batman.h index 60ba2ae..11ebe66 100644 --- a/batman.h +++ b/batman.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2006 BATMAN contributors: + * Copyright (C) 2006 B.A.T.M.A.N. contributors: * Thomas Lopatic, Corinna 'Elektra' Aichele, Axel Neumann, Marek Lindner * This program is free software; you can redistribute it and/or * modify it under the terms of version 2 of the GNU General Public @@ -24,7 +24,7 @@ #include <pthread.h> #include "list.h"
-#define VERSION "0.1" +#define VERSION "0.11" #define BATMAN_VERSION 1 #define PORT 1966 #define UNIDIRECTIONAL 0x80 @@ -33,7 +33,7 @@
/* * No configuration files or fancy command line switches yet - * To experiment with B.A.T.M.A.N settings change them here + * To experiment with B.A.T.M.A.N. settings change them here * and recompile the code * Here is the stuff you may want to play with: */
diff --git a/posix.c b/posix.c index e636c28..0c2104c 100644 --- a/posix.c +++ b/posix.c @@ -1040,14 +1040,14 @@ int main(int argc, char *argv[])
case 'v':
- printf( "B.A.T.M.A.N-III v%s (internal version %i)", VERSION, BATMAN_VERSION ); + printf( "B.A.T.M.A.N.-III v%s \n", VERSION); return (0);
case 'V':
print_animation();
- printf( "\x1B[0;0HB.A.T.M.A.N-III v%s (internal version %i)", VERSION, BATMAN_VERSION ); + printf( "\x1B[0;0HB.A.T.M.A.N.-III v%s", VERSION); printf( "\x1B[9;0HMay the bat guide your path ...\n" );
return (0); @@ -1110,7 +1110,7 @@ int main(int argc, char *argv[])
} else {
- printf( "B.A.T.M.A.N-III v%s (internal version %i)\n", VERSION, BATMAN_VERSION ); + printf( "B.A.T.M.A.N.-III v%s \n", VERSION );
}