commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Gateways (b853d885)
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 b853d8851ff7d28437ce8205977a72e00b9d706e Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Tue Nov 9 16:15:19 2010 +0000 doc: batman-adv/Gateways >--------------------------------------------------------------- b853d8851ff7d28437ce8205977a72e00b9d706e batman-adv/Gateways.textile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/batman-adv/Gateways.textile b/batman-adv/Gateways.textile index c6970212..75b95ac2 100644 --- a/batman-adv/Gateways.textile +++ b/batman-adv/Gateways.textile @@ -18,10 +18,12 @@ As the whole gateway functionality is based on DHCP, the protocol assumes each g Which gateway will be selected by the client depends on the number of DHCP servers / packet loss / delay / DHCP client software / etc. -Once the gateway feature has been activated batman-adv floods the networks with gateway information, so that each batman-adv knows all other gateways (including the link quality). A batman-adv gateway client will choose its gateway (based on user defined criteria) long before DHCP is started. As soon as a DHCP request from a client comes in batman-adv will not broadcast the packet but only send it to the chosen batman-adv gateway. The DHCP client will then select the gateway batman-adv prefers as only this gateway replied to the request. +Once the gateway feature has been activated batman-adv floods the networks with gateway information, so that each batman-adv knows all other gateways (including the link quality). A batman-adv gateway client will choose its gateway (based on user defined criteria) long before DHCP is started. As soon as a DHCP request from a client comes in batman-adv will not broadcast the packet but only send it to the chosen batman-adv gateway. [[Image(wiki:batman-adv-gateways:gateway2.png)]] +The DHCP client will then select the gateway batman-adv prefers as only this gateway replied to the request. + === The configuration ===

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Gateways: -1 char, +1 char (dcc54e6c)
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 dcc54e6cbc2a7ce91d96f1e8ea0e0130cb2fb789 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Thu Nov 11 22:05:16 2010 +0000 doc: batman-adv/Gateways: -1 char, +1 char >--------------------------------------------------------------- dcc54e6cbc2a7ce91d96f1e8ea0e0130cb2fb789 batman-adv/Gateways.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Gateways.textile b/batman-adv/Gateways.textile index 7787478a..8c362e6b 100644 --- a/batman-adv/Gateways.textile +++ b/batman-adv/Gateways.textile @@ -7,7 +7,7 @@ Often batman-adv is used to cover a bigger area with wireless access to the inte === The default route === -The subject of manipulating the IP (layer 3) default route with a layer 2 routing protocol has stirred up controversy between those who believe in a clean network layer separation and those who need this functionality. The former claim that a well-designed protocol should not mess with other layers but instead collaborates with tools made for higher layers. The later group has pointed out that the rule of network layer separation can be bent in real world applications and to improve usability. To achieve a compromise the gateway mechanism is disabled per default and only operates on top of DHCP (details below). Feel free to contact us in case you want to propose alternative ideas. +The subject of manipulating the IP (layer 3) default route with a layer 2 routing protocol has stirred up controversy between those who believe in a clean network layer separation and those who need this functionality. The former claim that a well-designed protocol should not mess with other layers but instead collaborate with tools made for higher layers. The latter group has pointed out that the rule of network layer separation can be bent in real world applications and to improve usability. To achieve a compromise the gateway mechanism is disabled per default and only operates on top of DHCP (details below). Feel free to contact us in case you want to propose alternative ideas. === The concept ===

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Emulation (b75c4b2d)
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 b75c4b2df08f6c77792d87652f0501ce6fdd63a5 Author: Sven Eckelmann <sven(a)narfation.org> Date: Fri Nov 19 21:00:36 2010 +0000 doc: open-mesh/Emulation >--------------------------------------------------------------- b75c4b2df08f6c77792d87652f0501ce6fdd63a5 open-mesh/Emulation.textile | 91 +++++++++++++++++++++++++-------------------- 1 file changed, 50 insertions(+), 41 deletions(-) diff --git a/open-mesh/Emulation.textile b/open-mesh/Emulation.textile index 552be563..1ce2aaf3 100644 --- a/open-mesh/Emulation.textile +++ b/open-mesh/Emulation.textile @@ -1,28 +1,34 @@ [[PageOutline]] -= Emulation Setup = -As a lot of people discussed about simulating mesh network protocols at [http://hackerspace.be/Wbm2009v2/ WBMv2], i'd like to share my qemu setup which i used to gather some data for batman-adv. The idea is to use [http://www.qemu.org/ QEMU] or [http://user-mode-linux.sourceforge.net/ UML] (instead of frameworks like they exist for [http://www.isi.edu/nsnam/ns/ NS-2]) to run an unmodified linux system with the unmodified source code. Besides BATMAN, you could evaluate any routing protocol. +h1. Emulation Setup + + +As a lot of people discussed about simulating mesh network protocols at "WBMv2":http://hackerspace.be/Wbm2009v2/, i'd like to share my qemu setup which i used to gather some data for batman-adv. The idea is to use "QEMU":http://www.qemu.org/ or "UML":http://user-mode-linux.sourceforge.net/ (instead of frameworks like they exist for "NS-2":http://www.isi.edu/nsnam/ns/) to run an unmodified linux system with the unmodified source code. Besides BATMAN, you could evaluate any routing protocol. + + +h2. Architecture -== Architecture == My system consists of the following components: - * [http://openwrt.org/ OpenWRT], kamikaze trunk version for x86 with minimal modifications (see below) - * one (unmodified) [http://www.qemu.org/ QEMU] instance per host - * one (modified, see below) [http://wiki.virtualsquare.org/index.php/VDE_Basic_Networking vde_switch] per instance. You need multiple instances to allow interconnection with wirefilter. - * one (unmodified) [http://wiki.virtualsquare.org/index.php/VDE#wirefilter wirefilter] per link between hosts. +* "OpenWRT":http://openwrt.org/, kamikaze trunk version for x86 with minimal modifications (see below) +* one (unmodified) "QEMU":http://www.qemu.org/ instance per host +* one (modified, see below) "vde_switch":http://wiki.virtualsquare.org/wiki/index.php/VDE_Basic_Networking per instance. You need multiple instances to allow interconnection with wirefilter. +* one (unmodified) "wirefilter":http://wiki.virtualsquare.org/wiki/index.php/VDE#wirefilter per link between hosts. + -=== OpenWRT === +h3. [[OpenWRT]] -OpenWRT has been used for this test. Some packages (tcpdump, netcat, batman-adv...) were added and kernel commandline parameters were modified to make sure that qemu boots up properly: -{{{ + +[[OpenWRT]] has been used for this test. Some packages (tcpdump, netcat, batman-adv...) were added and kernel commandline parameters were modified to make sure that qemu boots up properly: +<pre> noapic acpi=off -}}} +</pre> -Furthermore, to allow automatic network device setup on boot i'm using the following script which is located in /etc/rc.local ( ./files/etc/rc.local in OpenWRT build directory): +Furthermore, to allow automatic network device setup on boot i'm using the following script which is located in /etc/rc.local ( ./files/etc/rc.local in [[OpenWRT]] build directory): -{{{ +<pre> #!/bin/sh # kill default openwrt network config @@ -49,25 +55,24 @@ echo "" > /proc/net/batman-adv/interfaces echo eth0 > /proc/net/batman-adv/interfaces echo 15 > /proc/net/batman-adv/log_level ifconfig bat0 inet 192.168.0.${NUM} up -}}} +</pre> The script above is far from perfect, it takes some minutes after the rc.local file is finally started. Suggestions welcome. A sample openwrt image can be found here: - * [http://packetmixer.de/openwrt-x86-jffs2-128k.image] +* "h3. vde_switch -=== vde_switch === -The main advantage of [http://wiki.virtualsquare.org/index.php/VDE_Basic_Networking vde_switch] over [http://user-mode-linux.sourceforge.net/old/networking.html uml_switch] is that any clients can be attached to this virtual switch: QEMU, UML, tap interfaces, virtual interconnections, and not just UML instances. +The main advantage of [http://wiki.virtualsquare.org/wiki/index.php/VDE_Basic_Networking vde_switch":http://packetmixer.de/openwrt-x86-jffs2-128k.image] over "uml_switch":http://user-mode-linux.sourceforge.net/old/networking.html is that any clients can be attached to this virtual switch: QEMU, UML, tap interfaces, virtual interconnections, and not just UML instances. If the vde_switches were just connected with wirefilter "patch cables" without modification, we would end up creating a broadcast domain and switch loops which we don't want: The goal is to allow the packets to travel only from one host to it's neighbor, not farther. To accomplish this, i've modified the vde_switch to have "coloured" ports. The idea is: - * each port has a "colour" (an integer number) - * packets are only passed from ports to others with DIFFERENT colours. - * packets are dropped on outgoing ports if it has the SAME colour as the incoming port. +* each port has a "colour" (an integer number) +* packets are only passed from ports to others with DIFFERENT colours. +* packets are dropped on outgoing ports if it has the SAME colour as the incoming port. In this concept, the host port can have colour 1 while the interconnection ports have to colour 0. This way, packets can only travel from the host to (all of) the interconnection ports, or from one interconnection port to the host port. However packets can not travel between the the interconnection ports, thus only allowing "one hop" connections and avoiding switch loops and shared broadcast domains. The concept is illustrated below: @@ -75,35 +80,39 @@ In this concept, the host port can have colour 1 while the interconnection ports You can find the patch against vde2-2.2.3 (current latest stable version) to add these colour patches here: - * [attachment:vde2-2.2.3_colour.patch vde2-2.2.3_colour.patch] +* [attachment:vde2-2.2.3_colour.patch vde2-2.2.3_colour.patch] + + +h3. wirefilter -=== wirefilter === wirefilter is a tool where you can simulate various link defects and limits: - * packet loss - * burst loss - * delay - * duplicates - * bandwidth - * noise (damage to packets) - * mtu - * ... +* packet loss +* burst loss +* delay +* duplicates +* bandwidth +* noise (damage to packets) +* mtu +* ... However as the links are only set up bidirectional, interferences can unfortunately not be simulated with this system. -== Scripts == + +h2. Scripts + The following script is used to start up all the qemus. It is a good idea to start the script inside a screen to have the QEMU instances in screen windows (which can be switch with ctrl+a n, ctrl+a p). Make sure that you have the correct sudo priveleges or alternatively run this script as root. The script does: - * kill old instances - * start up vde_switch instances for each host - * start up QEMU hosts (one Ethernet tap device is created per instance to allow logging etc) - * install the links between the hosts. The resulting topology will be similar to this: +* kill old instances +* start up vde_switch instances for each host +* start up QEMU hosts (one Ethernet tap device is created per instance to allow logging etc) +* install the links between the hosts. The resulting topology will be similar to this: [[Image(wiki:Emulation:mesh.gif)]] -{{{ +<pre> #!/bin/sh QEMU=$(which qemu) VDESWITCH=~/src/vde2-2.2.3/src/vde_switch/vde_switch @@ -152,11 +161,11 @@ wirefilter --daemon -v num7.ctl:num9.ctl -l 60 wirefilter --daemon -v num2.ctl:num4.ctl -l 60 wirefilter --daemon -v num4.ctl:num6.ctl -l 60 wirefilter --daemon -v num6.ctl:num8.ctl -l 60 -}}} +</pre> The script is using the switch configuration file "colourful.rc". It creates the ports (create more if your topology demands this) and sets the host port (port no. 1) colour to 1. Put the following text in this file: -{{{ +<pre> port/setcolourful 1 port/create 1 port/create 2 @@ -164,15 +173,15 @@ port/create 3 port/create 4 port/create 5 port/setcolour 1 1 -}}} +</pre> To collect the batman logs from the individual hosts, you might want to use this script after all nodes have completed booting and started batman: -{{{ +<pre> #!/bin/sh for i in $(seq 1 9) do nc 192.168.${i}.2 2050 > num$i.log & done -}}} \ No newline at end of file +</pre> \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Release-todo (5393b8e1)
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 5393b8e133059c19b96dc619e14ae93b3f189a14 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Sun Nov 21 17:36:48 2010 +0000 doc: batman-adv/Release-todo >--------------------------------------------------------------- 5393b8e133059c19b96dc619e14ae93b3f189a14 batman-adv/Release-todo.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Release-todo.textile b/batman-adv/Release-todo.textile index 89e80ff8..71e7de5a 100644 --- a/batman-adv/Release-todo.textile +++ b/batman-adv/Release-todo.textile @@ -17,7 +17,7 @@ This page contains a checklist of things that need to be done for a release. * [x] update copyright years (if needed) * [ ] remove dead code (if any) * [x] check against kernel versions - * [ ] check that maint branch is merged in next + * [x] check that maint branch is merged in next * [ ] check for open patches on the ml * [ ] git tag release

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Emulation (588ef78e)
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 588ef78e2f1cadecfebe138327b6f3887f3c60e7 Author: Sven Eckelmann <sven(a)narfation.org> Date: Fri Nov 19 21:00:36 2010 +0000 doc: open-mesh/Emulation >--------------------------------------------------------------- 588ef78e2f1cadecfebe138327b6f3887f3c60e7 open-mesh/Emulation.textile | 91 ++++++++++++++++++++------------------------- 1 file changed, 41 insertions(+), 50 deletions(-) diff --git a/open-mesh/Emulation.textile b/open-mesh/Emulation.textile index 1ce2aaf3..3717260d 100644 --- a/open-mesh/Emulation.textile +++ b/open-mesh/Emulation.textile @@ -1,34 +1,28 @@ [[PageOutline]] += Emulation Setup = -h1. Emulation Setup - - -As a lot of people discussed about simulating mesh network protocols at "WBMv2":http://hackerspace.be/Wbm2009v2/, i'd like to share my qemu setup which i used to gather some data for batman-adv. The idea is to use "QEMU":http://www.qemu.org/ or "UML":http://user-mode-linux.sourceforge.net/ (instead of frameworks like they exist for "NS-2":http://www.isi.edu/nsnam/ns/) to run an unmodified linux system with the unmodified source code. Besides BATMAN, you could evaluate any routing protocol. - - -h2. Architecture +As a lot of people discussed about simulating mesh network protocols at [http://hackerspace.be/Wbm2009v2/ WBMv2], i'd like to share my qemu setup which i used to gather some data for batman-adv. The idea is to use [http://www.qemu.org/ QEMU] or [http://user-mode-linux.sourceforge.net/ UML] (instead of frameworks like they exist for [http://www.isi.edu/nsnam/ns/ NS-2]) to run an unmodified linux system with the unmodified source code. Besides BATMAN, you could evaluate any routing protocol. +== Architecture == My system consists of the following components: -* "OpenWRT":http://openwrt.org/, kamikaze trunk version for x86 with minimal modifications (see below) -* one (unmodified) "QEMU":http://www.qemu.org/ instance per host -* one (modified, see below) "vde_switch":http://wiki.virtualsquare.org/wiki/index.php/VDE_Basic_Networking per instance. You need multiple instances to allow interconnection with wirefilter. -* one (unmodified) "wirefilter":http://wiki.virtualsquare.org/wiki/index.php/VDE#wirefilter per link between hosts. - + * [http://openwrt.org/ OpenWRT], kamikaze trunk version for x86 with minimal modifications (see below) + * one (unmodified) [http://www.qemu.org/ QEMU] instance per host + * one (modified, see below) [http://wiki.virtualsquare.org/wiki/index.php/VDE_Basic_Networking vde_switch] per instance. You need multiple instances to allow interconnection with wirefilter. + * one (unmodified) [http://wiki.virtualsquare.org/wiki/index.php/VDE#wirefilter wirefilter] per link between hosts. -h3. [[OpenWRT]] +=== OpenWRT === - -[[OpenWRT]] has been used for this test. Some packages (tcpdump, netcat, batman-adv...) were added and kernel commandline parameters were modified to make sure that qemu boots up properly: -<pre> +OpenWRT has been used for this test. Some packages (tcpdump, netcat, batman-adv...) were added and kernel commandline parameters were modified to make sure that qemu boots up properly: +{{{ noapic acpi=off -</pre> +}}} -Furthermore, to allow automatic network device setup on boot i'm using the following script which is located in /etc/rc.local ( ./files/etc/rc.local in [[OpenWRT]] build directory): +Furthermore, to allow automatic network device setup on boot i'm using the following script which is located in /etc/rc.local ( ./files/etc/rc.local in OpenWRT build directory): -<pre> +{{{ #!/bin/sh # kill default openwrt network config @@ -55,24 +49,25 @@ echo "" > /proc/net/batman-adv/interfaces echo eth0 > /proc/net/batman-adv/interfaces echo 15 > /proc/net/batman-adv/log_level ifconfig bat0 inet 192.168.0.${NUM} up -</pre> +}}} The script above is far from perfect, it takes some minutes after the rc.local file is finally started. Suggestions welcome. A sample openwrt image can be found here: -* "h3. vde_switch + * [http://packetmixer.de/openwrt-x86-jffs2-128k.image] +=== vde_switch === -The main advantage of [http://wiki.virtualsquare.org/wiki/index.php/VDE_Basic_Networking vde_switch":http://packetmixer.de/openwrt-x86-jffs2-128k.image] over "uml_switch":http://user-mode-linux.sourceforge.net/old/networking.html is that any clients can be attached to this virtual switch: QEMU, UML, tap interfaces, virtual interconnections, and not just UML instances. +The main advantage of [http://wiki.virtualsquare.org/wiki/index.php/VDE_Basic_Networking vde_switch] over [http://user-mode-linux.sourceforge.net/old/networking.html uml_switch] is that any clients can be attached to this virtual switch: QEMU, UML, tap interfaces, virtual interconnections, and not just UML instances. If the vde_switches were just connected with wirefilter "patch cables" without modification, we would end up creating a broadcast domain and switch loops which we don't want: The goal is to allow the packets to travel only from one host to it's neighbor, not farther. To accomplish this, i've modified the vde_switch to have "coloured" ports. The idea is: -* each port has a "colour" (an integer number) -* packets are only passed from ports to others with DIFFERENT colours. -* packets are dropped on outgoing ports if it has the SAME colour as the incoming port. + * each port has a "colour" (an integer number) + * packets are only passed from ports to others with DIFFERENT colours. + * packets are dropped on outgoing ports if it has the SAME colour as the incoming port. In this concept, the host port can have colour 1 while the interconnection ports have to colour 0. This way, packets can only travel from the host to (all of) the interconnection ports, or from one interconnection port to the host port. However packets can not travel between the the interconnection ports, thus only allowing "one hop" connections and avoiding switch loops and shared broadcast domains. The concept is illustrated below: @@ -80,39 +75,35 @@ In this concept, the host port can have colour 1 while the interconnection ports You can find the patch against vde2-2.2.3 (current latest stable version) to add these colour patches here: -* [attachment:vde2-2.2.3_colour.patch vde2-2.2.3_colour.patch] - - -h3. wirefilter + * [attachment:vde2-2.2.3_colour.patch vde2-2.2.3_colour.patch] +=== wirefilter === wirefilter is a tool where you can simulate various link defects and limits: -* packet loss -* burst loss -* delay -* duplicates -* bandwidth -* noise (damage to packets) -* mtu -* ... + * packet loss + * burst loss + * delay + * duplicates + * bandwidth + * noise (damage to packets) + * mtu + * ... However as the links are only set up bidirectional, interferences can unfortunately not be simulated with this system. - -h2. Scripts - +== Scripts == The following script is used to start up all the qemus. It is a good idea to start the script inside a screen to have the QEMU instances in screen windows (which can be switch with ctrl+a n, ctrl+a p). Make sure that you have the correct sudo priveleges or alternatively run this script as root. The script does: -* kill old instances -* start up vde_switch instances for each host -* start up QEMU hosts (one Ethernet tap device is created per instance to allow logging etc) -* install the links between the hosts. The resulting topology will be similar to this: + * kill old instances + * start up vde_switch instances for each host + * start up QEMU hosts (one Ethernet tap device is created per instance to allow logging etc) + * install the links between the hosts. The resulting topology will be similar to this: [[Image(wiki:Emulation:mesh.gif)]] -<pre> +{{{ #!/bin/sh QEMU=$(which qemu) VDESWITCH=~/src/vde2-2.2.3/src/vde_switch/vde_switch @@ -161,11 +152,11 @@ wirefilter --daemon -v num7.ctl:num9.ctl -l 60 wirefilter --daemon -v num2.ctl:num4.ctl -l 60 wirefilter --daemon -v num4.ctl:num6.ctl -l 60 wirefilter --daemon -v num6.ctl:num8.ctl -l 60 -</pre> +}}} The script is using the switch configuration file "colourful.rc". It creates the ports (create more if your topology demands this) and sets the host port (port no. 1) colour to 1. Put the following text in this file: -<pre> +{{{ port/setcolourful 1 port/create 1 port/create 2 @@ -173,15 +164,15 @@ port/create 3 port/create 4 port/create 5 port/setcolour 1 1 -</pre> +}}} To collect the batman logs from the individual hosts, you might want to use this script after all nodes have completed booting and started batman: -<pre> +{{{ #!/bin/sh for i in $(seq 1 9) do nc 192.168.${i}.2 2050 > num$i.log & done -</pre> \ No newline at end of file +}}} \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Download (4717bf85)
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 4717bf85e51f8842862463c3d5cc679599b0cbf5 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Sun Nov 21 21:51:03 2010 +0000 doc: open-mesh/Download >--------------------------------------------------------------- 4717bf85e51f8842862463c3d5cc679599b0cbf5 open-mesh/Download.textile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/open-mesh/Download.textile b/open-mesh/Download.textile index e776b892..68b2d468 100644 --- a/open-mesh/Download.textile +++ b/open-mesh/Download.textile @@ -4,8 +4,8 @@ We are currently working on different branches. To get the details about the dif We are offering sources and precompiled batmand binaries and packages for different platforms and for the [http://downloads.open-mesh.org/batman/stable/ stable] and the [http://downloads.open-mesh.org/batman/development/ development] branch. However, please use the stable branch for your public infrastructure unless you know exactly what you are doing and are prepared for the big unknown. A kernel module needs to be linked against the exact kernel headers you are using, therefore we are unable to provide precompiled binaries for batman-adv. === Download Released Source Code === - * The latest version of [wiki:batman-adv batman-adv] is [http://downloads.open-mesh.org/batman/stable/sources/batman-adv/batman-adv-… batman-adv-2010.1.0.tar.gz] [http://downloads.open-mesh.org/batman/stable/sources/batman-adv/batman-adv-… md5] [http://downloads.open-mesh.org/batman/stable/sources/batman-adv/batman-adv-… sha1] [http://downloads.open-mesh.org/batman/stable/sources/batman-adv/batman-adv-… asc] - * The latest version of batctl (management and control tool for batman-adv) is [http://downloads.open-mesh.org/batman/stable/sources/batctl/batctl-2010.1.0… batctl-2010.1.0.tar.gz] [http://downloads.open-mesh.org/batman/stable/sources/batctl/batctl-2010.1.0… md5] [http://downloads.open-mesh.org/batman/stable/sources/batctl/batctl-2010.1.0… sha1] [http://downloads.open-mesh.org/batman/stable/sources/batctl/batctl-2010.1.0… asc] + * The latest version of [wiki:batman-adv batman-adv] is [http://downloads.open-mesh.org/batman/stable/sources/batman-adv/batman-adv-… batman-adv-2010.2.0.tar.gz] [http://downloads.open-mesh.org/batman/stable/sources/batman-adv/batman-adv-… md5] [http://downloads.open-mesh.org/batman/stable/sources/batman-adv/batman-adv-… sha1] [http://downloads.open-mesh.org/batman/stable/sources/batman-adv/batman-adv-… asc] + * The latest version of batctl (management and control tool for batman-adv) is [http://downloads.open-mesh.org/batman/stable/sources/batctl/batctl-2010.2.0… batctl-2010.2.0.tar.gz] [http://downloads.open-mesh.org/batman/stable/sources/batctl/batctl-2010.2.0… md5] [http://downloads.open-mesh.org/batman/stable/sources/batctl/batctl-2010.2.0… sha1] [http://downloads.open-mesh.org/batman/stable/sources/batctl/batctl-2010.2.0… asc] * The latest stable version of batmand is [http://downloads.open-mesh.org/batman/releases/batman-0.3.2/batman-0.3.2.ta… batman-0.3.2.tar.gz] [http://downloads.open-mesh.org/batman/releases/batman-0.3.2/batman-0.3.2.ta… md5] [http://downloads.open-mesh.org/batman/releases/batman-0.3.2/batman-0.3.2.ta… sha1] [http://downloads.open-mesh.org/batman/releases/batman-0.3.2/batman-0.3.2.ta… asc] * The latest version of the vis server for the batmand (package not needed for batman-adv) is [http://downloads.open-mesh.org/batman/releases/batman-0.3.2/vis-0.3.2.tar.gz vis-0.3.2.tar.gz] [http://downloads.open-mesh.org/batman/releases/batman-0.3.2/vis-0.3.2.tar.g… md5] [http://downloads.open-mesh.org/batman/releases/batman-0.3.2/vis-0.3.2.tar.g… sha1] [http://downloads.open-mesh.org/batman/releases/batman-0.3.2/vis-0.3.2.tar.g… asc] @@ -39,6 +39,7 @@ It follows an overview of linux versions and the batman-adv version they contain * linux 2.6.34 => batman-adv 0.2.1 (get batctl 0.2.1 from [http://downloads.open-mesh.org/batman/stable/sources/batctl/ here]) * linux 2.6.35 => batman-adv 2010.0.0 (get batctl 2010.0.0 from [http://downloads.open-mesh.org/batman/stable/sources/batctl/ here]) * linux 2.6.36 => batman-adv 2010.1.0 (get batctl 2010.1.0 from [http://downloads.open-mesh.org/batman/stable/sources/batctl/ here]) + * linux 2.6.37 => batman-adv 2010.2.0 (get batctl 2010.2.0 from [http://downloads.open-mesh.org/batman/stable/sources/batctl/ here]) === Debian ===

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Release-todo (bc61a3de)
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 bc61a3de843167fd825f668c69927006fc83c305 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Sun Nov 21 17:35:41 2010 +0000 doc: batman-adv/Release-todo >--------------------------------------------------------------- bc61a3de843167fd825f668c69927006fc83c305 batman-adv/Release-todo.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/batman-adv/Release-todo.textile b/batman-adv/Release-todo.textile index dcdcb4ac..89e80ff8 100644 --- a/batman-adv/Release-todo.textile +++ b/batman-adv/Release-todo.textile @@ -14,9 +14,9 @@ This page contains a checklist of things that need to be done for a release. '''Code''' * [ ] make sure all code contains the release version strings - * [ ] update copyright years (if needed) + * [x] update copyright years (if needed) * [ ] remove dead code (if any) - * [ ] check against kernel versions + * [x] check against kernel versions * [ ] check that maint branch is merged in next * [ ] check for open patches on the ml * [ ] git tag release

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/ELP: adding png's and further information (a01e6f42)
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 a01e6f422489d1d120937061e5b050332db0ec60 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Fri Oct 22 23:38:28 2010 +0000 doc: batman-adv/ELP: adding png's and further information >--------------------------------------------------------------- a01e6f422489d1d120937061e5b050332db0ec60 batman-adv/ELP.textile | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/batman-adv/ELP.textile b/batman-adv/ELP.textile index 0a86731f..8d3d9c92 100644 --- a/batman-adv/ELP.textile +++ b/batman-adv/ELP.textile @@ -15,13 +15,21 @@ In the following 4 node scenario, the parameters are as follows: * 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. -The following table holds the following information: +'''t = 0:''' + +[[Image(NDP-mobile-loop-0s.png, 20%25)]] + +'''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. -[[http://x-realis.dyndns.org/freifunk/scan.pdf Table]] - ''Result:'' In this quite typical and small-scale scenario, we already have an average time with looping packets of '''3.3''' seconds. == packet type: BAT_PACKET_NDP ==

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/ELP: adding link to scanned table (929211d4)
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 929211d42644fdf3974cf24bec7f5356a0ce6c69 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Fri Oct 22 23:07:54 2010 +0000 doc: batman-adv/ELP: adding link to scanned table >--------------------------------------------------------------- 929211d42644fdf3974cf24bec7f5356a0ce6c69 batman-adv/ELP.textile | 1 + 1 file changed, 1 insertion(+) diff --git a/batman-adv/ELP.textile b/batman-adv/ELP.textile index d278061f..0a86731f 100644 --- a/batman-adv/ELP.textile +++ b/batman-adv/ELP.textile @@ -20,6 +20,7 @@ The following table holds the following information: * 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. +[[http://x-realis.dyndns.org/freifunk/scan.pdf Table]] ''Result:'' In this quite typical and small-scale scenario, we already have an average time with looping packets of '''3.3''' seconds.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/ELP: text for loop description (c007aaa7)
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 c007aaa707177add5046df184b1581ed0937db4e Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Fri Oct 22 23:02:36 2010 +0000 doc: batman-adv/ELP: text for loop description >--------------------------------------------------------------- c007aaa707177add5046df184b1581ed0937db4e batman-adv/ELP.textile | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/batman-adv/ELP.textile b/batman-adv/ELP.textile index 91060c4f..d278061f 100644 --- a/batman-adv/ELP.textile +++ b/batman-adv/ELP.textile @@ -8,6 +8,21 @@ However, this also has three major drawbacks: The idea is to strip the link-quality calculations from the normal originator-messages and use a seperate packet type (basically hello-messages) and mechanism for this. Which would allow us to develop (convergence) optimization strategies for both jobs independently. +== Looping problems == +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) +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. + +The following table 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. + == packet type: BAT_PACKET_NDP == {{{ /* Neighbor discovery packet */

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017