commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/News-archive (b48c2fee)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit b48c2fee60f3edc0415e5cd948e879f09eb47735 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Thu Mar 17 03:53:57 2011 +0000 doc: open-mesh/News-archive >--------------------------------------------------------------- b48c2fee60f3edc0415e5cd948e879f09eb47735 open-mesh/News-archive.textile | 1 + 1 file changed, 1 insertion(+) diff --git a/open-mesh/News-archive.textile b/open-mesh/News-archive.textile index 664f8361..0f93f10f 100644 --- a/open-mesh/News-archive.textile +++ b/open-mesh/News-archive.textile @@ -5,6 +5,7 @@ This page contains the links to previous news posts for archiving puposes. [[BR]] === 2010 === + * '''04.Sep. 2010''' [wiki:2010-09-04-batman-adv-2010-1-0-release Batman-adv 2010.1.0 released] * '''19.Jun. 2010''' [wiki:2010-06-19-batman-adv-2010-0-0-release Batman-adv 2010.0.0 released] * '''13.Jun. 2010''' [wiki:2010-06-13-wbm2010-bracciano WBMv3 in Bracciano] * '''19.Apr. 2010''' [wiki:2010-04-19-scheduled-server-downtime Scheduled server downtime]

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/News-archive (8617f68f)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 8617f68fb0b05eaa5988a84fe01e139d01a5c11d Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Thu Mar 17 03:53:57 2011 +0000 doc: open-mesh/News-archive >--------------------------------------------------------------- 8617f68fb0b05eaa5988a84fe01e139d01a5c11d open-mesh/News-archive.textile | 63 +++++++++++++++++++++++++----------------- 1 file changed, 37 insertions(+), 26 deletions(-) diff --git a/open-mesh/News-archive.textile b/open-mesh/News-archive.textile index 0f93f10f..f1759660 100644 --- a/open-mesh/News-archive.textile +++ b/open-mesh/News-archive.textile @@ -1,29 +1,40 @@ -= News archive = + +h1. News archive + This page contains the links to previous news posts for archiving puposes. -[[BR]] - -=== 2010 === - * '''04.Sep. 2010''' [wiki:2010-09-04-batman-adv-2010-1-0-release Batman-adv 2010.1.0 released] - * '''19.Jun. 2010''' [wiki:2010-06-19-batman-adv-2010-0-0-release Batman-adv 2010.0.0 released] - * '''13.Jun. 2010''' [wiki:2010-06-13-wbm2010-bracciano WBMv3 in Bracciano] - * '''19.Apr. 2010''' [wiki:2010-04-19-scheduled-server-downtime Scheduled server downtime] - * '''22.Mar. 2010''' [wiki:2010-03-22-batman-adv-0-2-1-release Batman-adv 0.2.1 released] - * '''02.Mar. 2010''' [wiki:2010-03-02-batman-at-wbmv3 B.A.T.M.A.N. at WBMv3] - -[[BR]] -=== 2009 === - * '''26.Dec. 2009''' [wiki:2009-12-26-retrospect-batman-in-2009 Retrospect 2009] - * '''18.Dec. 2009''' [wiki:2009-12-18-batman-v-outlook B.A.T.M.A.N. V outlook] - * '''18.Nov. 2009''' [wiki:2009-11-18-wbm2009-2nd-encounter WirelessBattleMesh2009v2] - * '''09.Nov. 2009''' [wiki:2009-11-08-batman-adv-0-2-release Batman-adv 0.2 released] - * '''23.Oct. 2009''' [wiki:2009-10-23-batman-goes-mainline Batman goes mainline] - * '''13.Jun. 2009''' [wiki:2009-06-13-batman-0-3-2-release Batman 0.3.2 released] - * '''19.Apr. 2009''' [wiki:2009-04-19-wbm2009-aftermath WirelessBattleMesh2009] - * '''25.Jan. 2009''' [wiki:2009-01-25-batman-0-3-1-release Batman 0.3.1 released] - -[[BR]] -=== 2008 === - * '''28.Dec. 2008''' [wiki:2008-12-28-batman-adv-0-1-release Batman-adv 0.1 released] - * '''16.Nov. 2008''' [wiki:2008-11-16-batman-adv-goes-debian Batman-adv now available in Debian] + + + + +h3. 2010 + +* *04.Sep. 2010* [[2010-09-04-batman-adv-2010-1-0-release|Batman-adv 201010 released]] +* *19.Jun. 2010* [[2010-06-19-batman-adv-2010-0-0-release|Batman-adv 201000 released]] +* *13.Jun. 2010* [[2010-06-13-wbm2010-bracciano|WBMv3 in Bracciano]] +* *19.Apr. 2010* [[2010-04-19-scheduled-server-downtime|Scheduled server downtime]] +* *22.Mar. 2010* [[2010-03-22-batman-adv-0-2-1-release|Batman-adv 021 released]] +* *02.Mar. 2010* [[2010-03-02-batman-at-wbmv3|BATMAN at WBMv3]] + + + + +h3. 2009 + +* *26.Dec. 2009* [[2009-12-26-retrospect-batman-in-2009|Retrospect 2009]] +* *18.Dec. 2009* [[2009-12-18-batman-v-outlook|BATMAN V outlook]] +* *18.Nov. 2009* [[2009-11-18-wbm2009-2nd-encounter|WirelessBattleMesh2009v2]] +* *09.Nov. 2009* [[2009-11-08-batman-adv-0-2-release|Batman-adv 02 released]] +* *23.Oct. 2009* [[2009-10-23-batman-goes-mainline|Batman goes mainline]] +* *13.Jun. 2009* [[2009-06-13-batman-0-3-2-release|Batman 032 released]] +* *19.Apr. 2009* [[2009-04-19-wbm2009-aftermath|WirelessBattleMesh2009]] +* *25.Jan. 2009* [[2009-01-25-batman-0-3-1-release|Batman 031 released]] + + + + +h3. 2008 + +* *28.Dec. 2008* [[2008-12-28-batman-adv-0-1-release|Batman-adv 01 released]] +* *16.Nov. 2008* [[2008-11-16-batman-adv-goes-debian|Batman-adv now available in Debian]]

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/WikiStart (cc2ed041)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit cc2ed041da071010dfca1943a33cb84ecfda0b29 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Thu Mar 17 03:58:40 2011 +0000 doc: open-mesh/WikiStart >--------------------------------------------------------------- cc2ed041da071010dfca1943a33cb84ecfda0b29 open-mesh/WikiStart.textile | 62 ++++++++++++++++++--------------------------- 1 file changed, 25 insertions(+), 37 deletions(-) diff --git a/open-mesh/WikiStart.textile b/open-mesh/WikiStart.textile index 06b6b68d..c8de0e75 100644 --- a/open-mesh/WikiStart.textile +++ b/open-mesh/WikiStart.textile @@ -1,41 +1,29 @@ - -h1. Welcome to Open Mesh - -*This page serves as development platform for a collection of tools to build free and open mesh networks.* += Welcome to Open Mesh = +'''This page serves as development platform for a collection of tools to build free and open mesh networks.''' ---- - -h1. B.A.T.M.A.N. - += B.A.T.M.A.N. = B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is a routing protocol for multi-hop ad-hoc mesh networks. This is the main development website, we have source code, binary packages, documentation and further information available: - -h2. News - -* *17.Mar. 2011* [[2011-03-17-batman-adv-and-the-penguin|Batman-adv and the Penguin join forces]] -* *29.Jan. 2011* [[2011-01-29-batman-adv-2011-0-0-release|Batman-adv 201100 released]] -* *18.Jan. 2011* [[2011-01-18-wbmv4-announcement|WBMv4 Announcement]] -* *12.Dec. 2010* [[2010-12-12-batman-v-status-update|BATMAN V status update]] -* *22.Nov. 2010* [[2010-11-21-batman-adv-2010-2-0-release|Batman-adv 201020 released]] - -* [[news-archive|news archive]] - -h2. Getting Started - -* [[Download|Download]] - Get our latest releases, get access to our SVN repository -* [[Contribute|How to contribute]] - How to report bugs, send comments, patches or suggestions - -h2. Documentation - -* [[BranchesExplained|Branches explained]] - learn about the B.A.T.M.A.N. flavours -* [[UserDocs|UserDocs]] - understand how B.A.T.M.A.N. works -* [[FAQ|FAQ]] - Frequently Asked Questions -* [[Experience|Experience]] - Collection of links to B.A.T.M.A.N. press reviews, papers and projects using B.A.T.M.A.N. -* [[Patches|Patches]] - contribution from others related to B.A.T.M.A.N. -* [[batman-adv|BATMAN Advanced]] - information about the Layer 2 version of B.A.T.M.A.N. -* [[MailingList|Mailing List][wikiIRC IRC]] - contact us +== News == + * '''17.Mar. 2011''' [wiki:2011-03-17-batman-adv-and-the-penguin Batman-adv and the Penguin join forces] + * '''29.Jan. 2011''' [wiki:2011-01-29-batman-adv-2011-0-0-release Batman-adv 2011.0.0 released] + * '''18.Jan. 2011''' [wiki:2011-01-18-wbmv4-announcement WBMv4 Announcement] + * '''12.Dec. 2010''' [wiki:2010-12-12-batman-v-status-update B.A.T.M.A.N. V status update] + * '''22.Nov. 2010''' [wiki:2010-11-21-batman-adv-2010-2-0-release Batman-adv 2010.2.0 released] + + * [wiki:news-archive news archive] +== Getting Started == + * [wiki:Download Download] - Get our latest releases, get access to our SVN repository + * [wiki:Contribute How to contribute] - How to report bugs, send comments, patches or suggestions +== Documentation == + * [wiki:BranchesExplained Branches explained] - learn about the B.A.T.M.A.N. flavours + * [wiki:UserDocs UserDocs] - understand how B.A.T.M.A.N. works + * [wiki:FAQ FAQ] - Frequently Asked Questions + * [wiki:Experience Experience] - Collection of links to B.A.T.M.A.N. press reviews, papers and projects using B.A.T.M.A.N. + * [wiki:Patches Patches] - contribution from others related to B.A.T.M.A.N. + * [wiki:batman-adv B.A.T.M.A.N. Advanced] - information about the Layer 2 version of B.A.T.M.A.N. + * [wiki:MailingList Mailing List]/[wiki:IRC IRC] - contact us ---- - -h2. Other Projects on open-mesh.org - -* [[FFTrace|FFTrace]] - freifunk traceroute tool -* [[MeshLinux|MeshLinux]] - Linux distribution geared to build mesh supernodes \ No newline at end of file +== Other Projects on open-mesh.org == + * [wiki:FFTrace FFTrace] - freifunk traceroute tool + * [wiki:MeshLinux MeshLinux] - Linux distribution geared to build mesh supernodes \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/ELP: some more specific questions (291e9a1d)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 291e9a1d2ef646ce8c6c92a49054edb2775d5aea Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Wed Mar 16 22:41:33 2011 +0000 doc: batman-adv/ELP: some more specific questions >--------------------------------------------------------------- 291e9a1d2ef646ce8c6c92a49054edb2775d5aea batman-adv/ELP.textile | 215 ++++++++++++++++++++++++++++++------------------- 1 file changed, 131 insertions(+), 84 deletions(-) diff --git a/batman-adv/ELP.textile b/batman-adv/ELP.textile index 7474778c..40e97423 100644 --- a/batman-adv/ELP.textile +++ b/batman-adv/ELP.textile @@ -1,42 +1,50 @@ -= Neighborhood Discovery Protocol (NDP) = -{{{ -#!div style="width: 46em; text-align: justify" +h1. Neighborhood Discovery Protocol (NDP) -The B.A.T.M.A.N. protocol originally only used a single message type (called OGM) to determine the link qualities to the direct neighbors and spreading these link quality information through the whole mesh. This procedure is summarized on the [wiki:BATMANConcept B.A.T.M.A.N. concept page] and explained in details in [http://tools.ietf.org/html/draft-wunderlich-openmesh-manet-routing-00 the RFC draft] published in 2008. + +<pre> +<code class="div"> + +The B.A.T.M.A.N. protocol originally only used a single message type (called OGM) to determine the link qualities to the direct neighbors and spreading these link quality information through the whole mesh. This procedure is summarized on the [[BATMANConcept|BATMAN concept page]] and explained in details in "the RFC draft":http://tools.ietf.org/html/draft-wunderlich-openmesh-manet-routing-00 published in 2008. This approach was chosen for its simplicity during the protocol design phase and the implementation. However, it also bears some drawbacks: - * Wireless interfaces usually come with some packet loss, therefore a higher broadcast rate is desirable to allow a fast reaction on flaky connections. Other interfaces of the same host might be connected to Ethernet LANs / VPNs / etc which rarely exhibit packet loss would benefit from a lower broadcast rate to reduce overhead. - * It generally is more desirable to detect local link quality changes at a faster rate than propagating all these changes through the entire mesh (the far end of the mesh does not need to care about local link quality changes that much). Other optimizations strategies, like reducing overhead, might be possible if OGMs weren't used for all tasks in the mesh at the same time. +* Wireless interfaces usually come with some packet loss, therefore a higher broadcast rate is desirable to allow a fast reaction on flaky connections. Other interfaces of the same host might be connected to Ethernet LANs / VPNs / etc which rarely exhibit packet loss would benefit from a lower broadcast rate to reduce overhead. +* It generally is more desirable to detect local link quality changes at a faster rate than propagating all these changes through the entire mesh (the far end of the mesh does not need to care about local link quality changes that much). Other optimizations strategies, like reducing overhead, might be possible if OGMs weren't used for all tasks in the mesh at the same time. As a result detecting local link qualities shall be handled by an independent message type, NDP, whereas the OGM message type remains responsible for flooding the mesh with these link quality information and determening the overall path transmit qualities. -=== Definitions === - * node - A mesh router which utilizes the B.A.T.M.A.N. protocol as specified in this document on at least one network interface. A node consists of one or more originators. - * originator - An addressable entity within one mesh network routing layer. An originator's address has to be unique within a mesh network routing layer and unique on a node. A node's hard-interface may only be utilized by zero or one originator. - * B.A.T.M.A.N./hard interface - Network interface utilized by B.A.T.M.A.N. for its own ethernet frames. - * sliding window - Sequence numbers are recorded in dedicated sliding windows until they are considered out-of range. Thus, such a sliding window always contains the set of recently received sequence numbers. The amount of sequence numbers recorded in the sliding window is used as a metric for the quality of detected links and paths. - * duplicate - A received NDP message from a neighbor containing an already received sequence number. - * out of order - A received NDP message from a neighbor containing a sequence number that is older than the newest sequence number ever received from this neighbor. +h3. Definitions + + +* node - A mesh router which utilizes the B.A.T.M.A.N. protocol as specified in this document on at least one network interface. A node consists of one or more originators. +* originator - An addressable entity within one mesh network routing layer. An originator's address has to be unique within a mesh network routing layer and unique on a node. A node's hard-interface may only be utilized by zero or one originator. +* B.A.T.M.A.N./hard interface - Network interface utilized by B.A.T.M.A.N. for its own ethernet frames. +* sliding window - Sequence numbers are recorded in dedicated sliding windows until they are considered out-of range. Thus, such a sliding window always contains the set of recently received sequence numbers. The amount of sequence numbers recorded in the sliding window is used as a metric for the quality of detected links and paths. +* duplicate - A received NDP message from a neighbor containing an already received sequence number. +* out of order - A received NDP message from a neighbor containing a sequence number that is older than the newest sequence number ever received from this neighbor. + + +h3. Protocol Procedure -=== Protocol Procedure === -==== Broadcasting own Neighborhood Discovery Protocol (NDP) Messages ==== + +h4. Broadcasting own Neighborhood Discovery Protocol (NDP) Messages + Each node periodically (NDP interval) generates and broadcasts NDP messages for each interface B.A.T.M.A.N. is running on. A jitter may be applied to avoid collisions. -__The Neighborhood Discovery Protocol (NDP) Format:__ ++The Neighborhood Discovery Protocol (NDP) Format:+ - * Packet type: Initialize this field with the NDP packet type. - * Version: Set your internal compatibility version. - * Originator Address: Set this field to the primary MAC address of this B.A.T.M.A.N. node. - * Sequence number: On first broadcast set the sequence number to an arbitrary value and increment the field by one for each following broadcast. - * Num Neigh: The number of neighbors that are announced with this message. +* Packet type: Initialize this field with the NDP packet type. +* Version: Set your internal compatibility version. +* Originator Address: Set this field to the primary MAC address of this B.A.T.M.A.N. node. +* Sequence number: On first broadcast set the sequence number to an arbitrary value and increment the field by one for each following broadcast. +* Num Neigh: The number of neighbors that are announced with this message. If this B.A.T.M.A.N. interface wants to announce neighboring nodes it should append a neighbor entry message for each neighbor to be announced and fill the "number of neighbors" field accordingly. -{{{ +<pre> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -48,16 +56,16 @@ If this B.A.T.M.A.N. interface wants to announce neighboring nodes it should app +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Neigh | Alignment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -}}} +</code></pre> -__The Neighbor Entry Format:__ ++The Neighbor Entry Format:+ - * Neighbor Address: This field contains the MAC address of the neighbor to be announced. - * Link RQ: Fill this field with the total of the received sequence numbers (in percent) within the sliding sequence number window from this neighbor. +* Neighbor Address: This field contains the MAC address of the neighbor to be announced. +* Link RQ: Fill this field with the total of the received sequence numbers (in percent) within the sliding sequence number window from this neighbor. Note: See 'Neighbor Ranking' to get a detailed description of how to count/obtain the RQ value. Neighbors with an RQ value of 0 are not to be appended. -{{{ +<pre> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -65,89 +73,126 @@ Note: See 'Neighbor Ranking' to get a detailed description of how to count/obtai +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Address | Link RQ | Alignment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -}}} +</code></pre> + + +h4. Receiving Neighborhood Discovery Messages (NDP) -==== Receiving Neighborhood Discovery Messages (NDP) ==== Upon receiving a NDP packet a node must perform the following preliminary checks before the packet is further processed: - * If the NDP contains a version which is different to the own internal version the message must be silently dropped (thus, it must not be further processed). - * If the sender address of the NDP message belongs to one of the B.A.T.M.A.N. interfaces the message must be silently dropped as this NDP message originated from this node. - * If the sender address of the NDP message is an ethernet multicast (including broadcast) address the message must be silently dropped. - * If the NDP message is a duplicate or does not contain a newer sequence number (out-of-order) the message must be silently dropped. +* If the NDP contains a version which is different to the own internal version the message must be silently dropped (thus, it must not be further processed). +* If the sender address of the NDP message belongs to one of the B.A.T.M.A.N. interfaces the message must be silently dropped as this NDP message originated from this node. +* If the sender address of the NDP message is an ethernet multicast (including broadcast) address the message must be silently dropped. +* If the NDP message is a duplicate or does not contain a newer sequence number (out-of-order) the message must be silently dropped. + + +h4. Neighbor Ranking -==== Neighbor Ranking ==== For each NDP message having passed the preliminary checks the following must be performed: - * The sliding window to the sender of the NDP message must be updated (purged) to reflect the new upper and lower boundaries of the ranking range. The sequence number of the received NDP message must be added to the sliding window representing the link via which the NDP message has been received. - * The new resulting link RQ value is calculated by counting all sequence numbers that are to be found in the recently adjusted sliding window. - * The new current sequence number must be set to the sequence number contained in the received NDP message. - * All appended neighbor entries must be parsed to search for all MAC addresses belonging to one of the B.A.T.M.A.N. interfaces. If a match is found then save the received link RQ value towards that neighbor as link TQ value. +* The sliding window to the sender of the NDP message must be updated (purged) to reflect the new upper and lower boundaries of the ranking range. The sequence number of the received NDP message must be added to the sliding window representing the link via which the NDP message has been received. +* The new resulting link RQ value is calculated by counting all sequence numbers that are to be found in the recently adjusted sliding window. +* The new current sequence number must be set to the sequence number contained in the received NDP message. +* All appended neighbor entries must be parsed to search for all MAC addresses belonging to one of the B.A.T.M.A.N. interfaces. If a match is found then save the received link RQ value towards that neighbor as link TQ value. + + + +h4. Questions + + +* checks whether the NDP packet is too old? (TODO: Simon, add/describe the protected window mechanism) +* Shall we add "neighbor" interface addresses, which are our own to the NDP packet? (e.g., if one node has two interfaces which share the same broadcast domain) +* Shall we process one of our own NDP packets which we received over one of our other interfaces? (e.g. if one node has two interfaces which share the same broadcast domain) +* Shall we scan a NDP packet received from one of our neighbors only for an entry matching the incoming interface? (e.g. if one node has two interfaces which share the same broadcast domain) +* What to do if there are multiple entries with the matching mac address(es)? Only use the first and ignore the other matches? +* If a match has been found, do not further procede the traversal of neighbor entries +* Are NDP entries with a RQ of 0 allowed? +* What to do if RQ reaches 0 due to automatic sliding window? +* What to do if receiving an NDP packet which does not have the nodes own interface mac? Treating it as RQ of 0? Or keeping old value? -==== Questions ==== +h2. Extensions == + Threshholds === - * checks whether the NDP packet is too old? (TODO: Simon, add/describe the protected window mechanism) - * If an entry matches the mac address of the receiving interface and if the seqno is a new one, - then update/memorize the link TQ towards that neighbor with this value. - (TODO: does it make sense to not only check if the incoming interface mac matches, but also for other interfaces? Which would be the case if a node uses two interfaces sharing somehow the same broadcast domain... rare, but possible... example: two wifi interfaces, using channels 1 and 3) - * If a match has been found, do not further procede the traversal of neighbor entries +h3. EWMA === + Weighted Window === + +h3. Auto RQ window sliding === + Fixed minimum NDP packet size? === + +h3. Sometimes maximum packet size packets? -== Extensions == -=== Threshholds === -=== EWMA === -=== Weighted Window === -=== Auto RQ window sliding === -=== Fixed minimum NDP packet size? === -=== Sometimes maximum packet size packets? === ---- -== examples of NDP advantages == - * Modularization of the code - * The delta changes between two OGMs can be increased with an NDP interval faster than the OGM interval, resulting in a higher influence of a single OGM. - * Separate optimization strategies can be used for NDP and OGMs individually then. - * The more sparse the network is (number of single hop neighbors significantly smaller than the number of all nodes), the faster the NDP interval can be chosen relative to the OGM interval, resulting in major convergence speed improvements in sparse networks. - * As NDP messages are never rebroadcasted it also helps to reduce the overhead in dense networks (many single hop neighbors). - * (Mobile nodes can chose a faster OGM + NDP interval then. It directly improves their transmit path - which was not the case with the OGM LQ measurements due to the echo-quality dependency, and indirectly improves their receive path a little, due to the asymmetric penalty) - * Less overhead: With the classic LQ measurements with NDP, the overhead increases in a squared way immediately due to the OGM rebroadcast mechanism. The squared factor in NDP has a very low base however, therefore it only applies at a large amount of neighbors. This means, that when having i.e. 10 neighbors (or probably even 50), you can select a 10 (or 50x) faster NDP interval compared to the LQ measurements with the classic OGMs. - * More accuracy in case of medium/bad links: The EQ mechanism "reduces" the effective window for the EQ measurements. So when having a TQ of 50%25, the effective EQ window will be only ~32 bits large instead of the 64, leading to many more TQ/RQ fluctuations on links with a low transmit quality. - * You usually should set the originator interval to a value suiting the most mobile node on all nodes, having a homogeneous interval. This means, that even if you have a very static neighborhood with lots of nodes (so resulting to a lot of rebroadcasts, which can be the case on VPN- or ethernet interfaces used by batman-adv), you can't lower the interval for that one because very mobile nodes far away might than not be able to reach you anymore. - * A OGM should not be rebroadcasted by the same node more than once because that could falsify the link-quality calculations. However you might want to do this to speed the convergence at more distant and/or weaker links. +h2. examples of NDP advantages + +* Modularization of the code +* The delta changes between two OGMs can be increased with an NDP interval faster than the OGM interval, resulting in a higher influence of a single OGM. +* Separate optimization strategies can be used for NDP and OGMs individually then. +* The more sparse the network is (number of single hop neighbors significantly smaller than the number of all nodes), the faster the NDP interval can be chosen relative to the OGM interval, resulting in major convergence speed improvements in sparse networks. +* As NDP messages are never rebroadcasted it also helps to reduce the overhead in dense networks (many single hop neighbors). +* (Mobile nodes can chose a faster OGM + NDP interval then. It directly improves their transmit path - which was not the case with the OGM LQ measurements due to the echo-quality dependency, and indirectly improves their receive path a little, due to the asymmetric penalty) +* Less overhead: With the classic LQ measurements with NDP, the overhead increases in a squared way immediately due to the OGM rebroadcast mechanism. The squared factor in NDP has a very low base however, therefore it only applies at a large amount of neighbors. This means, that when having i.e. 10 neighbors (or probably even 50), you can select a 10 (or 50x) faster NDP interval compared to the LQ measurements with the classic OGMs. +* More accuracy in case of medium/bad links: The EQ mechanism "reduces" the effective window for the EQ measurements. So when having a TQ of 50%25, the effective EQ window will be only ~32 bits large instead of the 64, leading to many more TQ/RQ fluctuations on links with a low transmit quality. + +* You usually should set the originator interval to a value suiting the most mobile node on all nodes, having a homogeneous interval. This means, that even if you have a very static neighborhood with lots of nodes (so resulting to a lot of rebroadcasts, which can be the case on VPN- or ethernet interfaces used by batman-adv), you can't lower the interval for that one because very mobile nodes far away might than not be able to reach you anymore. +* A OGM should not be rebroadcasted by the same node more than once because that could falsify the link-quality calculations. However you might want to do this to speed the convergence at more distant and/or weaker links. + + +h2. RQ calculation -== RQ calculation == In periodic intervals, customizable per interface, a ndp packet gets broadcasted on each interface. As it has been done with the normal OGMs before, the rq-value is being calculated with a sliding window and counting the number of received ndp packets, but on a per interface basis now. -== local TQ propagation == + +h2. local TQ propagation + Additionally, a 2-tupel of neighbor-adresses and rq-values of neighbors on a certain interface will be attached to each ndp packet of the according interface. A neighbor will then pick the rq-value which the other node determined from the received ndp packets and insert this value as its own tq-value towards that node. -== global TQ propagation == + +h2. global TQ propagation + A node receiving an OGM will reduce its global TQ field by the local TQ fitting the neighbor and interface before processing/rebroadcasting (but after validation/duplicate checks). -== Data packet forwarding == + +h2. Data packet forwarding + This will still be done according to the received global TQ. ---- -== Further optimizations == -=== Consider local-TQ for a final forwarding === +h2. Further optimizations + + + +h3. Consider local-TQ for a final forwarding + It might happen, that a node rapidly moves towards the sender of a data packet. If so, a forwarding node can notice, that the local TQ value towards the final destination of the data packet is suddenly better than the global TQ via another hop. This forwarding node can then forward the packet to its final destination instead of forwarding it to the other next-hop according to the global TQ. -=== Rebroadcast OGM X times instead of once === + +h3. Rebroadcast OGM X times instead of once + Every node could rebroadcast an OGM i.e. 3 times instead of just once to increase the probability of an OGM reaching every node in the mesh, resulting in a much better convergence speed (getting closer to linear convergence speed) for the trade-off of control overhead (getting closer to squared). -=== Unscheduled OGM rebroadcasts === + +h3. Unscheduled OGM rebroadcasts + + -=== Adaptive ndp interval === +h3. Adaptive ndp interval + + + +h3. Probablistic flooding -=== Probablistic flooding === Although this does not optimize the convergence speed, it could greatly increase the efficiency of the flooding of broadcast/mulitcast-data packets. With ndp we now also know our neighbors' TQ-values on the same interface. With this information a node A can determine the probability, that a broadcast of node B has already reached all of A's neighbors: P(|N| = |N^+^|) = ∏_{n ∈ N} TQ(B, iface, n) with N being the set of A's neighbors and N^+^ the set of neighbors successfully receiving the broadcast. @@ -157,30 +202,32 @@ A node could then either decide with a threshold, if it might not rebroadcast (r ---- -==== Looping problems ==== -''Not an NDP issue, also present for current OGM mechanism - moved it to a different page later'' +h4. Looping problems + + +_Not an NDP issue, also present for current OGM mechanism - moved it to a different page later_ However, there seems to be a looping problem? (or do sequence numbers or global TQ window fix this?) In the following 4 node scenario, the parameters are as follows: - * OGM interval: 1000 - * NDP interval: ε (very fast) +* OGM interval: 1000 +* NDP interval: ε (very fast) Now node R moves from B to A within the first second, so he'll arrive at B before it schedules its next OGM. Also this next OGM after this first second already uses the new link qualities due to the fast NDP interval. -'''t = 0:''' +*t = 0:* [[Image(NDP-mobile-loop-0s.png, 20%25)]] -'''t = 1:''' +*t = 1:* [[Image(NDP-mobile-loop-1s.png, 20%25)]] After about 10 seconds average, there will be a loop with S sending packets to B, and B sending them back to S. This loop will last for about 3.3 seconds average. -The following [[http://x-realis.dyndns.org/freifunk/scan.pdf table]] will hold some more in detail information with the times and events that will change BATMAN nodes topology knowledge. It holds the following information: - * The times t in the table are the average times of arrival of an OGM at a node in seconds. - * The table shows the TQ values towards R. The first six of these rows are from a nodes perspective, the last two ones the actual, real TQ values for the chosen path. - * Time span with loops is marked with YES in the 'loops' row. +The following [[table]] will hold some more in detail information with the times and events that will change BATMAN nodes topology knowledge. It holds the following information: +* The times t in the table are the average times of arrival of an OGM at a node in seconds. +* The table shows the TQ values towards R. The first six of these rows are from a nodes perspective, the last two ones the actual, real TQ values for the chosen path. +* Time span with loops is marked with YES in the 'loops' row. -''Result:'' In this quite typical and small-scale scenario, we already have an average time with looping packets of '''3.3''' seconds. -}}} +_Result:_ In this quite typical and small-scale scenario, we already have an average time with looping packets of *3.3* seconds. +</code></pre>

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Quick-start-guide: instead you are just using the new bridge interface 'mesh-bridge' for routing: clarify that IP has to be assigned to mesh-bridge (c393d474)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit c393d474a6ad5da553167634c84f6f8ba46421d8 Author: Hendrik Fabelje <batman(a)fabelje.de> Date: Wed Mar 2 16:55:26 2011 +0000 doc: batman-adv/Quick-start-guide: instead you are just using the new bridge interface 'mesh-bridge' for routing: clarify that IP has to be assigned to mesh-bridge >--------------------------------------------------------------- c393d474a6ad5da553167634c84f6f8ba46421d8 batman-adv/Quick-start-guide.textile | 62 +++++++++++++++++++++--------------- 1 file changed, 36 insertions(+), 26 deletions(-) diff --git a/batman-adv/Quick-start-guide.textile b/batman-adv/Quick-start-guide.textile index 1fcf9a38..27beeaf5 100644 --- a/batman-adv/Quick-start-guide.textile +++ b/batman-adv/Quick-start-guide.textile @@ -1,81 +1,91 @@ -= B.A.T.M.A.N. Advanced quick start guide = -{{{ -#!div style="width: 46em; text-align: justify" +h1. B.A.T.M.A.N. Advanced quick start guide + + +<pre> +<code class="div"> This page shall show a couple of easy examples of how to use and setup a mesh network with B.A.T.M.A.N.-Advanced (further referenced as batman-adv). It is assumed, the tool 'batctl' was installed which allows a more intuitive configuration, though everything can be configured by accessing '/sys/class/net/$iface/batman-adv/...' directly without the need of installing batctl. -=== Configuring interfaces === + +h3. Configuring interfaces + In the first configuraton step you need to tell batman-adv which interfaces it should use to build the mesh network. This can be either wifi devices like wlanX or athX but also common ethernet devices, usually ethX. batman-adv is not limited to a certain interface type, therefore you can use any interface you can find with 'ifconfig' (even pan0 for bluetooth if you like B.A.T.M.A.N. more than the normal, build-in 'mesh-protocol' of bluetooth :-) ). Those interfaces can be added by using 'batctl if add ifname', e.g. -{{{ +<pre> batctl if add eth0 -}}} +</code></pre> Make sure, this interface is up and running ('ifconfig eth0 up') and use the command -{{{ +<pre> batctl if -}}} +</code></pre> to verify its status. Check the system log for hints in case it does not behave as you expect. Despite being up, those interfaces that have been added using batctl don't need any ip-address configured as batman-adv is operating on layer 2 (which is a common mistake by people who are more familiar with the 'old' batmand or other layer 3 routing protocols)! Those interfaces are bridge-interfaces - you just must not use those plain interfaces for routing anymore. -=== bat0 === + +h3. bat0 + So where are we going to send data packets to if not to those interfaces we have given batman-adv? That's where the virtual bat0 interface (created by batman-adv) is getting into the game. Usually you are going to assign IP adresses to this one - either manually or via dhcpv4 / avahi autoconfiguration / dhcpv6 / ipv6 autoconfiguration. Any packet that enters this interface will be examined by the batman-adv kernel module for its destination mac-adress and will be forwarded with the help of B.A.T.M.A.N.'s routing voodoo then, so that finally, magically it pops out at the right destination's bat0 interface :). -=== Examples === -'''simple mesh network'''[[BR]] +h3. Examples + + +*simple mesh network* + On all nodes, install batman-adv, load the module and enter the following commands: -{{{ +<pre> ifconfig wlan0 mtu 1524 iwconfig wlan0 mode ad-hoc essid my-mesh-network ap 02:12:34:56:78:9A channel 1 -}}} +</code></pre> -{{{ +<pre> batctl if add wlan0 ifconfig wlan0 up ifconfig bat0 up -}}} +</code></pre> You can now use the automatically assigned IPv6 link-local adresses on bat0 (usually starting with fe80::...), modern operating systems should support this. Or you can assign IPv4 addresses manually on all those nodes (i.e. 'ifconfig bat0 192.168.123.x/24') or one of the laptops in range has to have a DHCP server running on the bat0 interface. As batman-adv is operating on layer 2, even dhcp-messages can be send over the mesh network. -'''Note:''' batman-adv inserts an additional header of 24 bytes into each data packet being send over the mesh. Therefore we are increasing the maximum size of a packet over the plain interfaces to 1524, so that packets with the standard MTU of 1500 can pass normaly through bat0. You might also decrease the MTU to 1476 on all hosts but is usually just do-able in more or less static- and small-scaled mesh-networks. +*Note:* batman-adv inserts an additional header of 24 bytes into each data packet being send over the mesh. Therefore we are increasing the maximum size of a packet over the plain interfaces to 1524, so that packets with the standard MTU of 1500 can pass normaly through bat0. You might also decrease the MTU to 1476 on all hosts but is usually just do-able in more or less static- and small-scaled mesh-networks. + +*mixing non-B.A.T.M.A.N. systems with batman-adv* -'''mixing non-B.A.T.M.A.N. systems with batman-adv'''[[BR]] If you have a couple of computers that you don't want to run batman-adv on but you still want make use of the mesh network, you will need to configure an entry point for them on a node running batman-adv. Any device running Linux (a notebook, a wifi-router, a pc with a wifi card, ...) can be setup to work as a mesh entry point. In addition to the usual mesh setup steps mentioned above it is necessary to configure a bridge over bat0 and the interface those 'non-B.A.T.M.A.N.' machines are connected to. Let's say eth0 is the interface on a mesh access point where those non-B.A.T.M.A.N. systems are attached to and wlan0 is the interface on a mesh access point through which we want to build the mesh network. On each mesh access point, install batman-adv first, load the module and enter the following commands: -{{{ +<pre> ifconfig wlan0 mtu 1524 iwconfig wlan0 mode ad-hoc essid my-mesh-network ap 02:12:34:56:78:9A channel 1 -}}} +</code></pre> -{{{ +<pre> batctl if add wlan0 ifconfig wlan0 up -}}} +</code></pre> -{{{ +<pre> brctl addbr mesh-bridge brctl addif mesh-bridge eth0 brctl addif mesh-bridge bat0 ifconfig eth0 up ifconfig bat0 up ifconfig mesh-bridge up -}}} +</code></pre> From now on you won't want to use eth0, wlan0 or bat0 for any routing anymore, instead you are just using the new bridge interface 'mesh-bridge'. Any packet our mesh access point receives over eth0 will be forwarded to bat0 because of the bridge. batman-adv will forward it through the mesh according to the destination's mac address. -'''Note:''' Assign the IP Address to mesh-bridge in this case, not bat0. +*Note:* Assign the IP Address to mesh-bridge in this case, not bat0. For the MTU-part have a look at the note above. -''(How does batman-adv know where it has to send a data packet of an external computer, that is not using batman-adv, to another computer that is not using batman-adv either? It is automatically listening on bat0 and will keep track of any host mac address passing by this interface. Those host's mac addresses will then be announced to other batman-adv nodes in the mesh network automatically - so called HNA messages - so that every batman-adv node is going to know behind which other batman-adv node it can find which mac addresses.)'' +_(How does batman-adv know where it has to send a data packet of an external computer, that is not using batman-adv, to another computer that is not using batman-adv either? It is automatically listening on bat0 and will keep track of any host mac address passing by this interface. Those host's mac addresses will then be announced to other batman-adv nodes in the mesh network automatically - so called HNA messages - so that every batman-adv node is going to know behind which other batman-adv node it can find which mac addresses.)_ -}}} +</code></pre>

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Wbmv4-batmandev-agenda (c5ee4e8f)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit c5ee4e8f454e0e42060ee7e5fd2dba90ed45f713 Author: Antonio Quartulli <a(a)unstable.cc> Date: Thu Mar 10 16:46:18 2011 +0000 doc: open-mesh/Wbmv4-batmandev-agenda >--------------------------------------------------------------- c5ee4e8f454e0e42060ee7e5fd2dba90ed45f713 open-mesh/Wbmv4-batmandev-agenda.textile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/open-mesh/Wbmv4-batmandev-agenda.textile b/open-mesh/Wbmv4-batmandev-agenda.textile index 8be68c31..b30467bd 100644 --- a/open-mesh/Wbmv4-batmandev-agenda.textile +++ b/open-mesh/Wbmv4-batmandev-agenda.textile @@ -16,5 +16,7 @@ Celebrate batman-adv 2.6.38 Linux kernel integration * NDP * Multicast patches * Hidden-Node-Bcast problem + * New HNA announcement mechanism == Coding == + * new HNA code could still need a bit of coding, in particular the lock/unlock mechanism has to be reviewed \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Wbmv4-batmandev-agenda (6cd45d54)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 6cd45d5439b90a35dd14f47b5e5a7ecc135e8947 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Fri Mar 4 03:15:00 2011 +0000 doc: open-mesh/Wbmv4-batmandev-agenda >--------------------------------------------------------------- 6cd45d5439b90a35dd14f47b5e5a7ecc135e8947 open-mesh/Wbmv4-batmandev-agenda.textile | 1 + 1 file changed, 1 insertion(+) diff --git a/open-mesh/Wbmv4-batmandev-agenda.textile b/open-mesh/Wbmv4-batmandev-agenda.textile index bd6f156a..8be68c31 100644 --- a/open-mesh/Wbmv4-batmandev-agenda.textile +++ b/open-mesh/Wbmv4-batmandev-agenda.textile @@ -10,6 +10,7 @@ Celebrate batman-adv 2.6.38 Linux kernel integration * Making fragmentation more generic, adding Fragmentation header/layer? * Reviewing OGM protocol specification proposal * reviewing the new papers related to B.A.T.M.A.N. (Simon brings printed versions) + * discuss switching to git == Testing == * NDP

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Wbmv4-batmandev-agenda (beaf3302)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Wbmv4-batmandev-agenda (c97252fe)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Experience (33af5146)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 33af5146dbc679184020aa4e2222162a9bef21cf Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Wed Mar 16 22:20:42 2011 +0000 doc: open-mesh/Experience >--------------------------------------------------------------- 33af5146dbc679184020aa4e2222162a9bef21cf open-mesh/Experience.textile | 43 +++++++++++++++++++++++-------------------- 1 file changed, 23 insertions(+), 20 deletions(-) diff --git a/open-mesh/Experience.textile b/open-mesh/Experience.textile index 42f8c185..edcdd060 100644 --- a/open-mesh/Experience.textile +++ b/open-mesh/Experience.textile @@ -1,27 +1,30 @@ -= Experience = -{{{ -#!div style="width: 40em; text-align: justify" +h1. Experience -This page aims to provide a collection of links towards press reviews & papers related to B.A.T.M.A.N. as well as projects using the B.A.T.M.A.N. protocol in real live scenarios. This collection only reflects a small percentage of the things out there because not everybody contacts us to share his experience. If you have made some experience or even setup a B.A.T.M.A.N. mesh network at someplace in this universe please feel urged to [wiki:MailingList tell us] or drop us a link! -__Projects:__ - * building mesh potatoes with B.A.T.M.A.N.: http://villagetelco.org - * powerful mesh nodes with batman-adv inside: http://www.saxnet.de - * B.A.T.M.A.N. with dashboard integration: http://www.open-mesh.com - * The Batphone (VOIP + Mesh on your device): http://www.servalproject.org +<pre> +<code class="div"> -__Press:__ - * [http://www.h-online.com/open/features/Kernel-Log-Coming-in-2-6-38-Part-3-Ne… Kernel Log: Network drivers and infrastructure], The H Open (February 2011) - * [http://lwn.net/Articles/426947/ Mesh networking with batman-adv], LWN.net (February 2011) - * [http://www.h-online.com/open/features/What-s-new-in-Linux-2-6-37-1163376.ht… Kernel Trends: Outlook on 2.6.38], The H Open (January 2011) - * [http://www.h-online.com/open/news/item/Kernel-Log-Coming-in-2-6-33-Part-5-D… Kernel Log: Coming in 2.6.33 - Drivers], The H Open (February 2010) - * [http://www.linuxjournal.com/magazine/mesh-potato The Mesh Potato], Linux Journal (December 2009) +This page aims to provide a collection of links towards press reviews & papers related to B.A.T.M.A.N. as well as projects using the B.A.T.M.A.N. protocol in real live scenarios. This collection only reflects a small percentage of the things out there because not everybody contacts us to share his experience. If you have made some experience or even setup a B.A.T.M.A.N. mesh network at someplace in this universe please feel urged to [[MailingList|tell us]] or drop us a link! -__Papers:__ ++Projects:+ +* building mesh potatoes with B.A.T.M.A.N.: http://villagetelco.org +* powerful mesh nodes with batman-adv inside: http://www.saxnet.de +* B.A.T.M.A.N. with dashboard integration: http://www.open-mesh.com +* The Batphone (VOIP + Mesh on your device): http://www.servalproject.org - * [http://wirelessafrica.meraka.org.za/wiki/images/9/98/Batman_ifip.pdf B.A.T.M.A.N. performance comparison paper] - * [http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1747&context=infopapers B.A.T.M.A.N. / BABEL / OLSR performance comparison] - * [http://users.ece.gatech.edu/~cortes/files/Wi-Me.pdf mesh performance analysis with B.A.T.M.A.N.] -}}} ++Press:+ +* "Linux 2.6.38 release notes":http://kernelnewbies.org/Linux_2_6_38#head-17577655766f585c3c47df886fe91dba276f4c3f, kernelnewbies.org (March 2011) +* "Kernel Log: Network drivers and infrastructure":http://www.h-online.com/open/features/Kernel-Log-Coming-in-2-6-38-Part-3-Network-drivers-and-infrastructure-1197480.html, The H Open (February 2011) +* "Mesh networking with batman-adv":http://lwn.net/Articles/426947/, LWN.net (February 2011) +* "Kernel Trends: Outlook on 2.6.38":http://www.h-online.com/open/features/What-s-new-in-Linux-2-6-37-1163376.html?page=6, The H Open (January 2011) +* "Kernel Log: Coming in 2.6.33 - Drivers":http://www.h-online.com/open/news/item/Kernel-Log-Coming-in-2-6-33-Part-5-Drivers-931993.html, The H Open (February 2010) +* "The Mesh Potato":http://www.linuxjournal.com/magazine/mesh-potato, Linux Journal (December 2009) + ++Papers:+ + +* "B.A.T.M.A.N. performance comparison paper":http://wirelessafrica.meraka.org.za/wiki/images/9/98/Batman_ifip.pdf +* "B.A.T.M.A.N. / BABEL / OLSR performance comparison":http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1747&context=infopapers +* "mesh performance analysis with B.A.T.M.A.N.":http://users.ece.gatech.edu/~cortes/files/Wi-Me.pdf +</code></pre>

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017