commits July 2020

commits@lists.open-mesh.org

1 participants
76 discussions

[doc] backup-redmine/2020-07-12,master: doc: alfred/announce_primary.dia (6acb86c)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit 6acb86c74acc1f2f4f80984c7f5670488f11c5e6 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 22:23:36 2020 +0000 doc: alfred/announce_primary.dia >--------------------------------------------------------------- 6acb86c74acc1f2f4f80984c7f5670488f11c5e6 .../{announce_master.dia => announce_primary.dia} | 89 ++++++++++++++-------- 1 file changed, 56 insertions(+), 33 deletions(-) diff --git a/alfred/announce_master.dia b/alfred/announce_primary.dia similarity index 88% copy from alfred/announce_master.dia copy to alfred/announce_primary.dia index ce1f6e9..c9fcdfe 100644 --- a/alfred/announce_master.dia +++ b/alfred/announce_primary.dia @@ -2,10 +2,10 @@ <dia:diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/"> <dia:diagramdata> <dia:attribute name="background"> - <dia:color val="#ffffff"/> + <dia:color val="#ffffffff"/> </dia:attribute> <dia:attribute name="pagebreak"> - <dia:color val="#000099"/> + <dia:color val="#000099ff"/> </dia:attribute> <dia:attribute name="paper"> <dia:composite type="paper"> @@ -37,6 +37,9 @@ </dia:attribute> <dia:attribute name="grid"> <dia:composite type="grid"> + <dia:attribute name="dynamic"> + <dia:boolean val="true"/> + </dia:attribute> <dia:attribute name="width_x"> <dia:real val="1"/> </dia:attribute> @@ -53,7 +56,7 @@ </dia:composite> </dia:attribute> <dia:attribute name="color"> - <dia:color val="#d8e5e5"/> + <dia:color val="#d8e5e5ff"/> </dia:attribute> <dia:attribute name="guides"> <dia:composite type="guides"> @@ -61,8 +64,27 @@ <dia:attribute name="vguides"/> </dia:composite> </dia:attribute> + <dia:attribute name="display"> + <dia:composite type="display"> + <dia:attribute name="antialiased"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="snap-to-grid"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="snap-to-object"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="show-grid"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="show-connection-points"> + <dia:boolean val="true"/> + </dia:attribute> + </dia:composite> + </dia:attribute> </dia:diagramdata> - <dia:layer name="Background" visible="true" active="true"> + <dia:layer name="Background" visible="true" connectable="true" active="true"> <dia:object type="Standard - Box" version="0" id="O0"> <dia:attribute name="obj_pos"> <dia:point val="20,13"/> @@ -83,7 +105,7 @@ <dia:real val="0.10000000149011612"/> </dia:attribute> <dia:attribute name="inner_color"> - <dia:color val="#90ee90"/> + <dia:color val="#90ee90ff"/> </dia:attribute> <dia:attribute name="show_background"> <dia:boolean val="true"/> @@ -94,13 +116,13 @@ <dia:point val="22,14.5"/> </dia:attribute> <dia:attribute name="obj_bb"> - <dia:rectangle val="20.6225,13.7275;23.3775,15.2725"/> + <dia:rectangle val="20.4975,13.6982;23.5212,15.3018"/> </dia:attribute> <dia:attribute name="text"> <dia:composite type="text"> <dia:attribute name="string"> <dia:string>#node 1 -(master)#</dia:string> +(primary)#</dia:string> </dia:attribute> <dia:attribute name="font"> <dia:font family="sans" style="0" name="Helvetica"/> @@ -109,10 +131,10 @@ <dia:real val="0.80000000000000004"/> </dia:attribute> <dia:attribute name="pos"> - <dia:point val="22,14.3225"/> + <dia:point val="22,14.3119"/> </dia:attribute> <dia:attribute name="color"> - <dia:color val="#000000"/> + <dia:color val="#000000ff"/> </dia:attribute> <dia:attribute name="alignment"> <dia:enum val="1"/> @@ -146,7 +168,7 @@ <dia:real val="0.10000000149011612"/> </dia:attribute> <dia:attribute name="inner_color"> - <dia:color val="#ffc780"/> + <dia:color val="#ffc780ff"/> </dia:attribute> <dia:attribute name="show_background"> <dia:boolean val="true"/> @@ -160,13 +182,13 @@ <dia:point val="22,21.5"/> </dia:attribute> <dia:attribute name="obj_bb"> - <dia:rectangle val="20.895,20.7275;23.105,22.2725"/> + <dia:rectangle val="20.09,20.6982;23.9287,22.3018"/> </dia:attribute> <dia:attribute name="text"> <dia:composite type="text"> <dia:attribute name="string"> <dia:string>#node 3 -(slave)#</dia:string> +(secondary)#</dia:string> </dia:attribute> <dia:attribute name="font"> <dia:font family="sans" style="0" name="Helvetica"/> @@ -175,10 +197,10 @@ <dia:real val="0.80000000000000004"/> </dia:attribute> <dia:attribute name="pos"> - <dia:point val="22,21.3225"/> + <dia:point val="22,21.3119"/> </dia:attribute> <dia:attribute name="color"> - <dia:color val="#000000"/> + <dia:color val="#000000ff"/> </dia:attribute> <dia:attribute name="alignment"> <dia:enum val="1"/> @@ -212,7 +234,7 @@ <dia:real val="0.10000000149011612"/> </dia:attribute> <dia:attribute name="inner_color"> - <dia:color val="#ffc780"/> + <dia:color val="#ffc780ff"/> </dia:attribute> <dia:attribute name="show_background"> <dia:boolean val="true"/> @@ -226,13 +248,13 @@ <dia:point val="16,21.5"/> </dia:attribute> <dia:attribute name="obj_bb"> - <dia:rectangle val="14.895,20.7275;17.105,22.2725"/> + <dia:rectangle val="14.09,20.6982;17.9287,22.3018"/> </dia:attribute> <dia:attribute name="text"> <dia:composite type="text"> <dia:attribute name="string"> <dia:string>#node 2 -(slave)#</dia:string> +(secondary)#</dia:string> </dia:attribute> <dia:attribute name="font"> <dia:font family="sans" style="0" name="Helvetica"/> @@ -241,10 +263,10 @@ <dia:real val="0.80000000000000004"/> </dia:attribute> <dia:attribute name="pos"> - <dia:point val="16,21.3225"/> + <dia:point val="16,21.3119"/> </dia:attribute> <dia:attribute name="color"> - <dia:color val="#000000"/> + <dia:color val="#000000ff"/> </dia:attribute> <dia:attribute name="alignment"> <dia:enum val="1"/> @@ -278,7 +300,7 @@ <dia:real val="0.10000000149011612"/> </dia:attribute> <dia:attribute name="inner_color"> - <dia:color val="#ffc780"/> + <dia:color val="#ffc780ff"/> </dia:attribute> <dia:attribute name="show_background"> <dia:boolean val="true"/> @@ -292,13 +314,13 @@ <dia:point val="28,21.5"/> </dia:attribute> <dia:attribute name="obj_bb"> - <dia:rectangle val="26.895,20.7275;29.105,22.2725"/> + <dia:rectangle val="26.09,20.6982;29.9287,22.3018"/> </dia:attribute> <dia:attribute name="text"> <dia:composite type="text"> <dia:attribute name="string"> <dia:string>#node 4 -(slave)#</dia:string> +(secondary)#</dia:string> </dia:attribute> <dia:attribute name="font"> <dia:font family="sans" style="0" name="Helvetica"/> @@ -307,10 +329,10 @@ <dia:real val="0.80000000000000004"/> </dia:attribute> <dia:attribute name="pos"> - <dia:point val="28,21.3225"/> + <dia:point val="28,21.3119"/> </dia:attribute> <dia:attribute name="color"> - <dia:color val="#000000"/> + <dia:color val="#000000ff"/> </dia:attribute> <dia:attribute name="alignment"> <dia:enum val="1"/> @@ -329,7 +351,7 @@ <dia:point val="22,16.0491"/> </dia:attribute> <dia:attribute name="obj_bb"> - <dia:rectangle val="15.6382,15.9991;22.05,20.0616"/> + <dia:rectangle val="15.6382,15.9991;22.05,19.9998"/> </dia:attribute> <dia:attribute name="orth_points"> <dia:point val="22,16.0491"/> @@ -367,7 +389,7 @@ <dia:point val="22,16.0491"/> </dia:attribute> <dia:attribute name="obj_bb"> - <dia:rectangle val="21.95,15.9991;28.3618,20.0616"/> + <dia:rectangle val="21.95,15.9991;28.3618,19.9998"/> </dia:attribute> <dia:attribute name="orth_points"> <dia:point val="22,16.0491"/> @@ -405,7 +427,7 @@ <dia:point val="22,16.0492"/> </dia:attribute> <dia:attribute name="obj_bb"> - <dia:rectangle val="21.6382,15.9992;22.3618,20.0626"/> + <dia:rectangle val="21.6382,15.9992;22.3618,20.0008"/> </dia:attribute> <dia:attribute name="conn_endpoints"> <dia:point val="22,16.0492"/> @@ -436,7 +458,7 @@ <dia:point val="23.05,17.3"/> </dia:attribute> <dia:attribute name="obj_bb"> - <dia:rectangle val="23.05,16.705;23.05,17.45"/> + <dia:rectangle val="23.05,16.705;23.05,17.4525"/> </dia:attribute> <dia:attribute name="text"> <dia:composite type="text"> @@ -453,7 +475,7 @@ <dia:point val="23.05,17.3"/> </dia:attribute> <dia:attribute name="color"> - <dia:color val="#000000"/> + <dia:color val="#000000ff"/> </dia:attribute> <dia:attribute name="alignment"> <dia:enum val="0"/> @@ -469,12 +491,13 @@ <dia:point val="23,17"/> </dia:attribute> <dia:attribute name="obj_bb"> - <dia:rectangle val="23,16.405;30.2125,17.95"/> + <dia:rectangle val="22.9813,16.3863;27.825,18.7899"/> </dia:attribute> <dia:attribute name="text"> <dia:composite type="text"> <dia:attribute name="string"> - <dia:string>#Master announcement + <dia:string>#Primary +announcement broadcast#</dia:string> </dia:attribute> <dia:attribute name="font"> @@ -487,7 +510,7 @@ broadcast#</dia:string> <dia:point val="23,17"/> </dia:attribute> <dia:attribute name="color"> - <dia:color val="#000000"/> + <dia:color val="#000000ff"/> </dia:attribute> <dia:attribute name="alignment"> <dia:enum val="0"/> @@ -518,7 +541,7 @@ broadcast#</dia:string> <dia:real val="0.10000000149011612"/> </dia:attribute> <dia:attribute name="inner_color"> - <dia:color val="#ff6e75"/> + <dia:color val="#ff6e75ff"/> </dia:attribute> </dia:object> </dia:layer>

1 0

[doc] backup-redmine/2020-07-12,master: doc: alfred/node_architecture_primary.png (c0da90c)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit c0da90ca620945380743aa745f01e6e8cf71d226 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 22:23:37 2020 +0000 doc: alfred/node_architecture_primary.png >--------------------------------------------------------------- c0da90ca620945380743aa745f01e6e8cf71d226 alfred/node_architecture_primary.png | Bin 0 -> 13339 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/alfred/node_architecture_primary.png b/alfred/node_architecture_primary.png new file mode 100644 index 0000000..ce0326c Binary files /dev/null and b/alfred/node_architecture_primary.png differ

1 0

[doc] backup-redmine/2020-07-12,master: doc: open-mesh/Experience (d70fe72)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit d70fe72bc231aa27e65a0c68bd9ab1533a701af0 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:40:10 2020 +0000 doc: open-mesh/Experience >--------------------------------------------------------------- d70fe72bc231aa27e65a0c68bd9ab1533a701af0 open-mesh/Experience.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/Experience.textile b/open-mesh/Experience.textile index 8fc8348..e7122da 100644 --- a/open-mesh/Experience.textile +++ b/open-mesh/Experience.textile @@ -1,6 +1,6 @@ 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 [[MailingList|tell us]] or drop us a link! +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 their 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! h2. Projects:

1 0

[doc] backup-redmine/2020-07-12,master: doc: open-mesh/Gsoc2010-ideas (db7b93d)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit db7b93d7ac119e6751f1ee4d6837bd1b1c2699e4 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:40:39 2020 +0000 doc: open-mesh/Gsoc2010-ideas >--------------------------------------------------------------- db7b93d7ac119e6751f1ee4d6837bd1b1c2699e4 open-mesh/Gsoc2010-ideas.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/Gsoc2010-ideas.textile b/open-mesh/Gsoc2010-ideas.textile index 6e121e9..635f8d5 100644 --- a/open-mesh/Gsoc2010-ideas.textile +++ b/open-mesh/Gsoc2010-ideas.textile @@ -46,7 +46,7 @@ h3. B.A.T.M.A.N. protocol convergence speed *Brief description:* Implement a fast changing environment detection algorithm to let mobile nodes adapt to their new surroundings faster. -Fast moving nodes always have the problem of adjusting their routing information in time. They can choose to send more routing information, so that their environment can adjust to them but stationary nodes won't do the same and increase the mobile node's adaption time greatly. However, when a B.A.T.M.A.N. node detects that his local environment changed quickly he will enter the starvation mode. In this mode the node will actively try to confirm a working route as fast as possible by sending a "batman ping" to its new neighbors. Each B.A.T.M.A.N. neighbor will try to forward the message to its destination, once arrived there it will travel back. If the mobile node receives the reply it can change its route towards the new neighbor without waiting for normal OGM flooding as the route has been verified. The goal of this project is to implement the starving mode together with the "batman ping". +Fast moving nodes always have the problem of adjusting their routing information in time. They can choose to send more routing information, so that their environment can adjust to them but stationary nodes won't do the same and increase the mobile node's adaption time greatly. However, when a B.A.T.M.A.N. node detects that its local environment changed quickly he will enter the starvation mode. In this mode the node will actively try to confirm a working route as fast as possible by sending a "batman ping" to its new neighbors. Each B.A.T.M.A.N. neighbor will try to forward the message to its destination, once arrived there it will travel back. If the mobile node receives the reply it can change its route towards the new neighbor without waiting for normal OGM flooding as the route has been verified. The goal of this project is to implement the starving mode together with the "batman ping". h3. Optimize multicast performance

1 0

[doc] backup-redmine/2020-07-12,master: doc: batman-adv/Troubleshooting (26edc7a)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit 26edc7a8e451115c6985a90eab11d7a56a61b198 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:42:44 2020 +0000 doc: batman-adv/Troubleshooting >--------------------------------------------------------------- 26edc7a8e451115c6985a90eab11d7a56a61b198 batman-adv/Troubleshooting.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Troubleshooting.textile b/batman-adv/Troubleshooting.textile index ba08691..79e7e02 100644 --- a/batman-adv/Troubleshooting.textile +++ b/batman-adv/Troubleshooting.textile @@ -40,7 +40,7 @@ Make sure, that they see each other with a reasonable TQ quality (i.e. > 200). B h3. Do all nodes run the same batman-adv version ? -If 'batctl o' does not show the neighbor you expect to see you should verify whether or not all nodes runt he same batman-adv version. Having the same version on all nodes is the safest way to be sure that the versions are compatible. A new release might change the compatibility number to avoid problems when incompatible versions run in the same mesh. Incompatible nodes will simply ignore each other. Consult our [[Compatversion|compatibility table]] to find out which release(s) carry which compatibility number. +If 'batctl o' does not show the neighbor you expect to see you should verify whether or not all nodes run the same batman-adv version. Having the same version on all nodes is the safest way to be sure that the versions are compatible. A new release might change the compatibility number to avoid problems when incompatible versions run in the same mesh. Incompatible nodes will simply ignore each other. Consult our [[Compatversion|compatibility table]] to find out which release(s) carry which compatibility number. h3. Are those tq-values rather stable or acting crazy?

1 0

[doc] backup-redmine/2020-07-12,master: doc: open-mesh/Gsoc2010-ideas (a1229e3)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit a1229e33c572deeb090d85b651e7f530d6189295 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:43:19 2020 +0000 doc: open-mesh/Gsoc2010-ideas >--------------------------------------------------------------- a1229e33c572deeb090d85b651e7f530d6189295 open-mesh/Gsoc2010-ideas.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/Gsoc2010-ideas.textile b/open-mesh/Gsoc2010-ideas.textile index 635f8d5..f27ed34 100644 --- a/open-mesh/Gsoc2010-ideas.textile +++ b/open-mesh/Gsoc2010-ideas.textile @@ -46,7 +46,7 @@ h3. B.A.T.M.A.N. protocol convergence speed *Brief description:* Implement a fast changing environment detection algorithm to let mobile nodes adapt to their new surroundings faster. -Fast moving nodes always have the problem of adjusting their routing information in time. They can choose to send more routing information, so that their environment can adjust to them but stationary nodes won't do the same and increase the mobile node's adaption time greatly. However, when a B.A.T.M.A.N. node detects that its local environment changed quickly he will enter the starvation mode. In this mode the node will actively try to confirm a working route as fast as possible by sending a "batman ping" to its new neighbors. Each B.A.T.M.A.N. neighbor will try to forward the message to its destination, once arrived there it will travel back. If the mobile node receives the reply it can change its route towards the new neighbor without waiting for normal OGM flooding as the route has been verified. The goal of this project is to implement the starving mode together with the "batman ping". +Fast moving nodes always have the problem of adjusting their routing information in time. They can choose to send more routing information, so that their environment can adjust to them but stationary nodes won't do the same and increase the mobile node's adaption time greatly. However, when a B.A.T.M.A.N. node detects that its local environment changed quickly, it will enter the starvation mode. In this mode the node will actively try to confirm a working route as fast as possible by sending a "batman ping" to its new neighbors. Each B.A.T.M.A.N. neighbor will try to forward the message to its destination, once arrived there it will travel back. If the mobile node receives the reply it can change its route towards the new neighbor without waiting for normal OGM flooding as the route has been verified. The goal of this project is to implement the starving mode together with the "batman ping". h3. Optimize multicast performance

1 0

[doc] backup-redmine/2020-07-12,master: doc: batman-adv/Client-roaming (618f2c7)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit 618f2c761d1401dc30cfd3ea7d696caaaf846e50 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:48:07 2020 +0000 doc: batman-adv/Client-roaming >--------------------------------------------------------------- 618f2c761d1401dc30cfd3ea7d696caaaf846e50 batman-adv/Client-roaming.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Client-roaming.textile b/batman-adv/Client-roaming.textile index 6ee4332..34d461a 100644 --- a/batman-adv/Client-roaming.textile +++ b/batman-adv/Client-roaming.textile @@ -12,7 +12,7 @@ To detect whether a recently detected non-mesh client is a roaming client or a n The roaming advertisement message is a unicast TVLV packet and its content is explained in the [[TVLV#Roaming-Advertisement-message|related TVLV section]]. -The information contained in this packet is used to update the old node's global table so that, in case of payload packet directed to him while the network is not in sync, with a payload destination equal to 'client address is redirected to 'source address'. +The information contained in this packet is used to update the old node's global table so that, in case of payload packet directed to it while the network is not in sync, with a payload destination equal to 'client address is redirected to 'source address'. Due to this mechanism, immediately after a roaming the data packets might follow a slightly sub-optimal path (data flow is going through the old node) until the network is in sync again and every node has updated its global translation table. This strategy will help to avoid losing packets that are still flowing to the old node.

1 0

[doc] backup-redmine/2020-07-12,master: doc: batman-adv/Throughput_meter (7e8d39d)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit 7e8d39dd28fabcec71d8afa84990252fc15cf782 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:38:58 2020 +0000 doc: batman-adv/Throughput_meter >--------------------------------------------------------------- 7e8d39dd28fabcec71d8afa84990252fc15cf782 batman-adv/Throughput_meter.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Throughput_meter.textile b/batman-adv/Throughput_meter.textile index 6a1308d..7c2591f 100644 --- a/batman-adv/Throughput_meter.textile +++ b/batman-adv/Throughput_meter.textile @@ -1,7 +1,7 @@ h1. Bandwidth meter This page is about a general overview of the Bandwith Meter tool in B.A.T.M.A.N.-Advanced. -This project was started by Edo Monticelli during his 2012 Google Summer Of Code and it is possible to read his final report [[open-mesh:2012-10-06-GSoC-2012-Edo-Monticellis-Final-Report|here]]. +This project was started by Edo Monticelli during the 2012 Google Summer Of Code and it is possible to read the final report [[open-mesh:2012-10-06-GSoC-2012-Edo-Monticellis-Final-Report|here]]. Since then, the project evolved a lot and the protocol used by it moved from a na��ve Go-Back-N to the more sophisticated TCP NewReno. More technical details are discussed on the [[bandwidth_meter_debug|technical page]].

1 0

[doc] backup-redmine/2020-07-12,master: doc: batman-adv/Faq (bfaeaa8)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit bfaeaa8146a459b15471f31b8f00ccc64b3f74f9 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:38:19 2020 +0000 doc: batman-adv/Faq >--------------------------------------------------------------- bfaeaa8146a459b15471f31b8f00ccc64b3f74f9 batman-adv/Faq.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Faq.textile b/batman-adv/Faq.textile index 5bc2fa9..b67c1a9 100644 --- a/batman-adv/Faq.textile +++ b/batman-adv/Faq.textile @@ -10,7 +10,7 @@ h2. B.A.T.M.A.N. General questions h3. Does B.A.T.M.A.N. have simulator (NS2, Omnet++, etc) support? -*Q:* Does B.A.T.M.A.N. have his own simulator? +*Q:* Does B.A.T.M.A.N. have its own simulator? *A:* At this point no, but B.A.T.M.A.N. implementation (we know of) supports simulators like the ones mentioned above. However, some people experiment with B.A.T.M.A.N. using emulators (UML/Qemu/etc). If you are looking for step-by-step instructions to install such a system you can [[open-mesh:Emulation Environment|read our emulation document]]. h3. How to make my mesh network secure ?

1 0

[doc] backup-redmine/2020-07-12,master: doc: batman-adv/BATMAN_IV (c220099)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit c220099cb0d255ddfdbe26f8f83ea168715b9ef9 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:38:04 2020 +0000 doc: batman-adv/BATMAN_IV >--------------------------------------------------------------- c220099cb0d255ddfdbe26f8f83ea168715b9ef9 batman-adv/BATMAN_IV.textile | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/batman-adv/BATMAN_IV.textile b/batman-adv/BATMAN_IV.textile index 0c4430b..f017dc3 100644 --- a/batman-adv/BATMAN_IV.textile +++ b/batman-adv/BATMAN_IV.textile @@ -4,11 +4,11 @@ B.A.T.M.A.N. is a proactive routing protocol for Wireless Ad-hoc Mesh Networ h2(#b.a.t.m.a.n.-iii-brief-overview). B.A.T.M.A.N. III (Brief Overview) -On a regular basis every B.A.T.M.A.N. node broadcasts an originator message (or OGM), thereby informing its link-local neighbors about its existence (first step). Link-local neighbors which are receiving the Originator messages are relaying them by rebroadcasting it, according to specific B.A.T.M.A.N. forwarding rules. The B.A.T.M.A.N. mesh network is therefore flooded with Originator messages. This flooding process will be performed by single-hop neighbors in the second step, by two-hop neighbors in the third step, and so forth. OGMs are send and repeated as UDP broadcasts, therefore OGMs are flooded until every node has received it at least once, or until they got lost due to packet loss of communication links, or until their TTL (time to live) value has expired. In practise OGM packet loss caused by interference, collision or congestion is significant. The number of OGMs received from a given Originator via each link-local neighbor is used to estimate the qual ity of a (single-hop or multi-hop) route. In order to be able to find the best route to a certain originator, B.A.T.M.A.N counts the originator-messages received and logs which link-local neighbor relayed the message. Using this information B.A.T.M.A.N. maintains a table with the best link-local router towards every originator on the network. Unlike wired networks, WiFi setups often face the problem of asymetric links (Node A has a better connection towards Node B than vice versa). To ensure that the detected connections allow communication in both directions each B.A.T.M.A.N. node awaits rebroadcasts of its own OGMs from his neighbors within a certain timeframe (bidirectional link check). If the OGMs are not successfully retransmitted the connection is considered too asymetric (unusable) and therefore ignored. +On a regular basis every B.A.T.M.A.N. node broadcasts an originator message (or OGM), thereby informing its link-local neighbors about its existence (first step). Link-local neighbors which are receiving the Originator messages are relaying them by rebroadcasting it, according to specific B.A.T.M.A.N. forwarding rules. The B.A.T.M.A.N. mesh network is therefore flooded with Originator messages. This flooding process will be performed by single-hop neighbors in the second step, by two-hop neighbors in the third step, and so forth. OGMs are send and repeated as UDP broadcasts, therefore OGMs are flooded until every node has received it at least once, or until they got lost due to packet loss of communication links, or until their TTL (time to live) value has expired. In practise OGM packet loss caused by interference, collision or congestion is significant. The number of OGMs received from a given Originator via each link-local neighbor is used to estimate the qual ity of a (single-hop or multi-hop) route. In order to be able to find the best route to a certain originator, B.A.T.M.A.N counts the originator-messages received and logs which link-local neighbor relayed the message. Using this information B.A.T.M.A.N. maintains a table with the best link-local router towards every originator on the network. Unlike wired networks, WiFi setups often face the problem of asymetric links (Node A has a better connection towards Node B than vice versa). To ensure that the detected connections allow communication in both directions each B.A.T.M.A.N. node awaits rebroadcasts of its own OGMs from its neighbors within a certain timeframe (bidirectional link check). If the OGMs are not successfully retransmitted the connection is considered too asymetric (unusable) and therefore ignored. h1(#b.a.t.m.a.n.-iv-tq). B.A.T.M.A.N. IV (TQ) -The B.A.T.M.A.N. III algorithm has serious problems when it comes to asymetric links. The bidirectional link check tries to limit its impact but the result is far from being perfect. The timeframe in which B.A.T.M.A.N. accepts his own OGMs being rebroadcasted by its neighbor allows to tweak the behaviour. If this timeframe is rather short B.A.T.M.A.N. is very strict on choosing links. This may lead to many ignored links which might be usable in one direction. Only symetric connections will be considered. If the timeframe value is less strict B.A.T.M.A.N. will accept more links but tends to route in the wrong direction. +The B.A.T.M.A.N. III algorithm has serious problems when it comes to asymetric links. The bidirectional link check tries to limit its impact but the result is far from being perfect. The timeframe in which B.A.T.M.A.N. accepts its own OGMs being rebroadcasted by its neighbor allows to tweak the behaviour. If this timeframe is rather short B.A.T.M.A.N. is very strict on choosing links. This may lead to many ignored links which might be usable in one direction. Only symetric connections will be considered. If the timeframe value is less strict B.A.T.M.A.N. will accept more links but tends to route in the wrong direction. Example: OGMs from Node A propagate to B. The link is asymetric, therefore B receives all packets from A in contrast to A which receives almost nothing from B. As all the packets from A get to B the packet count at B's side goes up. B will assume that it has a perfect link towards A which is not the case. @@ -36,7 +36,7 @@ As explained in the previous section the packet counting floods the network with * B.A.T.M.A.N. knows the receiving link quality (RQ) by counting the packets of its neighbors. !rq.png(Receive Quality (RQ))! -* B.A.T.M.A.N. knows the echo link quality (EQ) by counting rebroadcasts of its own OGMs from his neighbors. +* B.A.T.M.A.N. knows the echo link quality (EQ) by counting rebroadcasts of its own OGMs from its neighbors. !eq_alt1.png(Echo Link Quality (EQ))! * B.A.T.M.A.N. can calculate the transmit link quality (TQ) by dividing the echo link quality by the receiving link quality. !tq.png(Transmit Link Quality (TQ))! @@ -89,7 +89,7 @@ The global TQ is an average of all received TQ values from one originator via a h2(#handling-asymetric-links). Handling Asymetric Links -Although the transmit link quality is most important decision factor B.A.T.M.A.N. IV also keeps track of the receiving link quality. On the WiFi layer every unicast packet has to be acknowledged by the neighbor node to approve the transmission. If this neighbor is not able to sucessfully send his ACKs the WiFi layer considers this transmission to be failed and tries to retransmit until it gives up. +Although the transmit link quality is most important decision factor B.A.T.M.A.N. IV also keeps track of the receiving link quality. On the WiFi layer every unicast packet has to be acknowledged by the neighbor node to approve the transmission. If this neighbor is not able to sucessfully send its ACKs the WiFi layer considers this transmission to be failed and tries to retransmit until it gives up. !asym_link1.png(Asymetry situation without asymetry penalty)! @@ -117,7 +117,7 @@ Example: 3 nodes (A, B and C) in a row (A can hear B but not C). Node A emits an !echo_cancel1.png(communication without echo cancellation)! -To detect echos (messages that already passed through a node) B.A.T.M.A.N. IV introduces a new protocol field called "previous sender" which contains the IP address of the node rebroadcasting the OGM. Whenever a node receives a message from a neighbor it will fill the "previous sender" field with the address of the sending neighbor before rebroadcasting it. If a node detects his own IP address in the "previous sender" field the packet will be ignored. +To detect echos (messages that already passed through a node) B.A.T.M.A.N. IV introduces a new protocol field called "previous sender" which contains the IP address of the node rebroadcasting the OGM. Whenever a node receives a message from a neighbor it will fill the "previous sender" field with the address of the sending neighbor before rebroadcasting it. If a node detects its own IP address in the "previous sender" field the packet will be ignored. Back to the example: Node B will ignore (drop) the packet coming back from node C as node C wrote the IP address of node B in the "previous sender" field.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2020