commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Building-with-openwrt (c419e543)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Troubleshooting: first version of batman-adv troubleshooting guide (eb01d908)
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 eb01d9085bec3ed5288a03ba2c0d7f176bdcf4da Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Wed Mar 31 16:55:27 2010 +0000 doc: batman-adv/Troubleshooting: first version of batman-adv troubleshooting guide >--------------------------------------------------------------- eb01d9085bec3ed5288a03ba2c0d7f176bdcf4da batman-adv/Troubleshooting.textile | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/batman-adv/Troubleshooting.textile b/batman-adv/Troubleshooting.textile new file mode 100644 index 00000000..00607ae5 --- /dev/null +++ b/batman-adv/Troubleshooting.textile @@ -0,0 +1,30 @@ += B.A.T.M.A.N.-Adv Troubleshooting = +''B.A.T.M.A.N.-Adv does net work as expected, what can I do now?'' + +First, try to minimise the complexity of your setup, i.e. just try to build a simple mesh network between two devices. Usually just following the [wiki/batman-adv-quick-start-guide quick-start-guide] is a good way to start with. + +If you still can't get any setup working at all, go through this checklist: + +=== Any warnings or errors in the kernel log? === +Check 'dmesg' for warnings, errors or crashes. + +=== Are both nodes having the same cell id? === +Check with 'iwconfig'. Some wifi drivers are a little buggy and do not always merge two ad-hoc cells, therefore you're usually best advised to chose and configure one manually (i.e. 'iwconfig wlan0 ap 02:XX:XX:XX:XX:XX'). If configuring a cell-id manually, you should set the 7th bit of the first byte - or start it with "02:" in other words. To keep this id (mostly) unique, using one of the routers mac-address for the rest is usually the safest way to go. + +=== Is 'batctl if' showing the used interfaces as active? === +If batman-adv is saying "[inactive]" for one of the mesh-port interfaces, make sure this one is up (i.e. 'ifconfig wlan0 up') + +=== Is 'batctl o' showing the other node? === +Make sure, that they see each other with a reasonable TQ quality (i.e. > 200). Be aware, that a full TQ update in a dynamic environment but still with the default ogm-interval setting can be delayed for up to 64 seconds. If they are not seeing each other, check your wifi settings twice, try ad-hoc meshing without batman-adv or any bridges first to make sure, that the ad-hoc wifi layer itself works fine and allows any kinds of packets (ad-hoc mode is usually not the best implemented and well tested wifi mode in a lot of wifi drivers). + +=== Are those tq-values rather stable or acting crazy? === +If they are acting crazy, check if the mesh-port interfaces used by batman-adv all have a different mac addresses. Otherwise this could break the routing algoritm in some scenarios. + +=== Does a ping to the other node via the mesh work? === +Set static ipv4-addresses (or (autoconfigured) ipv6 addresses) not being used on any other interfaces on bat0 and check if those two nodes can ping each other. If this works, but large pings do not (i.e. ping -s 1700), then check the MTU settings. All mesh hosts need an MTU of 24 Bytes less (i.e. on bat0 or any host bridged into the mesh) than on their mesh-port interfaces' MTU (the interfaces you've added via 'batctl if'). For instance you could chose to increase the MTU on all mesh-port interfaces to 1524 (or decrease it on all hosts, bat0 or any host interface being bridged into the mesh, to 1476 which is usually harder to maintain when having 'foreign' hosts). + +=== Does 'batctl ping' to the other node work? === +If you can see the other node but can't send any packets through the mesh network, check whether you can ping it with batman-adv's internal echoing packets (see 'batctl ping -h' for usage info). If this works, check your layer 3 settings, in general your routes and IP adresses - don't use the same routes/addresses on different interfaces, don't set any ip-addresses on the mesh-port interfaces. Just use bat0 or the bridge you might have created on top of it. + +=== Are the wifi/lan LEDs blinking like crazy? === +Make sure you DONT bridge any mesh-port-interfaces with your bat0 interface! \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Building-with-openwrt: adding "the easy way", removing divs for verbatims (otherwise I'd have a grey line on half of my screen) (29971940)
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 299719407e1c74394b5caeb8879196f8791be22b Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Wed Mar 31 15:37:47 2010 +0000 doc: batman-adv/Building-with-openwrt: adding "the easy way", removing divs for verbatims (otherwise I'd have a grey line on half of my screen) >--------------------------------------------------------------- 299719407e1c74394b5caeb8879196f8791be22b batman-adv/Building-with-openwrt.textile | 32 ++++++-------------------------- 1 file changed, 6 insertions(+), 26 deletions(-) diff --git a/batman-adv/Building-with-openwrt.textile b/batman-adv/Building-with-openwrt.textile index 310f8db1..7b546473 100644 --- a/batman-adv/Building-with-openwrt.textile +++ b/batman-adv/Building-with-openwrt.textile @@ -2,46 +2,34 @@ = Building B.A.T.M.A.N. Advanced on OpenWRT = {{{ -#!div style="width: 40em; text-align: justify" +#!div style="width: 46em; text-align: justify" Many tutorials assume that you have batman-adv running on an OpenWRT system without going into detail how to get the system built and configured. This documents aims to fill the gap by providing a step-by-step explanation how to get your OpenWRT system up & running. === Getting the OpenWRT build environment === First, you need to obtain a copy of the OpenWRT build system which contains all the build information to compile & package a complete linux system. You can either checkout the last stable or the trunk directly from the OpenWRT SVN repository or get tarballs from the OpenWRT project website. We assume you intend to download the latest stable (8.09.2 at the point of writing this document) via SVN: -}}} {{{ svn co svn://svn.openwrt.org/openwrt/tags/8.09.2 openwrt-kamikaze }}} -{{{ -#!div style="width: 40em; text-align: justify" - Change into the openwrt-kamikaze directory and configure the system to meet you needs (e.g. choose the platform and additional packages you intend to use). -}}} {{{ cd openwrt-kamikaze make menuconfig }}} -{{{ -#!div style="width: 40em; text-align: justify" - __Note__: The batman-adv package is not there yet because it needs to be activated seperately (see the following steps). [[BR]] To build your images you always have to invoke the "make" command from within the openwrt-kamikaze folder: -}}} {{{ cd openwrt-kamikaze make }}} -{{{ -#!div style="width: 40em; text-align: justify" - The rest of the document will focus on the batman-adv package. It is assumed that you configured the system to work on your platform. If you require additional information on how to tweak your OpenWRT system, please see [http://www.openwrt.org the OpenWRT project website]. === Adding the batman-adv package === @@ -54,43 +42,35 @@ Downloading and adding all packages might clutter your OpenWRT package menu with __The easy way__: [[BR]] -TBD +{{{ +scripts/feeds update +scripts/feeds install kmod-batman-adv-kernelland +}}} +''Note'': If you want to build a current version of batman-adv, make sure you have ''"svn-src packages !svn://svn.openwrt.org/openwrt/packages"'' in your feeds.conf(.default) __The manual way__: [[BR]] Download the OpenWRT package repository via SVN next to your openwrt-kamikaze folder (not inside!): -}}} {{{ svn co svn://svn.openwrt.org/openwrt/packages openwrt-packages }}} -{{{ -#!div style="width: 40em; text-align: justify" - The batman-adv package can be found in the "net" subfolder of the package repository. Now, it needs to be linked into your main package folder, so that OpenWRT can find it: -}}} {{{ cd openwrt-kamikaze/package ln -sf ../../openwrt-packages/net/batman-advanced/ . }}} -{{{ -#!div style="width: 40em; text-align: justify" - === Configuring the batman-adv package === As soon as the batman-adv package has been added, it will show up in the OpenWRT package menu: -}}} {{{ Kernel modules ---> Network Support ---> kmod-batman-adv-kernelland }}} -{{{ -#!div style="width: 40em; text-align: justify" - Once the package had been selected a number of suboptions will become visible. The branch option decides whether OpenWRT should build the latest stable batman-adv release or the bleeding edge development version. You also can enable/disable the verbose debug logging as well as choose whether or not to include the batctl tool. In addition, the batman-adv package comes with an init script which is installed per default. This script will run at boot time and can be used to configure your desired batman-adv options. It reads the batman-adv-kernelland uci file to retrieve the settings which allows to specify interfaces, intervals, log level and more.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Building-with-openwrt (d904dea9)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Building-with-openwrt (d04ba5fb)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Troubleshooting: adding sentence about writing a ticket and reference to openwrt-article (and enabling kernel symbol tables) (0984752b)
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 0984752b177f093f6710e69eb3b78bc449965690 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Wed Mar 31 17:33:12 2010 +0000 doc: batman-adv/Troubleshooting: adding sentence about writing a ticket and reference to openwrt-article (and enabling kernel symbol tables) >--------------------------------------------------------------- 0984752b177f093f6710e69eb3b78bc449965690 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 00607ae5..1a995b2c 100644 --- a/batman-adv/Troubleshooting.textile +++ b/batman-adv/Troubleshooting.textile @@ -6,7 +6,7 @@ First, try to minimise the complexity of your setup, i.e. just try to build a si If you still can't get any setup working at all, go through this checklist: === Any warnings or errors in the kernel log? === -Check 'dmesg' for warnings, errors or crashes. +Check 'dmesg' for warnings, errors or crashes. If you are seeing a crash, write a [/report ticket] and post the log their, describe your setup and hardware, and ideally how this crash could be reproduced. If the kernel log is just showing cryptic numbers and you are building the kernel(-module) yourself (i.e. OpenWRT distro with [/wiki/building-batman-adv-with-openwrt this] article), enable kernel symbol table please (see its advanced section for enabling this)! === Are both nodes having the same cell id? === Check with 'iwconfig'. Some wifi drivers are a little buggy and do not always merge two ad-hoc cells, therefore you're usually best advised to chose and configure one manually (i.e. 'iwconfig wlan0 ap 02:XX:XX:XX:XX:XX'). If configuring a cell-id manually, you should set the 7th bit of the first byte - or start it with "02:" in other words. To keep this id (mostly) unique, using one of the routers mac-address for the rest is usually the safest way to go.

1 0

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

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/The-olsr-story (8d8445bd)
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 8d8445bdc1cd66731f86c3b18b6d05c3a0a9ccb1 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Mon Mar 29 10:12:06 2010 +0000 doc: open-mesh/The-olsr-story >--------------------------------------------------------------- 8d8445bdc1cd66731f86c3b18b6d05c3a0a9ccb1 open-mesh/The-olsr-story.textile | 151 ++++++++++++++++++++++----------------- 1 file changed, 86 insertions(+), 65 deletions(-) diff --git a/open-mesh/The-olsr-story.textile b/open-mesh/The-olsr-story.textile index 693ccd75..0cb12de2 100644 --- a/open-mesh/The-olsr-story.textile +++ b/open-mesh/The-olsr-story.textile @@ -1,14 +1,16 @@ -= The OLSR.ORG story = -{{{ -#!div style="width: 40em; text-align: justify" +h1. The OLSR.ORG story + + +<pre> +<code class="div"> Proactive protocols (Link State Routing Protocols) generate a lot of overhead because they have to keep topoloy information and routing tables in sync amongst all or at least amongst adjacent nodes. If the protocol does not manage to keep the routing tables synced it is likely -that the payload will spin in routing loops until the !TimeToLive (TTL) +that the payload will spin in routing loops until the TimeToLive (TTL) is expired. Apart from high traffic-overhead and CPU-Load this is the biggest issue for Link State Routing Protocols. We were actively involved in the evolution of olsrd from olsr.org. Actually we were the @@ -23,36 +25,40 @@ that the inital designers of olsr thought was smart and replaced it with the LQ/ETX-Mechanism and Fish-Eye Mechanism tp update topology information. -What we did to improve olsr (in historical order): [[BR]] +What we did to improve olsr (in historical order): + -''Test OLSR according to RFC3626 at the conference Wizards of OS III in 2004 - Meshcloud with 25 Nodes'' +_Test OLSR according to RFC3626 at the conference Wizards of OS III in 2004 - Meshcloud with 25 Nodes_ -Results: [[BR]] - * Routing tables take long time to build and no time to break down. - * Routes flap. - * Routing loops. - * No throughput. - * Gateway switches all the time - so stateful connections to the Internet +Results: + +* Routing tables take long time to build and no time to break down. +* Routes flap. +* Routing loops. +* No throughput. +* Gateway switches all the time - so stateful connections to the Internet will brake down all the time -Conclusion: [[BR]] - * Hysteresis mechanism frequently kicks Multi Point Relays (MPRs) out of +Conclusion: + +* Hysteresis mechanism frequently kicks Multi Point Relays (MPRs) out of the routing table --> Infrastructure to broadcast topology information breaks down all the time and MPRs have to be negotiated again... - * Multipoint relay selection selects nodes far away to keep the number of +* Multipoint relay selection selects nodes far away to keep the number of necessary Multi Point Relays low --> Links to MPRs are weak, so hysteresis kicks them out of the routing table more often than not Multipoint relay selection reduces protocol overhead and prevents topology information from being in sync --> Routing loops - * Routes are unstable --> No throughput - * Routes selected on minimum Hop-count maximises packetloss --> No throughput - * Routing loops --> No throughput - * Dynamic gateway selection --> Stateful connections get interrupted when +* Routes are unstable --> No throughput +* Routes selected on minimum Hop-count maximises packetloss --> No throughput +* Routing loops --> No throughput +* Dynamic gateway selection --> Stateful connections get interrupted when a different gateway is selected -What we did: [[BR]] - * Disable hysteresis. - * Disable MPRs - all nodes forward topology information. +What we did: + +* Disable hysteresis. +* Disable MPRs - all nodes forward topology information. Now almost everything that was meant to optimize Link State Routing was disabled - a simple proactive link-state routing protocol with support @@ -67,19 +73,22 @@ configuration file that is shipped with olsr.org, olsrd will still behave according to RFC3626. So if you want to see how miserable RFC3626 works - try it with the default configuration file. -[[BR]] -''Deployment of OLSR (with 'Optimizations' removed) in the Berlin Freifunk mesh cloud - 2004'' -Results: [[BR]] - * Works much better than RFC3626. Still it was hardly usable. - * Throughput very low and unstable. - * Routing table doesn't break down anymore - * Dynamic gateway selection --> Stateful connections get interrupted when a different gateway is selected + +_Deployment of OLSR (with 'Optimizations' removed) in the Berlin Freifunk mesh cloud - 2004_ + +Results: + +* Works much better than RFC3626. Still it was hardly usable. +* Throughput very low and unstable. +* Routing table doesn't break down anymore +* Dynamic gateway selection --> Stateful connections get interrupted when a different gateway is selected -Conclusion: [[BR]] - * We knew routes based on minimum hopcount will likely have very low throughput. - * Dynamic gateway selection is a tradeoff of automatic gateway selection by the protocol +Conclusion: + +* We knew routes based on minimum hopcount will likely have very low throughput. +* Dynamic gateway selection is a tradeoff of automatic gateway selection by the protocol I knew from my first experience with Mobilemesh (another Link State Routing Protocol that we tried at the very beginning of the Freifunk @@ -104,20 +113,23 @@ a big barrel of beer at the c-base to celebrate the moment :) There was one tradeoff, however. We had to break compatibility with RFC3626. But since RFC3626 wasn't usable in real-life we didn't bother much. -[[BR]] -''Deployment of olsr-0.4.8 in the Freifunk-Mesh with ETX/LQ-Mechanism'' -Results: [[BR]] - * Probably bugs in the huge amount of new program-code - * Good routing decisions on wireless links operating at the same speed as long as the network is idle - * Throughput improved - but throughput is interrupted by routing loops as soon as heavy network load is introduced - * Payload runs for a while at high speed, then the traffic is interrupted, comes back after a while at slow speed - caused by routing loops - * Dynamic gateway selection --> Stateful connections get interrupted when a different gateway is selected +_Deployment of olsr-0.4.8 in the Freifunk-Mesh with ETX/LQ-Mechanism_ + +Results: + -Conclusion: [[BR]] - * This was a mayor improvement, but... +* Probably bugs in the huge amount of new program-code +* Good routing decisions on wireless links operating at the same speed as long as the network is idle +* Throughput improved - but throughput is interrupted by routing loops as soon as heavy network load is introduced +* Payload runs for a while at high speed, then the traffic is interrupted, comes back after a while at slow speed - caused by routing loops +* Dynamic gateway selection --> Stateful connections get interrupted when a different gateway is selected + +Conclusion: + +* This was a mayor improvement, but... Payload traffic in the mesh causes interference and alters LQ/ETX-Values - interference causes lost LQ-Messages, so LQ/ETX-Values in topology @@ -166,41 +178,47 @@ neighbours, etc. TC messages with small TTLs are sent more frequently than TC messages with higher TTLs, such that immediate neighbours are more up to date with respect to our links than the rest of the mesh. The following -sequence of TTL values is used by olsrd: [[BR]] +sequence of TTL values is used by olsrd: + -255 3 2 1 2 1 1 3 2 1 2 1 1 [[BR]] +255 3 2 1 2 1 1 3 2 1 2 1 1 -Hence, a TC interval of 0.5 seconds leads to the following TC broadcast scheme. [[BR]] - * Out of 13 TC messages, all 13 are seen by one-hop neighbours (TTL 1, 2, 3, or 255), i.e. a one-hop neighbour sees a TC message every 0.5 seconds. - * Two-hop neighbours (TTL 2, 3, or 255) see 7 out of 13 TC messages, i.e. about one message per 0.9 seconds. - * Three-hop neighbours (TTL 3 or 255) see 3 out of 13 TC messages, i.e. about one message per 2.2 seconds. - * All other nodes in the mesh (TTL 255) see 1 out of 13 TC messages, i.e. one message per 6.5 seconds. + +Hence, a TC interval of 0.5 seconds leads to the following TC broadcast scheme. + +* Out of 13 TC messages, all 13 are seen by one-hop neighbours (TTL 1, 2, 3, or 255), i.e. a one-hop neighbour sees a TC message every 0.5 seconds. +* Two-hop neighbours (TTL 2, 3, or 255) see 7 out of 13 TC messages, i.e. about one message per 0.9 seconds. +* Three-hop neighbours (TTL 3 or 255) see 3 out of 13 TC messages, i.e. about one message per 2.2 seconds. +* All other nodes in the mesh (TTL 255) see 1 out of 13 TC messages, i.e. one message per 6.5 seconds. The sequence of TTL values is hard-coded in lq_packet.c and can be altered easily for further experiments. The implementation of Link Quality Fish Eye mechanism took Thomas only a few minutes - and it was the second major improvement. -Thomas also introduced a new switch, called !LinkQualityDjikstraLimit. +Thomas also introduced a new switch, called LinkQualityDjikstraLimit. The slow CPUs of embedded routers have serious problems to recalculate the routing tables in a mesh-cloud with more than 100 nodes. Every incoming TC-Message would trigger another recalculation of the -Djikstra-Table - this would be far too often. !LinkQualityDjikstraLimit +Djikstra-Table - this would be far too often. LinkQualityDjikstraLimit allows to set an interval for recalculating the Djikstra-Table. -[[BR]] -''Deployment of olsr-0.4.10'' + + +_Deployment of olsr-0.4.10_ -Results: [[BR]] - * Now it is really working and usable :) - * It's still not absolutely loop-free under heavy payload (sometimes loops for 3-10 seconds) - * Multihop-Links with 10 Hops work and are stable as long as the wireless links work - * !LinkQualityDjikstraLimit allows to run olsr even on a relatively slow CPU in a big mesh-cloud - but the routing-table becomes very very static - * Gateway-Switching is still a constant annoyance if a mesh has more than one Internet-Gateway +Results: + +* Now it is really working and usable :) +* It's still not absolutely loop-free under heavy payload (sometimes loops for 3-10 seconds) +* Multihop-Links with 10 Hops work and are stable as long as the wireless links work +* LinkQualityDjikstraLimit allows to run olsr even on a relatively slow CPU in a big mesh-cloud - but the routing-table becomes very very static +* Gateway-Switching is still a constant annoyance if a mesh has more than one Internet-Gateway + +Conclusions: -Conclusions: [[BR]] - * Apart from the problems with Gateway-Switching it is now a well behaving routing protocol. +* Apart from the problems with Gateway-Switching it is now a well behaving routing protocol. But still... Thomas and I agreed that we could cope with the increasing size of the Freifunk networks only by making the protocol more and more @@ -241,10 +259,13 @@ We both lost interest in Olsr development in spring 2006 and Thomas implemented a quick and dirty version of Batman-I in one night to see if the new algorithm was viable. It is - but that's a whole different story... -Written by Elektra and published at www.open-mesh.org [[BR]] +Written by Elektra and published at www.open-mesh.org + + +Copyleft: + +(CC) Creative Commons Attribution-Noncommercial-Share Alike 3.0 -Copyleft: [[BR]] -(CC) Creative Commons Attribution-Noncommercial-Share Alike 3.0 [[BR]] -}}} +</code></pre>

1 0

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

14 Jul '17

1 0

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

14 Jul '17

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017