[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Faq (1a53391)
by postmaster＠open-mesh.org
Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2019-09-17,master
>---------------------------------------------------------------
commit 1a5339113c7d106aed91db555217e1739daeb234
Author: Sven Eckelmann <sven(a)narfation.org>
Date: Tue Sep 17 10:23:22 2019 +0000
doc: batman-adv/Faq
>---------------------------------------------------------------
1a5339113c7d106aed91db555217e1739daeb234
batman-adv/Faq.textile | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/batman-adv/Faq.textile b/batman-adv/Faq.textile
index 5713865..fcd5507 100644
--- a/batman-adv/Faq.textile
+++ b/batman-adv/Faq.textile
@@ -58,7 +58,7 @@ h3. Can batman-adv run on interfaces in AP / Station / etc mode ?
h3. How can I connect non-mesh clients to my batman-adv network ?
*Q:* How can I connect non-mesh clients to batman-adv network?
-*A: * The [[batman-adv:Quick-start-guide|batman-adv quick-start-guide]] explains how to bridge your standard AP / Ethernet interfaces with bat0 which can be problematic if you only possess one WiFi card. In these cases it might be desirable to run adhoc mode and AP mode at the same time. Fortunately, some WiFi chips / drivers support a so-called "multi VAP" (virtual AP) or "multi SSID" mode to have multiple WiFi networks on the same WiFi interface.
+*A:* The [[batman-adv:Quick-start-guide|batman-adv quick-start-guide]] explains how to bridge your standard AP / Ethernet interfaces with bat0 which can be problematic if you only possess one WiFi card. In these cases it might be desirable to run adhoc mode and AP mode at the same time. Fortunately, some WiFi chips / drivers support a so-called "multi VAP" (virtual AP) or "multi SSID" mode to have multiple WiFi networks on the same WiFi interface.
h3. How big networks does batman-adv support?
@@ -94,10 +94,10 @@ h3. Logs not received via trace-cmd?
*Q:* The trace-cmd shows now log messages for batman-adv?
*A:* You need to compile the batman-adv with logging support.
- * Linux tree
- ** go to *<code>Networking support ---> Networking options ---> B.A.T.M.A.N. Advanced Meshing Protocol</code>* and select *<code>B.A.T.M.A.N. debugging</code>* and *<code>B.A.T.M.A.N. tracing support</code>*
- * external module
- ** compile with make parameter *<code>CONFIG_BATMAN_ADV_DEBUG=y CONFIG_BATMAN_ADV_TRACING=y</code>*
+* Linux tree
+** go to *<code>Networking support ---> Networking options ---> B.A.T.M.A.N. Advanced Meshing Protocol</code>* and select *<code>B.A.T.M.A.N. debugging</code>* and *<code>B.A.T.M.A.N. tracing support</code>*
+* external module
+** compile with make parameter *<code>CONFIG_BATMAN_ADV_DEBUG=y CONFIG_BATMAN_ADV_TRACING=y</code>*
batctl must also be used to set the relevant loglevel
2 years, 9 months
[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Broadcast-Avoidances (ce3c07d)
by postmaster＠open-mesh.org
Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2019-09-17,master
>---------------------------------------------------------------
commit ce3c07daf0e2d0479b48a91a38d02f458c02e4ce
Author: Sven Eckelmann <sven(a)narfation.org>
Date: Tue Sep 17 10:22:51 2019 +0000
doc: batman-adv/Broadcast-Avoidances
>---------------------------------------------------------------
ce3c07daf0e2d0479b48a91a38d02f458c02e4ce
batman-adv/Broadcast-Avoidances.textile | 31 +++++++++++++++----------------
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/batman-adv/Broadcast-Avoidances.textile b/batman-adv/Broadcast-Avoidances.textile
index 2b2f12b..7e31d7e 100644
--- a/batman-adv/Broadcast-Avoidances.textile
+++ b/batman-adv/Broadcast-Avoidances.textile
@@ -97,15 +97,14 @@ h3. Concept
h3. Neighborhood Hash TVLV Format
- * Packet type: 0x03 (BATADV_ELP)
- * TVLV type: 0x01 (BATADV_TVLV_NHH)
- * Length: 68 bytes
- * Fixed TVLV fields:
- ** minimum throughput: the worst of all TX throughputs to any neighbor a node sees on the according interface (4 bytes)
- ** maximum throughput: the best of all TX throughputs to any neighbor a node sees on the according interface (4 bytes)
- ** neighorhood hash: a sha512 hash summarizing all neighbors a node sees on the according interface; hash created from neighbor addresses sorted alphabetically, concatenated, binary (64 bytes)
-
- * Definition:
+* Packet type: 0x03 (BATADV_ELP)
+* TVLV type: 0x01 (BATADV_TVLV_NHH)
+* Length: 68 bytes
+* Fixed TVLV fields:
+** minimum throughput: the worst of all TX throughputs to any neighbor a node sees on the according interface (4 bytes)
+** maximum throughput: the best of all TX throughputs to any neighbor a node sees on the according interface (4 bytes)
+** neighorhood hash: a sha512 hash summarizing all neighbors a node sees on the according interface; hash created from neighbor addresses sorted alphabetically, concatenated, binary (64 bytes)
+* Definition:
<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
@@ -142,8 +141,8 @@ _Egress Check:_
If either (or both):
- * The best TX throughput of the neighbor we received the broadcast packet from with our forwarding penalty applied is smaller than the worst TX throughput of this neighbor (_ingress check_).
- * Our best TX throughput with our forwarding penalty applied is smaller than the worst TX throughput of the neighbor we received the broadcast packet from (_egress check_).
+* The best TX throughput of the neighbor we received the broadcast packet from with our forwarding penalty applied is smaller than the worst TX throughput of this neighbor (_ingress check_).
+* Our best TX throughput with our forwarding penalty applied is smaller than the worst TX throughput of the neighbor we received the broadcast packet from (_egress check_).
Then a rebroadcast can be avoided.
@@ -165,21 +164,21 @@ _Egress Check:_
If either (or both):
- * The TX throughput to the neighbor we received the OGM2 packet from with our forwarding penalty applied is smaller than the worst TX throughput of all our neighbors (_ingress check_).
- * The best TX throughput of all our neighbors with our forwarding penalty applied is smaller than the worst TX throughput of all our neighbors (_egress check_).
+* The TX throughput to the neighbor we received the OGM2 packet from with our forwarding penalty applied is smaller than the worst TX throughput of all our neighbors (_ingress check_).
+* The best TX throughput of all our neighbors with our forwarding penalty applied is smaller than the worst TX throughput of all our neighbors (_egress check_).
Then a rebroadcast can be avoided.
h4. Further readings:
- * [[Broadcast-Avoidances-NHH-Assessment|Broadcast Avoidances - Neighborhood Hash Assessment]]
+* [[Broadcast-Avoidances-NHH-Assessment|Broadcast Avoidances - Neighborhood Hash Assessment]]
h2. Appendix
h3. Limitations
- * Many avoidance possibilities undetected in wireless scenarios (see "Future improvements" below or assessment page)
- * In wired cases with a mix of 100MBit/s and 1000MBit/s interfaces: Only avoids broadcast packet rebroadcasts, not OGM2 rebroadcasts
+* Many avoidance possibilities undetected in wireless scenarios (see "Future improvements" below or assessment page)
+* In wired cases with a mix of 100MBit/s and 1000MBit/s interfaces: Only avoids broadcast packet rebroadcasts, not OGM2 rebroadcasts
h3. Future Improvements
2 years, 9 months
[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Bridge-loop-avoidance-Testcases (958fb93)
by postmaster＠open-mesh.org
Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2019-09-17,master
>---------------------------------------------------------------
commit 958fb93cec9009b6f31048f289acad42c947e257
Author: Sven Eckelmann <sven(a)narfation.org>
Date: Tue Sep 17 10:21:48 2019 +0000
doc: batman-adv/Bridge-loop-avoidance-Testcases
>---------------------------------------------------------------
958fb93cec9009b6f31048f289acad42c947e257
batman-adv/Bridge-loop-avoidance-Testcases.textile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/batman-adv/Bridge-loop-avoidance-Testcases.textile b/batman-adv/Bridge-loop-avoidance-Testcases.textile
index 8d01f6d..2edc8fb 100644
--- a/batman-adv/Bridge-loop-avoidance-Testcases.textile
+++ b/batman-adv/Bridge-loop-avoidance-Testcases.textile
@@ -33,8 +33,8 @@ h3. Limited Horizon tests
In this test, the first node A can't reach the last one C due to a limited horizon (the OGMs of A don't reach the OGMs of C and vice versa).
- * Test 1: Client 1 and Client 2 should be able to ping the internet gateway. There are are no bridge loops.
- * Test 2: Client 1 and Client 2 should be able to ping each other.
+* Test 1: Client 1 and Client 2 should be able to ping the internet gateway. There are are no bridge loops.
+* Test 2: Client 1 and Client 2 should be able to ping each other.
+note1+: Test 2 will only work if BATMAN runs over the backbone, e.g. by calling "batctl if add br0".
+note2+: Limited horizon may be easily simulated by increasing the hop_penalty, e.g. "batctl meshif bat0 hop_penalty 230" will have a 3 hop range in a network without packet loss.
2 years, 9 months
[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Broadcast-Avoidances-NHH-Assessment (136f795)
by postmaster＠open-mesh.org
Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2019-09-17,master
>---------------------------------------------------------------
commit 136f795e074d9b3f32d90cbc95dbdf9ed0125e59
Author: Sven Eckelmann <sven(a)narfation.org>
Date: Tue Sep 17 10:22:21 2019 +0000
doc: batman-adv/Broadcast-Avoidances-NHH-Assessment
>---------------------------------------------------------------
136f795e074d9b3f32d90cbc95dbdf9ed0125e59
.../Broadcast-Avoidances-NHH-Assessment.textile | 42 +++++++++++-----------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/batman-adv/Broadcast-Avoidances-NHH-Assessment.textile b/batman-adv/Broadcast-Avoidances-NHH-Assessment.textile
index 529a595..d948596 100644
--- a/batman-adv/Broadcast-Avoidances-NHH-Assessment.textile
+++ b/batman-adv/Broadcast-Avoidances-NHH-Assessment.textile
@@ -105,9 +105,9 @@ h3. Simplification
Instead of performing all the checks described above, the modified rules are used in the implementation with the following goals:
- * Less information to exchange
- * Less computational overhead
- * Supposed to work even with large neighborhoods
+* Less information to exchange
+* Less computational overhead
+* Supposed to work even with large neighborhoods
Performing the checks stated above has the following disadvantages: For one thing, the computational overhead could be significant for neighborhoods of a certain size. For another, B does not even know the throughput from A to B or A to C (or C to A or C to B - we will see later why we might need those). B only knows its own TX throughput towards other neighbors and not the other way around.
@@ -125,13 +125,13 @@ h4. Proof: Ingress TX (bcast)
We want to proof:
- * p(Amax) < Amin => p(AB) < ACn for any Cn.
+* p(Amax) < Amin => p(AB) < ACn for any Cn.
One has:
- * a ≤ b => p(a) ≤ p(b)
- * AB ≤ Amax
- * Amin ≤ ACn
+* a ≤ b => p(a) ≤ p(b)
+* AB ≤ Amax
+* Amin ≤ ACn
<pre>
AB ≤ Amax
@@ -148,13 +148,13 @@ h4. Proof: Egress TX (bcast)
We want to proof:
- * p(Bmax) < Amin => p(BCn) < ACn
+* p(Bmax) < Amin => p(BCn) < ACn
One has:
- * a ≤ b => p(a) ≤ p(b)
- * BCn ≤ Bmax
- * Amin ≤ ACn
+* a ≤ b => p(a) ≤ p(b)
+* BCn ≤ Bmax
+* Amin ≤ ACn
<pre>
BCn ≤ Bmax
@@ -171,12 +171,12 @@ h4. Proof: Ingress RX (OGM2)
We want to proof:
- * p(AB) < MIN<code></code>(Amin, Cn-min) => p(AB) < CnA for any Cn.
+* p(AB) < MIN<code></code>(Amin, Cn-min) => p(AB) < CnA for any Cn.
One has:
- * MIN<code></code>(a, b) ≤ b
- * Cn-min ≤ CnA
+* MIN<code></code>(a, b) ≤ b
+* Cn-min ≤ CnA
<pre>
p(AB) < MIN(Amin, Cn-min)
@@ -190,15 +190,15 @@ h4. Proof: Egress RX (OGM2)
We want to proof:
- * p(MAX<code></code>(Amax, Cn-max)) < MIN<code></code>(Amin, Cn-min) => p(AB) < CnA for any Cn.
+* p(MAX<code></code>(Amax, Cn-max)) < MIN<code></code>(Amin, Cn-min) => p(AB) < CnA for any Cn.
One has:
- * a ≤ b => p(a) ≤ p(b)
- * MIN<code></code>(a, b) ≤ b
- * a ≤ MAX<code></code>(a, b)
- * AB ≤ Amax
- * Cn-min ≤ CnA
+* a ≤ b => p(a) ≤ p(b)
+* MIN<code></code>(a, b) ≤ b
+* a ≤ MAX<code></code>(a, b)
+* AB ≤ Amax
+* Cn-min ≤ CnA
<pre>
Amax ≤ MAX(Amax, Cn-max)
@@ -222,4 +222,4 @@ This number of inputs would be reached if over 500 years a new neighborhood were
See also:
- * https://en.wikipedia.org/wiki/Birthday_attack
\ No newline at end of file
+* https://en.wikipedia.org/wiki/Birthday_attack
\ No newline at end of file
2 years, 9 months
[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Bridge-loop-avoidance-Protocol (3f1e068)
by postmaster＠open-mesh.org
Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2019-09-17,master
>---------------------------------------------------------------
commit 3f1e0686a7e4b249eeb38f2ac4e1ae89edb2d625
Author: Sven Eckelmann <sven(a)narfation.org>
Date: Tue Sep 17 10:21:33 2019 +0000
doc: batman-adv/Bridge-loop-avoidance-Protocol
>---------------------------------------------------------------
3f1e0686a7e4b249eeb38f2ac4e1ae89edb2d625
batman-adv/Bridge-loop-avoidance-Protocol.textile | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/batman-adv/Bridge-loop-avoidance-Protocol.textile b/batman-adv/Bridge-loop-avoidance-Protocol.textile
index 0612f02..28c678b 100644
--- a/batman-adv/Bridge-loop-avoidance-Protocol.textile
+++ b/batman-adv/Bridge-loop-avoidance-Protocol.textile
@@ -2,9 +2,9 @@ h1. Bridge loop avoidance protocol description
Further pages on this topic:
- * [[Bridge-loop-avoidance-Testcases]] Test case descriptions
- * [[Bridge-loop-avoidance-II]] Technical description
- * [[Bridge-loop-avoidance]] User howto
+* [[Bridge-loop-avoidance-Testcases]] Test case descriptions
+* [[Bridge-loop-avoidance-II]] Technical description
+* [[Bridge-loop-avoidance]] User howto
h2. Claim frames
@@ -12,10 +12,10 @@ h2. Claim frames
All claim operations are sent using "special" gratuitous ARP frames. 4 types are used which are illustrated above:
- * CLAIM frames are used to tell others that a backbone gateway feels responsible for a client now
- * UNCLAIM frames are sent when a backbone gateway does not feel responsible anymore
- * ANNOUNCE frames are sent regularly to find other backbone gateways and provides the CRC of its local table
- * REQUEST frames are used to ask for a full table update when the information is out of sync (i.e. the announced CRC does not match with the local CRC)
+* CLAIM frames are used to tell others that a backbone gateway feels responsible for a client now
+* UNCLAIM frames are sent when a backbone gateway does not feel responsible anymore
+* ANNOUNCE frames are sent regularly to find other backbone gateways and provides the CRC of its local table
+* REQUEST frames are used to ask for a full table update when the information is out of sync (i.e. the announced CRC does not match with the local CRC)
The claim type is announced within the 4th byte of the Target HW address.
@@ -125,9 +125,9 @@ h3. ANNOUNCE frames
The periodic ANNOUNCE frames (default: every 10 seconds) by the backbone gateways serve the following purposes:
- * backbone gateways learn about the existence of other backbone gateways (this is important for new gateways)
- * when no ANNOUNCE frames are received anymore, we can assume that this backbone gateway is no longer serving the backbone and can remove its claims
- * It contains a checksum (the last 2 bytes YY:YY within the Sender HW address) which other backbone gateways can use to check their table consistency. If a table is not consistent, a backbone gateway can ask for the full claim table via the REQUEST frame.
+* backbone gateways learn about the existence of other backbone gateways (this is important for new gateways)
+* when no ANNOUNCE frames are received anymore, we can assume that this backbone gateway is no longer serving the backbone and can remove its claims
+* It contains a checksum (the last 2 bytes YY:YY within the Sender HW address) which other backbone gateways can use to check their table consistency. If a table is not consistent, a backbone gateway can ask for the full claim table via the REQUEST frame.
Note: the SRC HW address is a "locally administered address" group address which should not be used by any NIC or protocol, but is not registered with the IEEE
2 years, 9 months
[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Bridge-loop-avoidance-II (b950701)
by postmaster＠open-mesh.org
Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2019-09-17,master
>---------------------------------------------------------------
commit b950701a598e45b5bb8119dc9f24338a4d10e4d1
Author: Sven Eckelmann <sven(a)narfation.org>
Date: Tue Sep 17 10:21:12 2019 +0000
doc: batman-adv/Bridge-loop-avoidance-II
>---------------------------------------------------------------
b950701a598e45b5bb8119dc9f24338a4d10e4d1
batman-adv/Bridge-loop-avoidance-II.textile | 46 ++++++++++++++---------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/batman-adv/Bridge-loop-avoidance-II.textile b/batman-adv/Bridge-loop-avoidance-II.textile
index 62832f2..7328056 100644
--- a/batman-adv/Bridge-loop-avoidance-II.textile
+++ b/batman-adv/Bridge-loop-avoidance-II.textile
@@ -2,9 +2,9 @@ h1. Bridge loop avoidance II
Further pages on this topic:
- * [[Bridge-loop-avoidance-Testcases|Bridge loop avoidance test case descriptions]]
- * [[Bridge-loop-avoidance-Protocol|Bridge loop avoidance protocol description]]
- * [[Bridge-loop-avoidance|Bridge loop avoidance user howto]]
+* [[Bridge-loop-avoidance-Testcases|Bridge loop avoidance test case descriptions]]
+* [[Bridge-loop-avoidance-Protocol|Bridge loop avoidance protocol description]]
+* [[Bridge-loop-avoidance|Bridge loop avoidance user howto]]
h2. Situation
@@ -15,16 +15,16 @@ This is the example we will use to discuss the concept: multiple mesh nodes (cal
h2. Definitions:
- * backbone gateway: A mesh node which is connected to both - a mesh network and a backbone (e.g. LAN).
- * client: A non-mesh network participant which is sending data via the mesh. The client is always identified by the source MAC address of the payload Ethernet header.
- * Originator: An originator is a mesh participant in batman. If we talk about the originator address in this document, we mean the hardware address of the primary interface.
+* backbone gateway: A mesh node which is connected to both - a mesh network and a backbone (e.g. LAN).
+* client: A non-mesh network participant which is sending data via the mesh. The client is always identified by the source MAC address of the payload Ethernet header.
+* Originator: An originator is a mesh participant in batman. If we talk about the originator address in this document, we mean the hardware address of the primary interface.
h2. Goals:
- * The bridge loop avoidance should be able to scale to hundreds of gateways connected to the same backbone.
- * Communication between the mesh nodes and the backbone should be via the best backbone gateway.
- * Minimize broadcast traffic in the backbone.
- * Roaming should still be possible.
+* The bridge loop avoidance should be able to scale to hundreds of gateways connected to the same backbone.
+* Communication between the mesh nodes and the backbone should be via the best backbone gateway.
+* Minimize broadcast traffic in the backbone.
+* Roaming should still be possible.
h2. Key Concepts:
@@ -32,8 +32,8 @@ h3. Claiming clients:
Only one backbone gateway (out of possibly many gateways) should forward traffic from a non-mesh client (coming via the mesh) to the backbone. Every backbone gateway announces the mac addresses of the non-mesh clients it feels responsible for in the form of "claim frames" on the soft-interface bat0. Each backbone gateway will save a claim list of other backbone gateways. By doing this, it can:
- * see which clients are already tracked (claimed)
- * see which other backbone gateways exist in the backbone
+* see which clients are already tracked (claimed)
+* see which other backbone gateways exist in the backbone
Note that backbone gateways may overwrite a claim of another backbone gateway by simply claiming the same client. In this case, the newest claim wins, and local databases are updated accordingly.
@@ -68,8 +68,8 @@ h3. Broadcast, backbone->mesh:
If a claim for the mesh-client exists:
- * all not responsible backbone gateways should discard the frame - this might be a loop.
- * if the responsible backbone gateway (which claimed this client) also receives the packet, "unclaim" this client by sending an according un-claim packet, and forward the packet into the mesh. This should only happen in the roaming case, but not in normal situations.
+* all not responsible backbone gateways should discard the frame - this might be a loop.
+* if the responsible backbone gateway (which claimed this client) also receives the packet, "unclaim" this client by sending an according un-claim packet, and forward the packet into the mesh. This should only happen in the roaming case, but not in normal situations.
If the client is not claimed, all backbone gateways will send the broadcast into the mesh. The mesh nodes will avoid duplicates by using the duplicate lists (see section below)
@@ -125,8 +125,8 @@ To do this, we use a "mesh duplicate list": This list is kept for every backbone
If the client is not claimed by any backbone gateway, every backbone gateway shall forward the packet into the mesh. This will lead to duplicates of the broadcast with different meta information (different originators, different sequence numbers). To avoid duplicates within the mesh, every mesh node will use the "mesh duplicate list":
- * after the (old) seqno window check: match the frame to the "mesh duplicate list" of other backbone gateways to see if another backbone gateway from the same backbone has sent a broadcast with the same payload checksum.
- * if true, drop the packet. Otherwise, add the checksum to the entries and re-forward it.
+* after the (old) seqno window check: match the frame to the "mesh duplicate list" of other backbone gateways to see if another backbone gateway from the same backbone has sent a broadcast with the same payload checksum.
+* if true, drop the packet. Otherwise, add the checksum to the entries and re-forward it.
@@ -134,15 +134,15 @@ h2. Discussion:
h3. Features:
- * no single "super" gateway => should scale better
- * the only additional BATMAN backbone packets are claim packets, which are only sent for new claims and regular announcements
- * no BATMAN packets on the backbone
- * broadcasts are sent from all the gateways into the mesh
- * nodes can select gateways, and change among them (gateways will automatically re-claiming)
- * should not loop ;)
+* no single "super" gateway => should scale better
+* the only additional BATMAN backbone packets are claim packets, which are only sent for new claims and regular announcements
+* no BATMAN packets on the backbone
+* broadcasts are sent from all the gateways into the mesh
+* nodes can select gateways, and change among them (gateways will automatically re-claiming)
+* should not loop ;)
h3. Limitations:
- * loops in higher-level structures may not be avoided. For example, if there are two meshes and two backbones are interconnected as in the illustration below, a loop is formed which can't be detected, since the claim frames of one mesh won't travel along the mesh network of the other.
+* loops in higher-level structures may not be avoided. For example, if there are two meshes and two backbones are interconnected as in the illustration below, a loop is formed which can't be detected, since the claim frames of one mesh won't travel along the mesh network of the other.
!2mesh2lan.png!
\ No newline at end of file
2 years, 9 months
[doc] backup-redmine/2019-09-17, master: doc: batman-adv/BATMAN_V (8e76e0e)
by postmaster＠open-mesh.org
Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2019-09-17,master
>---------------------------------------------------------------
commit 8e76e0e8ba47b9b1df34944c546a35bf07cbbdc2
Author: Sven Eckelmann <sven(a)narfation.org>
Date: Tue Sep 17 10:20:14 2019 +0000
doc: batman-adv/BATMAN_V
>---------------------------------------------------------------
8e76e0e8ba47b9b1df34944c546a35bf07cbbdc2
batman-adv/BATMAN_V.textile | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/batman-adv/BATMAN_V.textile b/batman-adv/BATMAN_V.textile
index 6563868..3dbf7f3 100644
--- a/batman-adv/BATMAN_V.textile
+++ b/batman-adv/BATMAN_V.textile
@@ -18,9 +18,9 @@ B.A.T.M.A.N. V adopts the strategy of 'divide & conquer' to handle these differe
The task separation (neighbor discovery vs mesh routing) bears the following advantages:
- * Reduced overhead, as OGMs can then be sent with a slower interval. The OGM propagation has a squared amount of overhead in worst case scenarios, therefore the the slower intervals are very desirable.
- * Neighbor discovery and metric data collection can be performed individually, at different intervals or even different techniques.
- * Effort for multiple interface handling can be reduced.
+* Reduced overhead, as OGMs can then be sent with a slower interval. The OGM propagation has a squared amount of overhead in worst case scenarios, therefore the the slower intervals are very desirable.
+* Neighbor discovery and metric data collection can be performed individually, at different intervals or even different techniques.
+* Effort for multiple interface handling can be reduced.
h2. Throughput based metric
@@ -47,6 +47,6 @@ This allows different compatibility strategies:
h2. Technical documentation:
- * neighbor discovery: [[ELP|Echo Location Protocol (ELP)]]
- * path metric computation: [[Ogmv2|Originator Message version 2 (OGMv2)]]
- * routing tests: [[BATMAN_V_Tests|B.A.T.M.A.N. IV vs B.A.T.M.A.N. V]]
\ No newline at end of file
+* neighbor discovery: [[ELP|Echo Location Protocol (ELP)]]
+* path metric computation: [[Ogmv2|Originator Message version 2 (OGMv2)]]
+* routing tests: [[BATMAN_V_Tests|B.A.T.M.A.N. IV vs B.A.T.M.A.N. V]]
\ No newline at end of file
2 years, 9 months
[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Batman-adv-openwrt-config (d43991c)
by postmaster＠open-mesh.org
Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2019-09-17,master
>---------------------------------------------------------------
commit d43991cecb34aa24440ce59a26882e876ef8520a
Author: Sven Eckelmann <sven(a)narfation.org>
Date: Tue Sep 17 10:20:38 2019 +0000
doc: batman-adv/Batman-adv-openwrt-config
>---------------------------------------------------------------
d43991cecb34aa24440ce59a26882e876ef8520a
batman-adv/Batman-adv-openwrt-config.textile | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/batman-adv/Batman-adv-openwrt-config.textile b/batman-adv/Batman-adv-openwrt-config.textile
index c5fd735..9e935b5 100644
--- a/batman-adv/Batman-adv-openwrt-config.textile
+++ b/batman-adv/Batman-adv-openwrt-config.textile
@@ -145,12 +145,12 @@ config wifi-iface 'wmesh'
It is assumed you configured the 'wifi-device' depending on your requirements and your hardware. The interesting part is the 'wifi-iface' stanza with its options:
- * 'device' points back to your radio (wifi-device) interface
- * 'ifname' allows you to specify an arbitrary name for your adhoc interface (which we are going to re-use later)
- * 'network' points to the corresponding stanza in '/etc/config/network'
- * 'mode' defines the wifi mode (adhoc in our case)
- * 'mcast_rate' helps to avoid low bandwidth routes (routes with a lower throughput rate than the mcast rate will not be visible to batman-adv)
- * 'ssid' and 'bssid' are basic wireless settings you might want to set to your liking
+* 'device' points back to your radio (wifi-device) interface
+* 'ifname' allows you to specify an arbitrary name for your adhoc interface (which we are going to re-use later)
+* 'network' points to the corresponding stanza in '/etc/config/network'
+* 'mode' defines the wifi mode (adhoc in our case)
+* 'mcast_rate' helps to avoid low bandwidth routes (routes with a lower throughput rate than the mcast rate will not be visible to batman-adv)
+* 'ssid' and 'bssid' are basic wireless settings you might want to set to your liking
More information can be found in the "OpenWrt wireless configuration":https://wiki.openwrt.org/doc/uci/wireless
@@ -219,12 +219,12 @@ config wifi-iface 'wmesh'
It is assumed you configured the 'wifi-device' depending on your requirements and your hardware. The interesting part is the 'wifi-iface' stanza with its options:
- * 'device' points back to your radio (wifi-device) interface
- * 'ifname' allows you to specify an arbitrary name for your adhoc interface (which we are going to re-use later)
- * 'network' points to the corresponding stanza in '/etc/config/network'
- * 'mode' defines the wifi mode (adhoc in our case)
- * 'mcast_rate' helps to avoid low bandwidth routes (routes with a lower throughput rate than the mcast rate will not be visible to batman-adv)
- * 'ssid' and 'bssid' are basic wireless settings you might want to set to your liking
+* 'device' points back to your radio (wifi-device) interface
+* 'ifname' allows you to specify an arbitrary name for your adhoc interface (which we are going to re-use later)
+* 'network' points to the corresponding stanza in '/etc/config/network'
+* 'mode' defines the wifi mode (adhoc in our case)
+* 'mcast_rate' helps to avoid low bandwidth routes (routes with a lower throughput rate than the mcast rate will not be visible to batman-adv)
+* 'ssid' and 'bssid' are basic wireless settings you might want to set to your liking
More information can be found in the "OpenWrt wireless configuration":https://wiki.openwrt.org/doc/uci/wireless
2 years, 9 months
[doc] backup-redmine/2019-09-17, master: doc: alfred/Gettingstarted (f9b85f9)
by postmaster＠open-mesh.org
Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2019-09-17,master
>---------------------------------------------------------------
commit f9b85f9e725adc8523089df847cfd204bcbf39f3
Author: Sven Eckelmann <sven(a)narfation.org>
Date: Tue Sep 17 10:19:41 2019 +0000
doc: alfred/Gettingstarted
>---------------------------------------------------------------
f9b85f9e725adc8523089df847cfd204bcbf39f3
alfred/Gettingstarted.textile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/alfred/Gettingstarted.textile b/alfred/Gettingstarted.textile
index 7465132..ca821ea 100644
--- a/alfred/Gettingstarted.textile
+++ b/alfred/Gettingstarted.textile
@@ -1,5 +1,5 @@
h2. Getting started
- * [[Building information]] - how to download and build alfred
- * [[batadv-vis]] - Tool to visualize batman-adv networks
- * [[alfred-gpsd]] - Share geolocation of mesh nodes
\ No newline at end of file
+* [[Building information]] - how to download and build alfred
+* [[batadv-vis]] - Tool to visualize batman-adv networks
+* [[alfred-gpsd]] - Share geolocation of mesh nodes
\ No newline at end of file
2 years, 9 months
[doc] backup-redmine/2019-09-17, master: doc: alfred/Developerinformation (24ee441)
by postmaster＠open-mesh.org
Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2019-09-17,master
>---------------------------------------------------------------
commit 24ee441fef3642e68cf4b536fd1d0e4972faab0d
Author: Sven Eckelmann <sven(a)narfation.org>
Date: Tue Sep 17 10:19:28 2019 +0000
doc: alfred/Developerinformation
>---------------------------------------------------------------
24ee441fef3642e68cf4b536fd1d0e4972faab0d
alfred/Developerinformation.textile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/alfred/Developerinformation.textile b/alfred/Developerinformation.textile
index b0252fb..65daaf6 100644
--- a/alfred/Developerinformation.textile
+++ b/alfred/Developerinformation.textile
@@ -1,3 +1,3 @@
h2. Developer information
- * [[Alfred architecture]] - information about topologies, internal architecture and packet format
\ No newline at end of file
+* [[Alfred architecture]] - information about topologies, internal architecture and packet format
\ No newline at end of file
2 years, 9 months