The following commit has been merged in the master branch: commit 97c2a108e7392f20921b7a2b7e6e898a1b97f933 Author: Corinna 'Elektra' Aichele onelektra@gmx.net Date: Sat Sep 30 20:36:16 2006 +0200

commit message missing

diff --git a/CHANGELOG b/CHANGELOG index dbf690e..cf3286d 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -1,6 +1,13 @@

version 0.1 ^^^^^^^^^^^ +documentation: + +- english documentation updated to 0.10-rc0 - 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 +- added the textfile 'THANKS' +

new functions:

diff --git a/INSTALL b/INSTALL index 3bf8c78..56b30b8 100755 --- a/INSTALL +++ b/INSTALL @@ -2,7 +2,9 @@ B.A.T.M.A.N Installation and Use #################################

-Axel Neumann (neumann@tkn.tu-berlin.de) +Marek Lindner +Stefan Sperling +Axel Neumann (neumann@nomail.net) Corinna 'Elektra' Aichele (onelektra@gmx.net) Thomas Lopatic (thomas@lopatic.de) Felix Fietkau (nbd@nbd.name) @@ -12,64 +14,73 @@ Felix Fietkau (nbd@nbd.name) Preface -------

-This is a minimalistic and experimental piece of code to test the viability -of the B.A.T.M.A.N-II routing algorithm based on ideas of Thomas Lopatic and -Corinna 'Elektra' Aichele. +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 +and Corinna 'Elektra' Aichele.

-This is implementation 0.06 of the improved B.A.T.M.A.N algorithm with -bidirectional link check mechanism. It is not unlikely that we have to -fix some bugs. So far the deamon seems to behave well... +This is implementation 0.1-rc0 of the improved B.A.T.M.A.N-III algorithm. It +is not unlikely that we have to fix some bugs. + +Use - like always - at your own risk!

-------- Features --------

-At the moment this code implements just the bare routing algorithm. It will only work on a -single interface (of course it could be a virtual one, to run a deathmatch -against other routing protocols like olsrd) ;-) - -There is no gateway-feature yet. So set up an IPIP-tunnel by hand. +Improved B.A.T.M.A.N-III algorithm +Free-BSD support +Mac OS-X support +IP-Tunnels +Gateway detection +Multiple Interfaces support +Support for a server that collects link-state information from each node to generate two +dimensional or three dimensional topology graphs.

------- Roadmap -------

-If the tests with this algorithm are sucessful, implementing a gateway feature should not -take too long. We will definitely go for a way to semi-automatically set up -IPIP-Tunnels to avoid too much gateway-switching. This is a real annoyance if you -are behind a NATed gateway - which is the default in most environments - -because your SSH, VOIP, FTP, IM-Sessions, Downloads... are interrupted every time -the protocol chooses to switch the gateway. +So far IP-Tunnels use TCP in TCP - which is known to have bad performance +when links are lossy. We are going to move to UDP for the IP-Tunnels. + +Testing, improvements in the documentation. + +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

-Supporting multiple interfaces should be the next step after implementing the gateway feature.

-This process can of course be accelerated with your support (testing, debugging, -coding, patches.) +------------ +Requirements +------------

+Linux with kernel-module 'tun' loaded if you want to use/be a gateway +FreeBSD +MacOS-X

------------ Installation ------------

-At the moment there is only support for Linux. You need the usual working -environment to compile software. In the B.A.T.M.A.N directory type +You need the usual working environment to compile software. In the +B.A.T.M.A.N directory type

make <press enter>

After the compilation process is finished you'll find a executable called 'batman'. This -executable is quite big because it contains debugging information for GDB. +executable is quite big because it is not stripped.

-If you want to use the routing deamon on a small embedded system you should -strip it - that means removing the informations needed by GDB. To do this just -perform +Strip it by performing:

strip batman <press enter>

Note there is no installation script at the moment. If you want to install -it, copy the deamon to a location in your path, for example /usr/sbin or -/usr/local/bin. +it, copy the deamon to a location somewhere in your path, for example +/usr/sbin or /usr/local/bin.

@@ -78,26 +89,66 @@ Use ---

-Make sure you have no firewall running that is blocking UDP port 1966. - -The functionality of B.A.T.M.A.N at the moment is minimal, so launching it is -fairly easy. In the directory with the B.A.T.M.A.N deamon type - as root - +Make sure you have no firewall running that is blocking UDP port 1966. +Type in the B.A.T.M.A.N source-directory: + +./batman -H + + +Usage: batman [options] interface [interface interface] + + -d debug level + default: 0, allowed values: 0 - 3 + + -g gateway class + + Use this feature if you want to offer a internet gateway and tell + clients what kind of gateway you are! + + default: 0 -> this is not an internet gateway + allowed values: 1 -> modem line + 2 -> ISDN line + 3 -> double ISDN + 4 -> 256 KBit + 5 -> UMTS / 0.5 MBit + 6 -> 1 MBit + 7 -> 2 MBit + 8 -> 3 MBit + 9 -> 5 MBit + 10 -> 6 MBit + 11 -> >6 MBit + + -h shorter help + -H this help + + + -o orginator interval in ms + default: 1000, allowed values: >0 + + -p preferred gateway + + This will set up an IP-Tunnel to the destination IP + + default: none, allowed values: IP

-./batman <interface> <press enter> + -r routing class (only needed if gateway class = 0)

-Example: + If you are a client, this will select the way you choose an + internet-gateway

-If the interface you want batman to run on is wlan0, type: + default: 0 -> set no default route + allowed values: 1 -> use fast internet connection + 2 -> use stable internet connection + 3 -> use best statistic internet connection (olsr style)

-./batman wlan0 <press enter> + -s visualisation server

-If you want to start with debug level 1, type: + The Server-IP that collects the topology information for + topology-visualisation

-./batman -d wlan0 + default: none, allowed values: IP

-You can add more d's to have even more debugging information:

-./batman -ddd wlan0

Switch the output of runtime debugging messages to a low level if you want diff --git a/LIESMICH b/LIESMICH index 881954c..db7a0b5 100755 --- a/LIESMICH +++ b/LIESMICH @@ -1,7 +1,22 @@ + + + +---------------------------------------------------------------------------- +HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS + +Die deutschsprachige Doku (dieser Text) ist veraltet. Die englische Version +'Readme' ist dagegen up-to-date. + +HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS HINWEIS +---------------------------------------------------------------------------- + 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 Durchf�hrbarkeit wir mit diesem Code testen wollen. Alle bisherigen uns bekannten Routingalgorithmen f�r MANETs (Mobile Ad-Hoc Networks) versuchen diff --git a/README b/README index 4d9f5bf..9f5b7de 100755 --- a/README +++ b/README @@ -1,142 +1,219 @@ -B.A.T.M.A.N-II +B.A.T.M.A.N-III

BETTER APPROACH TO MOBILE AD-HOC NETWORKING

-B.A.T.M.A.N is a new and pretty much different approach to Ad-Hoc-Routing, -whose operability we want to test with this code. So far all popular routing -algorithms for MANETs (Mobile Ad-Hoc Networks) that we are aware of try to -calculate routes. B.A.T.M.A.N does something completely different. It -doesn't calculate routes - it detects routes that exist and uses them, if -needed. - -B.A.T.M.A.N does not care where a route goes along that it utilizes to -connect to another node in the mesh. B.A.T.M.A.N merely checks which single -hop neighbour it has to send a package to put it on the best way to a node -in the distance. If you want to find out how B.A.T.M.A.N routes to a certain -node, perform a +#################### +# 1.) INTRODUCTION # +#################### + +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 (linkstate +algorithms) calculate routes proactively from all nodes to all nodes in the +mesh-cloud, whether they are necessary or not. B.A.T.M.A.N doesn't calculate +routes - it continuously detects the existence of routes by forwarding and +receiving broadcast packets. 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 neighbour 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

ping -R <destination address>

Note that this command does not work with busybox (a multicall binary, the -'swiss knife' for embedded linux systems, used in OpenWRT and Freifunk -firmware), since 'ping' doesn't have the -R option in busybox. You can do +'swiss knife' for embedded linux systems, used for example in OpenWRT and +Freifunk firmware), since 'ping' doesn't have the -R option in busybox. You +can do

traceroute -n <destination address>

instead.

-A node in a B.A.T.M.A.N MANET is only interested to know about the existence -of all nodes that it can communicate with, either in single or multihop -range, and which single hop neighbour it has to choose as a router. To -communicate with a node in multihop range a B.A.T.M.A.N node must *only* -know which single hop neighbour is the right one to give its packets to, in -order that the packets find 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 link state -routing. +################# +# 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 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 +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 +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! + +Axel Neumann proved theoretically that the algorithm of B.A.T.M.A.N-II still +had its flaws. He has simulated 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. Internet gateway +detection and auto-negotiation of IP-Tunnels has been added, too. Last but +not least support for multiple interfaces per node has been implemented as +well. And we have a feature to collect link state information in a +centralized 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 +routing daemons. As this is a young and experimental development it needs +further testing to improve maturity, of course. + +We'll have a party at c-base in Berlin soon, to celebrate when this +milestone will finally be released as B.A.T.M.A.N-III-0.10! + +B.A.T.M.A.N. will have a hard time to gain the same popolarity like olsrd +from olsr.org. OLSR is now the same for community mesh networks in Europe +and elsewhere what 'Tempo' is for handkerchiefs in Germany. Tempo is a +german brand that produces handkerchiefs. Germans with a cold rather ask for +a 'Tempo' than for a 'Taschentuch' (= handkerchief). + +The formula: + +OLSR = Community Mesh Network + +is now established in the minds of community networkers today. + +It is overwhelming to see what olsr.org has been growing into. Let's wait and see +the way that B.A.T.M.A.N. goes :) + + +##################################### +# 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 +existence of all nodes that it can communicate with, either in single or +multihop range, and which single hop neighbour it has to choose as a router +to a certain destination. To communicate with a node in multihop range a +B.A.T.M.A.N node only needs to know which single hop neighbour 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 +link state routing. + +Reactive (Source Routing) Algorithms

Source routing means a node Y in the mesh 'thinks', that the best way to send data to node D is a path where the packet travels from node Q to node S, from node S to node H, from H to W - and so on - until the data terminates at the destination node. Y gives Q the directive to send the data to S. S receives the directive from Y to send the data to H - the whole -chain is planned by the orginator of the traffic. So Y computes the path to +chain is planned by the originator of the traffic. So Y computes the path to D and tells intermediate nodes what to do.

One known design for MANET Routing is DSR - Dynamic Source Routing. DSR contains an algorithm that aims to find source routes and to maintain them, in case they break down. The fly in the ointment is, that MANETs are subject to highly dynamic changes. A MANET does not only lose payload data, but -loses topology information also. If the orginator is several hops away from +loses topology information also. If the originator is several hops away from the destination it is very likely that the information about the topology on -the other end is very hazy, incomplete and outdated. The orginator is the -node most incompetent to decide the path of the data on the other end. The -chain could be already broken down before Y sends its first packet. Y -receives the message "destination host unreachable' and starts looking for a -new path again. - -In a mesh with link state routing (LSR) every node tries to calculate routes -valid for the whole mesh from every single node to every other. Fortunately -this does not mean source routing, because the view about the topology in -the distance is hazy, too. In fact every node maintains a huge database and -computes paths that its packets should follow and hands it confidingly to -the next neighbour on the path that it has calculated. While one node may -believe that it knows the path that the packages are going to travel, each -node maintains its own database and calculates its own paths. So every node -autonomously computes its own decisions when initiating or forwarding -traffic. This decisions are likely to differ from what an orginator believes -about the path its packets are going to travel. +the other end is very hazy, incomplete and outdated. The originator is the +node most incompetent to decide the path of the data on the other end of the +path. The chain could be already broken down before Y sends its first +packet. Y then receives a message that the destination host is unreachable +and starts looking for a new path again. + +Proactive (Link State Routing) Algorithms + +In a mesh with proactive link state routing (LSR) every node tries to +calculate routes valid for the whole mesh from every single node to every +other. Fortunately this does not mean source routing, because the view about +the topology in the distance is hazy, too. In fact every node maintains a +individual huge database and computes paths that packets should follow and +hands payload packets confidingly to the next neighbour on the path that it +has calculated. While one node may believe that it knows the path that the +packages are actually going to travel, each node maintains its own database +and calculates its own paths. So every node autonomously computes its own +decisions when initiating or forwarding traffic.

There are two flies in the ointment that come with this approach. First tradeoff is the calculation of huge databases, while all a node can decide is select the next single hop neighbour that it hands a packet to. Second -the databases in nodes in a mesh with more than a handful of nodes are +the databases in nodes in a mesh with a considerable number of nodes are never really consistent - so routing loops can occur if the route calculations of two nodes involved in forwarding traffic are not in sync and collide with each other. Link state routing therefore bears a lot of overhead and problems. The advantage compared to source routing is that a -node nearer to the destination has better information about the status of +node closer to the destination has better information about the status of the topology and can compute better decisions about the path.

If routing loops occur you get the message 'Time to live exceeded' when performing a 'ping'.

-The link state routing protocol (LSR) most popular today is OLSR from -olsr.org. OLSR with LinkQualityExtension and Fisheye-Algorithm works quite -well, apart from a few bugs and the annoying effect, that it too often -switches between internet gateways which causes problems (connections break -down, timeouts) when these gateways perform network address translation -(masquerading). In the end OLSR lacks an IP-Tunnel-Plugin that would users -allow to select their gateways. +The link state routing protocol (LSR) that is most popular today in the open +source world is OLSR from olsr.org. OLSR with LinkQualityExtension and +Fisheye-Algorithm works quite well, apart from a few bugs and the annoying +effect, that it too often switches between internet gateways which causes +problems (connections break down, timeouts). OLSR lacks an IP-Tunnel-Plugin +that would users allow to select their gateways.

-In conclusion OLSR is too complicated for its own good and draws too much -CPU-Power. So it is time for something more simple and more effective - -B.A.T.M.A.N +In conclusion the algoritm of OLSR is too complicated for its own good and +draws too much CPU-Power. So it is time for something more simple and more +effective.

-Antoine Saint Exupery, Autor of the 'The little prince' said this quote stammt: +There is a well known quotation from Antoine Saint Exupery, Author of the 'The +little prince':

All human doing goes the way from the primitive along the complicated to the simple.

+B.A.T.M.A.N. could be a milestone in the development of a simple yet well +performing routing algorithm for MANETs.

-B.A.T.M.A.N is a simple set of rules a node has to comply with. +B.A.T.M.A.N. is a simple set of rules a node has to comply with.

-##################################### -# Simple B.A.T.M.A.N procedure # -# # -# B.A.T.M.A.N-I # -#####################################

-A firewall must not block B.A.T.M.A.N traffic. B.A.T.M.A.N sends its traffic -on Port 1966 UDP. This port must be open for incoming and outgoing traffic. -This is a problem occuring quite often. +########################## +# B.A.T.M.A.N. ALGORITHM # +########################## + + +NOTE: +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.

-1.) Broadcasts

-B.A.T.M.A.N detects its neighbours and distant nodes by transmitting and -receiving broadcasts that are forwarded by every node. A broadcast (we will -call it orginator messages from now on) contains the orginator address, a -sequence number and a TTL. TTL or Time-To-Live is a number that is -decremented by 1 every time the packet is forwarded. If the TTL value -reaches 0 the packet is dropped. The TTL is used to avoid packets endlessly -roaming around. This is a common mechanism in TCP. The TTL does also tell -how often has been forwarded. Particular important for B.A.T.M.A.N is the -sequence number. Orginators number their broadcasts so other nodes can -deceide whether they receive a orginator message the first time or receive -it repeatedly. +B.A.T.M.A.N detects neighbours 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 +broadcast message initiated from a distant node it is aware of the existence +of the node.

-Orginator messages are broadcasted from every node at a given interval and -forwarded by all other nodes. If a broadcast gets lost it is not -resend. If a node receives a orginator message for the first -time it is forwarded. + +ORIGINATOR MESSAGES + +A broadcast (we will call it originator message from now on) contains at +least the originator address, a sequence number and a TTL. TTL or +Time-To-Live is a counter that is decremented by 1 every time before the +packet is forwarded. If the TTL value reaches 0 the packet is dropped. The +TTL is used in TCP to avoid packets endlessly roaming around. This is a +common mechanism. The TTL does also tell how often a originator message has +been forwarded if the initial TTL-Value is known. + +Particular important for B.A.T.M.A.N. is the sequence number. Originators +number their broadcasts so other nodes can deceide whether they receive a +originator message the first time or repeatedly. + +Originator messages are initiated from every node at a given interval and +forwarded by all other nodes according to the rules of the algorithm. If a +broadcast gets lost it is not resend.

Imagine we have a chain of mesh nodes:

Node A <--> Node B <--> Node C <--> Node D

Imagine further that every node can only see its direct neighbours. Now node A -broadcasts a orginator-message. Node B receives the message and rebroadcasts it. +broadcasts a originator-message. Node B receives the message and rebroadcasts it.

Thereby node C receives the information: Message from node A, forwarded from node B, sequence number 0, TTL 49 @@ -162,74 +239,113 @@ Node A + ------------ Node D -------- + Node F

What does B.A.T.M.A.N do now?

-Node A broadcasts an orginator-message with sequence number 0. B, C, D and E +Node A broadcasts an originator-message with sequence number 0. B, C, D and E all forward this message.

-Node F receives the orginator-message sequence number 0 from node A -forwarded by node D first and memorises that he has seen A over D. Node F -ignores the orginator-message with sequence number 0 from A, that he +Node F receives the originator-message sequence number 0 from node A +forwarded by node D first and memorises that it has seen A over D. Node F +ignores the originator-message with sequence number 0 from A, that he 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. All node F has to do is memorise where it gets most orginator messages +and/or quicker. All node F has to do is memorise where it gets most originator messages from. Speed is decisive, because node F is only memorising who is forwarding the packet first. If node F wants to communicate with node A it simply sends its packets to the node with the best statistic.

If the statistic is equal amongst two or more neighbours the biggest TTL is -decisive. If TTL is equal, too the last received orginator packet from +decisive. If TTL is equal the last received orginator packet from destination host is decisive.

-###################################### -# Improved B.A.T.M.A.N procedure # -# # -# B.A.T.M.A.N-II # -######################################

+TABLES AND LISTS MAINTAINED BY B.A.T.M.A.N. + +1.) List of symmetric single hop neighbours + +Each node maintains a list of direct neighbours that contains all nodes that +it has a direct bidirectional (symmetric) communication link to. +Bidirectional links are detected when a originator receives its +self-initiated originator messages getting directly repeated by its +neighbours. + +2.) Table of Originators and Ranking + +This table contains all nodes that are detected by receiving their +originator messages and the number of originator pakets received via each +bidirectional neighbour. The best neighbour for each originator is added to +the kernel routing table of the underlying operating system as router to the +originator. + +Example: Ranking table in Node Q + +List of Originatorpackets received from +Originators Neighbour A Neighbour B Neighbour C Neighbour D + +A 12 9 7 3 + +B 3 7 17 4 + +C 0 3 27 1 + +D 0 2 17 8 + +X 3 3 9 4 + +Y 9 1 12 2 + + +According to the ranking table Q would route payload traffic to: + +A via A +B via C +C via C +D via C +X via C +Y via C + + +ORIGINATOR MESSAGE RANKING POLICY + +(Sorry if this sounds like programm code :) + +If a originator message with a unknown sequence number is received first via +the best ranking neighbour the packet count is increased for the best +neighbour.

+If a originator message with a unknown sequence number is not received via +the best ranking neighbour but from another bidirectional neighbour the +packet count is increased for that neighbour.

-The simple B.A.T.M.A.N procedure has a limitation: It does not consider that -wireless links could be unidirectional. The assumption is, that there is a -way back on the path orginator messages came from. A single unidirectional -(unsymmetric) link would spoil the whole concept. It is not uncommon in a -wireless network that links work perfectly - but only in one direction. So -the simple B.A.T.M.A.N algorithm would fail miserably. So the conclusion is -that B.A.T.M.A.N must check that it only considers symmetric links. +If a originator message with a unknown sequence number is received via the +best ranking neighbour but received first from another bidirectional +neighbour the packet count is increased for the best ranking neighbour as +long as the TTL of the originator message from the best neighbour and...

-This could be achieved with a simple set of rules: +Uff - if you want to read further check out the programm code ;)

-1.) Bidirectional link check

-Neighbours that repeat our own orginator messages with a value of TTLMAX - 1 -can see us and we can see them if we receive them forwarding our own -orginator broadcasts. Only messages from neighbours that we have a -bidirectional link to are prcessed. If we don't see them repeat our -orginator messages within a given timeframe we consider them as unsymmetric -neighbours again. +ORIGINATOR MESSAGE FORWARDING POLICY

-2.) Broadcasts from nodes that we have no bidirectional link to are ignored -and not forwarded. We ignore them until the bidirectional link check is -successful again. +Only originator packets that are received via the best ranking neighbour are +forwarded - that means rebroadcasted.

+That was easy...

-3.) Exception from rule 1.) and 2.)

-Orginator broadcasts from orginators that are single hop neighbours are -repeated always. These are broadcasts with TTLMAX. We do so even if the -orginators are not bidirectional neighbours. In this case we put an -'unsymmetric-flag' in the broadcast before we repeat it. So the orginator -can tell that we successfully received him. Other nodes that see the message -ignore them because they see the flag. The forwarded orginator message with -'unsymmetric-flag' is of interest only for the orginator that initiated the -transmission. +BIDIRECTIONAL NEIGHBOUR DETECTION AND UNIDIRECTIONAL FLAG

-This exception is necessary to avoid an chicken-and-egg problem. Otherwise -we would ignore all orginator messages from our single hop neighbours -forever. And they would forever ignore us, of course... +Originator messages originated from single hop neighbours are repeated +always, but if we don't receive our own self-initiated originator messages +getting rebroadcasted by a neighbour we add a unidirectional flag in +response to his self-initiated broadcasts.

+Originator messages with unidirectional flag that were not initiated by us +are always ignored. If we see a neighbour directly repeat our self-initiated +originator messages then there is obviously a bidirectional link between +us.

Happy testing!

-Elektra, Thomas, Axel, Felix \ No newline at end of file +Elektra \ No newline at end of file diff --git a/THANKS b/THANKS new file mode 100644 index 0000000..b01c4a4 --- /dev/null +++ b/THANKS @@ -0,0 +1,12 @@ +We would like to thank all people that donated their time and skills to this +software! + +Thomas Lopatic +Marek Lindner +Axel Neumann +Corinna 'Elektra' Aichele +Stefan Sperling +Felix Fietkau +Ludger Schmudde + + diff --git a/posix.c b/posix.c index 599851f..d9ce121 100644 --- a/posix.c +++ b/posix.c @@ -518,7 +518,7 @@ int main(int argc, char *argv[]) dev = NULL; memset(&tmp_ip_holder, 0, sizeof (struct in_addr));

- printf( "B.A.T.M.A.N-II v%s (internal version %i)\n", VERSION, BATMAN_VERSION ); + printf( "B.A.T.M.A.N-III v%s (internal version %i)\n", VERSION, BATMAN_VERSION );

while ( ( optchar = getopt ( argc, argv, "d:hHo:g:p:r:s:" ) ) != -1 ) {