commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/FAQ (db71f3df)
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 db71f3df9b71aa7c37a521e4e88b3f9dda120c5c Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Tue Jun 29 16:42:00 2010 +0000 doc: open-mesh/FAQ >--------------------------------------------------------------- db71f3df9b71aa7c37a521e4e88b3f9dda120c5c open-mesh/FAQ.textile | 69 +++++++++++++++++++++++++++++++++++---------------- 1 file changed, 48 insertions(+), 21 deletions(-) diff --git a/open-mesh/FAQ.textile b/open-mesh/FAQ.textile index 128cf7e0..e01f9bc0 100644 --- a/open-mesh/FAQ.textile +++ b/open-mesh/FAQ.textile @@ -1,16 +1,22 @@ -= FAQ = -{{{ -#!div style="width: 46em; text-align: justify" +h1. FAQ -If you are missing a question/answer (quite likely) please use the [wiki:MailingList B.A.T.M.A.N. mailing list] or [wiki:IRC IRC channel] to trigger us. -=== Does B.A.T.M.A.N. have simulator (NS2, Omnet++, etc) support? === +<pre> +<code class="div"> -At this point no 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 [wiki:Emulation read our emulation document]. +If you are missing a question/answer (quite likely) please use the [[MailingList|BATMAN mailing list] or [wikiIRC IRC channel]] to trigger us. + + +h3. Does B.A.T.M.A.N. have simulator (NS2, Omnet++, etc) support? + + +At this point no 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 [[Emulation|read our emulation document]]. + + +h3. How to make my mesh network secure ? -=== How to make my mesh network secure ? === What kind of security do you need? Security is a big field. Maybe you just mean encryption and authentication..... @@ -34,46 +40,65 @@ So it really depends what you want and cannot be resolved in a "security for everything, against any attack and for every purpose" blob. -=== Understanding the version and compatibility number === + +h3. Why does batman need so much time to detect a "dead" node ? + + +Or: Why can I see a node in the originator table a long time after it died ? + +Or: Does batman really need 200 seconds (PURGE_TIMEOUT) to switch the route ? + +Batman switches the route as soon as it learns about a better path towards a destination which can take a fraction of a second up to several seconds very much depending on the settings and situation. When no more new originator messages are sent by a node (because it died), no more routing updates regarding this node are exchanged. Batman will not immediately delete this node from its database because the connection could just have a temporary problem and might recover. Only after a timeout period of (currently) 200 seconds the node is removed entirely from batman's internal database. It does not hurt to give the node a little extra time to recover from a connection loss as it speeds up the resume process. All routes using this "lost" node as intermediate hop will have changed towards another path in the meantime and are of no concern. + + + +h3. Understanding the version and compatibility number + The version number (defined as SOURCE_VERSION in the source)is the one displayed when launching the batmand in debug mode. It indicates the state of your code. The compatibility number (defined as COMPAT_VERSION in the source) is transmitted with every broadcasted OGM to guide other batmand instances receiving this OGM whith the decision about incompatible protocol versions. -=== Why are multiple interfaces problematic? === + +h3. Why are multiple interfaces problematic? + The internet (and most network technology today) was designed with the idea that every interface on a given system has a unique broadcast adress. When a packet enters a system the kernel has to decide where it should be routed to. While using the same broadcast adresses on different interfaces you provoke an undefined situation as this should not happen (by design) and the result is unpredictable. In that case the Linux kernel will send all your packages to the first interface (in the routing table) with that broadcast address. A solution to that problem is the usage of the Linux kernel option "BINDTODEVICE" which allows to specify an outgoing interface for a packet. Unfortunatly this option is a Linux-only feature (as far as we know). Therefore you won't be able to use multiple interfaces with the same broadcast addresses on other operation systems than Linux. -=== Log larger amounts of debug messages === -First, install netcat on your device. On a OpenWRT based distro you can try this (packet version may vary): +h3. Log larger amounts of debug messages + -{{{ +First, install netcat on your device. On a [[OpenWRT]] based distro you can try this (packet version may vary): + +<pre> ipkg install http://www.linuxops.net/ipkg/netcat_0.7.1_mipsel.ipk -}}} +</code></pre> Then start batmand and pipe the output into netcat: -{{{ +<pre> batmand -d 4 <your_interfaces> | nc -l -p <any_unused_port> -}}} +</code></pre> Finally start the netcat client on your logging server and save the output: -{{{ +<pre> nc <IP_of_your_device> <your_unused_port_from_step_2> > batman.log -}}} +</code></pre> If you use a firewall, NAT or any other problematic network setup you can swap the netcat server position. Beware: Your netcat server has to be started before you start your netcat client. -=== Update many Openwrt based systems === - 1. Download the update script: [http://downloads.open-mesh.org/batman/useful-scripts-and-tools/update_batma… update script] +h3. Update many Openwrt based systems + + + 1. Download the update script: "update script":http://downloads.open-mesh.org/batman/useful-scripts-and-tools/update_batman.sh 2. Edit the the variables in the configuration section of the script to match your needs. 3. Run the script. ;-) @@ -83,10 +108,12 @@ Note: The HOSTS_TO_UPDATE variable in the script expects SSH host names which mu Tip: Use key based access to authenticate your login request on your machines to avoid typing your passwords too often. If you use encrypted keys you can enable the ssh-agent to manage your passwords. -=== What is the batgat kernel module good for? === + +h3. What is the batgat kernel module good for? + The batman daemon maintains a tunnel connection to every "batman internet client". Every packet that goes to the internet or comes back has to go through this tunnel. As it is a user space tunnel a lot of copying between user space and kernel land is necessary. Depending on the number of clients and the CPU power available this might be a bottleneck. The batgat kernel module tries to overcome this limitation. Once loaded the batman daemon will detect its presence automatically on startup. The daemon will activate the kernel module to let it handle the tunneling, hence avoiding the expensive copy operations. There is no difference between the daemon tunneling and the kernel tunneling other than that. -}}} +</code></pre>

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Understand-your-batman-adv-network (0af2a3f0)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/SubmittingLinux: force compilation as module in build tests (4e4a66d1)
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 4e4a66d1319e89c83f88be4591f2a739d496f7d9 Author: Sven Eckelmann <sven(a)narfation.org> Date: Tue Jul 6 20:35:07 2010 +0000 doc: batman-adv/SubmittingLinux: force compilation as module in build tests >--------------------------------------------------------------- 4e4a66d1319e89c83f88be4591f2a739d496f7d9 batman-adv/SubmittingLinux.textile | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/batman-adv/SubmittingLinux.textile b/batman-adv/SubmittingLinux.textile index fb9f3f3e..928faddb 100644 --- a/batman-adv/SubmittingLinux.textile +++ b/batman-adv/SubmittingLinux.textile @@ -260,32 +260,32 @@ a85d1b45e4cde0c882a41baaefeec0cd5502416f '-(%25)-(patches)> git checkout 166b2caa61fce5260aed4e119671764331fdc62a Previous HEAD position was a85d1b4... batman-adv: Avoid rounding issues for local hna timeout HEAD is now at 166b2ca... batman-adv: Convert names from Java to C style -'-(%25)-(166b2caa61fce5260aed4e119671764331fdc62a)> make CC=cgcc -C /home/sven/tmp/linux-next M=`pwd` +'-(%25)-(166b2caa61fce5260aed4e119671764331fdc62a)> make CONFIG_BATMAN_ADV=m CC=cgcc -C /home/sven/tmp/linux-next M=`pwd` ... '-(%25)-(166b2caa61fce5260aed4e119671764331fdc62a)> git checkout 5cd65234b12021fe1f28e28e455a6b6a06712ec2 Previous HEAD position was 166b2ca... batman-adv: Convert names from Java to C style HEAD is now at 5cd6523... batman-adv: Avoid rounding issues for local hna timeout -'-(%25)-(83d1bc8bb328bcfa42be492fe0e2648b77c18af2)> make CC=cgcc -C /home/sven/tmp/linux-next M=`pwd` +'-(%25)-(83d1bc8bb328bcfa42be492fe0e2648b77c18af2)> make CONFIG_BATMAN_ADV=m CC=cgcc -C /home/sven/tmp/linux-next M=`pwd` .... '-(%25)-(83d1bc8bb328bcfa42be492fe0e2648b77c18af2)> git checkout 9e9605f0fe000f1097cb43271540ab2b76b2a782 Previous HEAD position was 83d1bc8... batman-adv: Lower resolution for timeouts HEAD is now at 9e9605f... batman-adv: replace manual calculation by msecs_to_jiffies() for better readability -'-(%25)-(9e9605f0fe000f1097cb43271540ab2b76b2a782)> make CC=cgcc -C /home/sven/tmp/linux-next M=`pwd` +'-(%25)-(9e9605f0fe000f1097cb43271540ab2b76b2a782)> make CONFIG_BATMAN_ADV=m CC=cgcc -C /home/sven/tmp/linux-next M=`pwd` .... '-(%25)-(9e9605f0fe000f1097cb43271540ab2b76b2a782)> git checkout 043aa9a54a5296c6027a5bcd808b8d29cea8a474 Previous HEAD position was 9e9605f... batman-adv: replace manual calculation by msecs_to_jiffies() for better readability HEAD is now at 043aa9a... Staging: batman-adv: Add sysfs abi documentation about bonding -'-(%25)-(043aa9a54a5296c6027a5bcd808b8d29cea8a474)> make CC=cgcc -C /home/sven/tmp/linux-next M=`pwd` +'-(%25)-(043aa9a54a5296c6027a5bcd808b8d29cea8a474)> make CONFIG_BATMAN_ADV=m CC=cgcc -C /home/sven/tmp/linux-next M=`pwd` ... '-(%25)-(043aa9a54a5296c6027a5bcd808b8d29cea8a474)> git checkout f6d8baba5fce6161bc2cee9c97e0afbc139942c0 Previous HEAD position was 043aa9a... Staging: batman-adv: Add sysfs abi documentation about bonding HEAD is now at f6d8bab... batman-adv: adapting source version to revised versioning scheme -'-(%25)-(f6d8baba5fce6161bc2cee9c97e0afbc139942c0)> make CC=cgcc -C /home/sven/tmp/linux-next M=`pwd` +'-(%25)-(f6d8baba5fce6161bc2cee9c97e0afbc139942c0)> make CONFIG_BATMAN_ADV=m CC=cgcc -C /home/sven/tmp/linux-next M=`pwd` ... '-(%25)-(f6d8baba5fce6161bc2cee9c97e0afbc139942c0)> git checkout a85d1b45e4cde0c882a41baaefeec0cd5502416f Previous HEAD position was f6d8bab... batman-adv: adapting source version to revised versioning scheme HEAD is now at a85d1b4... batman-adv: Add include guards to all header files -'-(%25)-(a85d1b45e4cde0c882a41baaefeec0cd5502416f)> make CC=cgcc -C /home/sven/tmp/linux-next M=`pwd` +'-(%25)-(a85d1b45e4cde0c882a41baaefeec0cd5502416f)> make CONFIG_BATMAN_ADV=m CC=cgcc -C /home/sven/tmp/linux-next M=`pwd` ... '-(%25)-(a85d1b45e4cde0c882a41baaefeec0cd5502416f)> git checkout patches Switched to branch 'patches'

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Building-with-openwrt (4287e213)
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 (4f298890)
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 4f2988901679ec24d2ea622c7ab911c532c7ec04 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Thu Jul 1 17:05:02 2010 +0000 doc: batman-adv/Building-with-openwrt >--------------------------------------------------------------- 4f2988901679ec24d2ea622c7ab911c532c7ec04 batman-adv/Building-with-openwrt.textile | 45 +++++++++++++------------------- 1 file changed, 18 insertions(+), 27 deletions(-) diff --git a/batman-adv/Building-with-openwrt.textile b/batman-adv/Building-with-openwrt.textile index 2fbd17cb..0b26f754 100644 --- a/batman-adv/Building-with-openwrt.textile +++ b/batman-adv/Building-with-openwrt.textile @@ -8,25 +8,25 @@ Many tutorials assume that you have batman-adv running on an OpenWRT system with === 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: +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 (backfire 10.03 at the point of writing this document) via SVN: {{{ -svn co svn://svn.openwrt.org/openwrt/tags/8.09.2 openwrt-kamikaze +svn co svn://svn.openwrt.org/openwrt/tags/backfire_10.03 openwrt }}} 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 +cd openwrt make menuconfig }}} __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: +To build your images you always have to invoke the "make" command from within the openwrt folder: {{{ -cd openwrt-kamikaze +cd openwrt make }}} @@ -34,33 +34,32 @@ The rest of the document will focus on the batman-adv package. It is assumed tha === Adding the batman-adv package === -There are 2 ways to add the batman-adv package: - * downloading the OpenWRT package repository and adding the package to your OpenWRT build system (the manual way) - * using scripts provided by OpenWRT to download the whole package repository and adding all packages to your OpenWRT build system (the easy way) +The standard OpenWRT package feed contains a batman-adv package which is intended to be used on a day to day basis, therefore it retrieves the latest batman-adv stable release. Since a lot of people want to experiment with the latest features or use OpenWRT to test their own batman-adv patches we also provide an openwrt package feed which contains the batman-adv development version. -__The easy way__: [[BR]] +__Adding the stable version__: [[BR]] {{{ scripts/feeds update -scripts/feeds install kmod-batman-adv-kernelland +scripts/feeds install kmod-batman-adv }}} ''Note'': If you downloaded an OpenWRT release but intend to build the latest batman-adv package you might need to modify your feeds.conf(.default). Make sure you have ''"svn-src packages !svn://svn.openwrt.org/openwrt/packages"'' instead of e.g. ''"src-svn packages !svn://svn.openwrt.org/openwrt/branches/packages_8.09"''. -__The manual way__: [[BR]] +__Adding the developer version__: [[BR]] -Download the OpenWRT package repository via SVN next to your openwrt-kamikaze folder (not inside!): +Append the following line to your openwrt feed configuration file (either feeds.conf or feeds.conf.default): {{{ -svn co svn://svn.openwrt.org/openwrt/packages openwrt-packages +src-svn batman http://downloads.open-mesh.org/svn/openwrt-feed/ }}} -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: +Update the package information and add the development package: {{{ -cd openwrt-kamikaze/package -ln -sf ../../openwrt-packages/net/batman-advanced/ . +scripts/feeds update +scripts/feeds install kmod-batman-adv-devel }}} + === Configuring the batman-adv package === As soon as the batman-adv package has been added, it will show up in the OpenWRT package menu: @@ -68,27 +67,19 @@ As soon as the batman-adv package has been added, it will show up in the OpenWRT {{{ Kernel modules ---> Network Support ---> - kmod-batman-adv-kernelland + kmod-batman-adv }}} -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. +Once the package had been selected a number of suboptions will become visible. You 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 uci file to retrieve the settings which allows to specify interfaces, intervals, log level and more. === Advanced features === -The package offers an easy way to apply custom patches whenever batman-adv is built. Next to the standard OpenWRT method of having a "patches" folder you also can apply patches depending on the branch you chose. Order in which patches are applied: - -{{{ -patches/* -patches/maint/* # if the maint branch was chosen -patches/dev/* # if the dev branch was chosen -}}} - If you experience build problems or simply intend to rebuild the batman-adv package only, you can tell OpenWRT to build a specific package and enable the debugging mode as follows: {{{ -cd openwrt-kamikaze +cd openwrt make package/batman-advanced/clean make package/batman-advanced/compile V=99 }}}

1 0

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

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/FAQ (ce9576aa)
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 ce9576aa960fa9295d7edc4311c423e4e5d0f3aa Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Tue Jun 29 16:42:00 2010 +0000 doc: open-mesh/FAQ >--------------------------------------------------------------- ce9576aa960fa9295d7edc4311c423e4e5d0f3aa open-mesh/FAQ.textile | 65 ++++++++++++++++++--------------------------------- 1 file changed, 23 insertions(+), 42 deletions(-) diff --git a/open-mesh/FAQ.textile b/open-mesh/FAQ.textile index e01f9bc0..cc6ed3eb 100644 --- a/open-mesh/FAQ.textile +++ b/open-mesh/FAQ.textile @@ -1,22 +1,16 @@ += FAQ = -h1. FAQ +{{{ +#!div style="width: 46em; text-align: justify" +If you are missing a question/answer (quite likely) please use the [wiki:MailingList B.A.T.M.A.N. mailing list] or [wiki:IRC IRC channel] to trigger us. -<pre> -<code class="div"> +=== Does B.A.T.M.A.N. have simulator (NS2, Omnet++, etc) support? === -If you are missing a question/answer (quite likely) please use the [[MailingList|BATMAN mailing list] or [wikiIRC IRC channel]] to trigger us. - - -h3. Does B.A.T.M.A.N. have simulator (NS2, Omnet++, etc) support? - - -At this point no 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 [[Emulation|read our emulation document]]. - - -h3. How to make my mesh network secure ? +At this point no 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 [wiki:Emulation read our emulation document]. +=== How to make my mesh network secure ? === What kind of security do you need? Security is a big field. Maybe you just mean encryption and authentication..... @@ -40,65 +34,54 @@ So it really depends what you want and cannot be resolved in a "security for everything, against any attack and for every purpose" blob. +=== Why does batman need so much time to detect a "dead" node ? === -h3. Why does batman need so much time to detect a "dead" node ? - - -Or: Why can I see a node in the originator table a long time after it died ? - +Or: Why can I see a node in the originator table a long time after it died ?[[BR]] Or: Does batman really need 200 seconds (PURGE_TIMEOUT) to switch the route ? Batman switches the route as soon as it learns about a better path towards a destination which can take a fraction of a second up to several seconds very much depending on the settings and situation. When no more new originator messages are sent by a node (because it died), no more routing updates regarding this node are exchanged. Batman will not immediately delete this node from its database because the connection could just have a temporary problem and might recover. Only after a timeout period of (currently) 200 seconds the node is removed entirely from batman's internal database. It does not hurt to give the node a little extra time to recover from a connection loss as it speeds up the resume process. All routes using this "lost" node as intermediate hop will have changed towards another path in the meantime and are of no concern. - -h3. Understanding the version and compatibility number - +=== Understanding the version and compatibility number === The version number (defined as SOURCE_VERSION in the source)is the one displayed when launching the batmand in debug mode. It indicates the state of your code. The compatibility number (defined as COMPAT_VERSION in the source) is transmitted with every broadcasted OGM to guide other batmand instances receiving this OGM whith the decision about incompatible protocol versions. - -h3. Why are multiple interfaces problematic? - +=== Why are multiple interfaces problematic? === The internet (and most network technology today) was designed with the idea that every interface on a given system has a unique broadcast adress. When a packet enters a system the kernel has to decide where it should be routed to. While using the same broadcast adresses on different interfaces you provoke an undefined situation as this should not happen (by design) and the result is unpredictable. In that case the Linux kernel will send all your packages to the first interface (in the routing table) with that broadcast address. A solution to that problem is the usage of the Linux kernel option "BINDTODEVICE" which allows to specify an outgoing interface for a packet. Unfortunatly this option is a Linux-only feature (as far as we know). Therefore you won't be able to use multiple interfaces with the same broadcast addresses on other operation systems than Linux. +=== Log larger amounts of debug messages === -h3. Log larger amounts of debug messages - - -First, install netcat on your device. On a [[OpenWRT]] based distro you can try this (packet version may vary): +First, install netcat on your device. On a OpenWRT based distro you can try this (packet version may vary): -<pre> +{{{ ipkg install http://www.linuxops.net/ipkg/netcat_0.7.1_mipsel.ipk -</code></pre> +}}} Then start batmand and pipe the output into netcat: -<pre> +{{{ batmand -d 4 <your_interfaces> | nc -l -p <any_unused_port> -</code></pre> +}}} Finally start the netcat client on your logging server and save the output: -<pre> +{{{ nc <IP_of_your_device> <your_unused_port_from_step_2> > batman.log -</code></pre> +}}} If you use a firewall, NAT or any other problematic network setup you can swap the netcat server position. Beware: Your netcat server has to be started before you start your netcat client. +=== Update many Openwrt based systems === -h3. Update many Openwrt based systems - - - 1. Download the update script: "update script":http://downloads.open-mesh.org/batman/useful-scripts-and-tools/update_batman.sh + 1. Download the update script: [http://downloads.open-mesh.org/batman/useful-scripts-and-tools/update_batma… update script] 2. Edit the the variables in the configuration section of the script to match your needs. 3. Run the script. ;-) @@ -108,12 +91,10 @@ Note: The HOSTS_TO_UPDATE variable in the script expects SSH host names which mu Tip: Use key based access to authenticate your login request on your machines to avoid typing your passwords too often. If you use encrypted keys you can enable the ssh-agent to manage your passwords. - -h3. What is the batgat kernel module good for? - +=== What is the batgat kernel module good for? === The batman daemon maintains a tunnel connection to every "batman internet client". Every packet that goes to the internet or comes back has to go through this tunnel. As it is a user space tunnel a lot of copying between user space and kernel land is necessary. Depending on the number of clients and the CPU power available this might be a bottleneck. The batgat kernel module tries to overcome this limitation. Once loaded the batman daemon will detect its presence automatically on startup. The daemon will activate the kernel module to let it handle the tunneling, hence avoiding the expensive copy operations. There is no difference between the daemon tunneling and the kernel tunneling other than that. -</code></pre> +}}}

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multicast-ideas (b01a61cb)
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 b01a61cb19e248e64560e17c6b0f78261b2d0e37 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Sun Jun 27 15:35:09 2010 +0000 doc: batman-adv/Multicast-ideas >--------------------------------------------------------------- b01a61cb19e248e64560e17c6b0f78261b2d0e37 batman-adv/Multicast-ideas.textile | 39 ++++++++++++++++++++++++++------------ 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index fa83482c..75e9c085 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -1,23 +1,36 @@ -= BATMAN-Adv Multicast Awareness = -== Idea == -The intention is to decrease the broadcast domain for multicast packets, especially large multicast data packets should not be broadcasted through the whole mesh. += B.A.T.M.A.N.-Adv Multicast Awareness = -== Concepts and classifications == -=== Reactive, multicast group specific, sender-based distribution infrastructure initiation === -Similar to batman-adv's current HNA sensing mechanisms, batman-adv would look for multicast packets going into its bat0 interface and memorize the according multicast MAC addresses which represent one multicast group id each in IPv6 or a small set of multicast group ids in IPv4. On sensing, the according batman-adv node will add MCA (= multicast sender announcements) entries to each OGM. +{{{ +#!div style="width: 40em; text-align: justify" + +As batman-adv has full control over all data traffic flowing through the mesh network multicast traffic also falls under its jurisdiction. At the time of writing this document batman-adv handles the multicast traffic by flooding the whole network with it. Although this approach is suitable for common multicast groups sending a small number of packets (e.g. IPv6 neighbor announcements) it fails its purpose when it comes to large multicast data packets (e.g. multimedia streaming). This document aims to provide a concept for multicast optimizations, especially when it comes to these large data packets. + +=== The concept === + +To be truly multicast aware each batman-adv node needs to perform the following tasks: + + * detection of own multicast groups + * let the network know which multicast groups this node is belonging to and also learn who else is part of this group + * deliver the data to the entire mutlicast group in the most efficient way + +'''multicast group sensing''' -=== Proactive, periodic distribution infrastructure maintenance === -A batman-adv node receiving an OGM with MCA entries will check its local multicast group table. If it is a member of the same multicast group fetched from the received OGM's MCAs, it will start a periodic unicast stream to the other member(s) of the same multicast group (packet type description, see mcast_pathsel_packet). This technique for maintenance is similar to the one used in ODMRP. The default interval would/should be 500ms for them, the purge timeout about 3 to 5 times higher - the higher the purge timeout, the more robust the infrastrucutre in a very mobile environment would be, but the larger the distribution infrastructure / broadcast domain would become. +Similar to batman-adv's current HNA sensing mechanisms, batman-adv would look for multicast packets going into its bat0 interface and memorize the according multicast MAC addresses which represent one multicast group id each in IPv6 or a small set of multicast group ids in IPv4. (Reactive, multicast group specific, sender-based distribution infrastructure initiation) -=== multicast data packet delivery === -In the beginning when an optimised distribution infrastructure has just started to build up, multicast data packets should still be broadcasted. The advantage of this would be, that no buffering or packet dropping would have to be done. +'''multicast group participation''' -After about 5 seconds (then all nodes with a reasonable ogm receiving quality should have gotten the MCA), multicast data packets would still be encapsulated in a batman bcast_packet, but with the packet type set to BAT_MCAST. Another, intermediate node receiving this on-link broadcasted packet only rebroadcasts the packet if the following checks apply: - * Is this a multicast packet which shall take an optimised path (bcast_packet.packet_type == BAT_MCAST)? +A batman-adv node will flood the whole mesh network with the multicast groups it belongs to (it further will be referenced as MCA - multicast sender announcements). +When A batman-adv node receiving an OGM with MCA entries will check its local multicast group table. If it is a member of the same multicast group fetched from the received OGM's MCAs, it will start a periodic unicast stream to the other member(s) of the same multicast group (packet type description, see mcast_pathsel_packet). This technique for maintenance is similar to the one used in ODMRP. The default interval would/should be 500ms for them, the purge timeout about 3 to 5 times higher - the higher the purge timeout, the more robust the infrastrucutre in a very mobile environment would be, but the larger the distribution infrastructure / broadcast domain would become. (Proactive, periodic distribution infrastructure maintenance) + +'''multicast data packet delivery''' + +Multicast data packets would still be treated as standard batman-adv data broadcast packet, but receives an additional flag to mark it as optimized multicast traffic (the flag is called BAT_MCAST). This packet type will only be rebroadcasted if the following conditions are met: * Did I receive a mcast_pathsel_packet for the same multicast group before (mcast_pathsel_packet.src == ethhdr.dst)? * Did I receive the matching mcast_pathsel_packet(s) via the same neighbor (ethhdr(mcast_pathsel_packet).src == ethhdr.src)? +This mechanism requires the multicast group infrastructure to be known. Shortly after creating/joining a new group this won't be the case. During the build up phase multicast data packets should still be broadcasted to ensure fast delivery. + == New batman-adv packet types == === BAT_MCAST === A multicast data packet that shall use an optimized path will still use a batman bcast_packet header, but set packet_type to BAT_MCAST. @@ -78,3 +91,5 @@ A node can easily detect a receiver-host on its local network by listening to IG * ODMRP [[http://tools.ietf.org/html/draft-ietf-manet-odmrp-04|draft-ietf-manet-odmrp…, * SMF [[http://tools.ietf.org/html/draft-ietf-manet-smf-10|draft-ietf-manet-smf-10]] * PGM [[http://tools.ietf.org/html/rfc3208|rfc3208]] + +}}}

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multicast-ideas: adding (a) killer-optimization-feature for multicast-forwarding (010d4d98)
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 010d4d98afd068dfabc0dc15b4e92d120423cc13 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Mon Jun 28 23:17:37 2010 +0000 doc: batman-adv/Multicast-ideas: adding (a) killer-optimization-feature for multicast-forwarding >--------------------------------------------------------------- 010d4d98afd068dfabc0dc15b4e92d120423cc13 batman-adv/Multicast-ideas.textile | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index d10c0d3a..b83b5816 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -74,6 +74,13 @@ If so, the intermediate node should not rebroadcast this multicast data packet. === converting BAT_MCAST to unicast if just one member on path left === A node knows, whether there might be a single multicast member of the same group on the forwarding path left (or better: whether all but one multicast members are behind the neighbor we just received the multicast-data packet from) because of the previously received, broadcasted OGMs (+ MCA entries). In this case, the forwarding node can unwrapp the multicast data packet and wrap it into a batman unicast-header to this single destination instead. This will greatly increase the reliability and throughput to such a remote multicast member because the rate selection algorithms being able to select an optimal value instead of just broadcasting it with the default value of 11MBit/s on the one hand and the now acknowledged transfer for the rest of the path on the other. +=== switching between multicast and unicast forwarding === +This is basically an extension of the optimization stated above. But instead of converting a BAT_MCAST to unicast only once at the end of a packets journey, this optimization here also suggests to convert the means of tranportation back and forth: If a multicast data packets journey would get to a crotch, so two different forwarding nodes as next hops for the data, then the packet should be broadcasted by the node on the crotch with the advantage of only blocking the wifi medium once (as the basic algorithm is doing it, too). However, if a node which is part of the distribution infrastructure and knows, that there's just one recipient, just one next hop being a forwarding node, then the multicast data packet should be send as a unicast packet (with a special packet structure *). + +A forwarding node of a certain multicast group distribution infrastructure can detect if it is on a crotch without any additional communication need, it just has to memorise the following more entry: Of one multicast-group's mcast_pathsel stream(s) (the unicast packets maintaining an efficient distribution infrastructure), not only memorize the group and the previous senders mac address, but also the next hop destination mac address(es). If this forwarding node has multiple of these matching next hop destination addresses then it knows it is on a crotch. + +So if a forwarding node sitting on a crotch receives a multicast data packet via unicast, then it has to reencapsulate it in a broadcast header with multicast flag. If a forwarding node ''not'' sitting on a crotch receives a multicast data packet via broadcast, then it has to reecapsulate it in a mcast header with unicast destination. Otherwise it can forward the packet according to its table without having to reencapsulate it. + === NAKs between neighbors === In wireless networks all unicast traffic is being acknowledged and in case of a loss resend until a certain amount of times. We usually don't have this feature for broadcasted packets, especially because of the mobile characteristics of the mesh it can be quite tough to tell on link layer if there was no ACK because of interference or because the neighbor got out of range. It is therefore a lot easier to use NAKs in this case - if a neigbor who is part of the distribution infrastructure detects a missing sequence number, it could request it again and receive it via unicast from the according neighbor. PGM ([http://tools.ietf.org/html/rfc3208 RFC3208])is also using the NAK approach on the transport layer for multicast packets for instance.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multicast-ideas (78c917a3)
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 78c917a37cbb65f02ff288afeea8c2811062098b Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Sun Jun 27 01:45:38 2010 +0000 doc: batman-adv/Multicast-ideas >--------------------------------------------------------------- 78c917a37cbb65f02ff288afeea8c2811062098b batman-adv/Multicast-ideas.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index 396f0535..1d714145 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -56,7 +56,7 @@ If already about 50%25 of the nodes are part of the same multicast group, then s Another optimization for this broadcasting approach in dense multicast networks would be for a node to still check the following: * Are all other multicast members I know of behind the same neighbor I just received the multicast data packet from? -If so, the intermediate node could drop this multicast data packet. For this approach multicast packets should never be forwarded as BAT_BCAST packets, a dense/sparse-flag in the batman packet header would be needed instead. +If so, the intermediate node should not rebroadcast this multicast data packet. For this approach multicast packets should never be forwarded as BAT_BCAST packets, a dense/sparse-flag in the batman packet header would be needed instead. === converting BAT_MCAST to unicast if just one member on path left === A node knows, whether there might be a single multicast member of the same group on the forwarding path left (or better: whether all but one multicast members are behind the neighbor we just received the multicast-data packet from) because of the previously received, broadcasted OGMs (+ MCA entries). In this case, the forwarding node can unwrapp the multicast data packet and wrap it into a batman unicast-header to this single destination instead. This will greatly increase the reliability and throughput to such a remote multicast member because the rate selection algorithms being able to select an optimal value instead of just broadcasting it with the default value of 11MBit/s on the one hand and the now acknowledged transfer for the rest of the path on the other.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017