commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Release-todo (90dd8bea)
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 90dd8bea8b9b63c15a4e8004ed681070cafd62e3 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Sat Sep 4 13:27:14 2010 +0000 doc: batman-adv/Release-todo >--------------------------------------------------------------- 90dd8bea8b9b63c15a4e8004ed681070cafd62e3 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 61d52c44..a3279100 100644 --- a/batman-adv/Release-todo.textile +++ b/batman-adv/Release-todo.textile @@ -8,7 +8,7 @@ This page contains a checklist of things that need to be done for a release. * [ ] make sure all code contains the release version strings * [x] update copyright years (if needed) - * [ ] remove dead code (if any) + * [x] remove dead code (if any) * [x] check against kernel versions * [ ] check that maint branch is merged in next * [ ] check for open patches on the ml

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Release-todo: Create new release todo (87c78cf6)
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 87c78cf6e56479c852024fed04d09393bda803f2 Author: Sven Eckelmann <sven(a)narfation.org> Date: Fri Aug 27 17:40:31 2010 +0000 doc: batman-adv/Release-todo: Create new release todo >--------------------------------------------------------------- 87c78cf6e56479c852024fed04d09393bda803f2 batman-adv/Release-todo.textile | 40 +++++++++++++++++++++++++--------------- 1 file changed, 25 insertions(+), 15 deletions(-) diff --git a/batman-adv/Release-todo.textile b/batman-adv/Release-todo.textile index db36a2c7..59cd6b49 100644 --- a/batman-adv/Release-todo.textile +++ b/batman-adv/Release-todo.textile @@ -6,30 +6,40 @@ This page contains a checklist of things that need to be done for a release. '''Code''' - * [x] make sure all code contains the release version strings - * [x] update copyright years (if needed) - * [x] remove dead code (if any) - * [x] svn/git tag release - * [-] change version strings inside the trunk (strip beta etc) - * [-] change version strings after release to next version - * [x] check against kernel versions + * [ ] make sure all code contains the release version strings + * [ ] update copyright years (if needed) + * [ ] remove dead code (if any) + * [ ] check against kernel versions + * [ ] check that maint branch is merged in next + * [ ] check for open patches on the ml + * [ ] git tag release + '''Documentation''' - * [x] build changelog - * [x] update README - * [x] write release announcement + * [ ] build changelog + * [ ] update README + * [ ] write release announcement '''Release''' - * [x] build package tar.gz (replace symlinks with real files) and generate checksums - * [x] move packages/checksums to stable/sources / create symlinks from releases - * [x] update download links in the trac downloads page - * [x] send release mail + * [ ] build package tar.gz and generate checksums + * [ ] move packages/checksums to stable/sources / create symlinks from releases + * [ ] update download links in the trac downloads page + * [ ] send release mail * [ ] update IRC channel topic '''Distributions''' + * [ ] update openwrt package - * [x] inform batman package maintainer + * [ ] inform batman package maintainer + + +'''Aftershow''' + + * [ ] Merge differences (README, CHANGELOG, ...) into master branch + * [ ] Merge current next into maint (must be fast-forward or pre-tagging steps were done wrong) + * [ ] Get patches for next release from master-rebase/batctl-rebase repository + * [ ] Rebase patches in next on top of linux-next and send it to kernel maintainers for future kernels \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Release-todo (77e53dc0)
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 77e53dc009a30f490708ad4b4a82dd717cb66b47 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Sat Sep 4 00:26:17 2010 +0000 doc: batman-adv/Release-todo >--------------------------------------------------------------- 77e53dc009a30f490708ad4b4a82dd717cb66b47 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 59cd6b49..61d52c44 100644 --- a/batman-adv/Release-todo.textile +++ b/batman-adv/Release-todo.textile @@ -7,9 +7,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/Building-with-openwrt (9c9a23eb)
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 9c9a23ebfb15941d1f50830bfd04ecb2d9f93057 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Thu Aug 26 14:44:05 2010 +0000 doc: batman-adv/Building-with-openwrt >--------------------------------------------------------------- 9c9a23ebfb15941d1f50830bfd04ecb2d9f93057 batman-adv/Building-with-openwrt.textile | 141 +++++++++++++------------------ 1 file changed, 60 insertions(+), 81 deletions(-) diff --git a/batman-adv/Building-with-openwrt.textile b/batman-adv/Building-with-openwrt.textile index 90bafed5..d8b846d7 100644 --- a/batman-adv/Building-with-openwrt.textile +++ b/batman-adv/Building-with-openwrt.textile @@ -1,177 +1,156 @@ += Building B.A.T.M.A.N. Advanced with OpenWRT = -h1. Building B.A.T.M.A.N. Advanced with [[OpenWRT]] +{{{ +#!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. -<pre> -<code class="div"> +=== Getting the OpenWRT build environment === -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. +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: - -h3. 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 (backfire 10.03 at the point of writing this document) via SVN: - -<pre> +{{{ svn co svn://svn.openwrt.org/openwrt/tags/backfire_10.03 openwrt -</code></pre> +}}} 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). -<pre> +{{{ cd openwrt make menuconfig -</code></pre> - -+Note+: The batman-adv package is not there yet because it needs to be activated seperately (see the following steps). +}}} +__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 folder: -<pre> +{{{ cd openwrt make -</code></pre> - -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 "the [[OpenWRT]] project website":http://www.openwrt.org. +}}} +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]. -h3. Adding the batman-adv package +=== Adding the batman-adv package === +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 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. +__Adding the stable version__: [[BR]] -+Adding the stable version+: - - -<pre> +{{{ scripts/feeds update scripts/feeds install kmod-batman-adv -</code></pre> -_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"_. - -+Adding the developer version+: +}}} +''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"''. +__Adding the developer version__: [[BR]] Append the following line to your openwrt feed configuration file (either feeds.conf or feeds.conf.default): -<pre> +{{{ src-svn batman http://downloads.open-mesh.org/svn/openwrt-feed/ -</code></pre> +}}} Update the package information and add the development package: -<pre> +{{{ scripts/feeds update scripts/feeds install kmod-batman-adv-devel -</code></pre> - - +}}} -h3. Configuring the batman-adv package +=== Configuring the batman-adv package === -As soon as the batman-adv package has been added, it will show up in the [[OpenWRT]] package menu: +As soon as the batman-adv package has been added, it will show up in the OpenWRT package menu: -+stable version+: - -<pre> +__stable version__: [[BR]] +{{{ Kernel modules ---> Network Support ---> kmod-batman-adv -</code></pre> - -+developer version+: +}}} -<pre> +__developer version__: [[BR]] +{{{ Kernel modules ---> Network Support ---> kmod-batman-adv-devel -</code></pre> +}}} 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 === -h3. Advanced features - - -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: - -+stable version+: +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: -<pre> +__stable version__: [[BR]] +{{{ cd openwrt make package/batman-advanced/clean make package/batman-advanced/compile V=99 -</code></pre> +}}} -+developer version+: - -<pre> +__developer version__: [[BR]] +{{{ cd openwrt make package/batman-adv-devel/clean make package/batman-adv-devel/compile V=99 -</code></pre> +}}} The package offers an easy way to apply custom patches whenever batman-adv is built. Simply copy your patches into the "patches" folder inside the package directory (you have to create the folder in case it does not exist yet). The location of the folder depends on which package you want to patch: -+stable version+: - -<pre> +__stable version__: [[BR]] +{{{ openwrt/feeds/packages/net/batman-advanced/patches -</code></pre> - -+developer version+: +}}} -<pre> +__developer version__: [[BR]] +{{{ openwrt/feeds/batman/batman-adv-devel/patches -</code></pre> +}}} It is also possible to modify the batman-adv version if you ever wanted to build an older/newer version than configured in the package: -+stable version+: - +__stable version__: [[BR]] Adjust the PKG_VERSION variable to download & build the stable release you are interested in. -<pre> +{{{ cat openwrt/feeds/packages/net/batman-advanced/Makefile [..] PKG_VERSION:=2010.0.0 [..] -</code></pre> - -+developer version+: +}}} +__developer version__: [[BR]] Ajust the PKG_REV variable to download & build the SVN revision you are interested in: -<pre> +{{{ cat openwrt/feeds/batman/batman-adv-devel/Makefile [..] PKG_REV:=1764 [..] -</code></pre> +}}} -In case you experience kernel oopses it might prove helpful to enable the kernel symbol table which translates the cryptic numbers which are part of each kernel oops log into readable function names. This calltrace can help developers to analyze the problem. Use [[OpenWRT]]'s config menu to enable the kernel symbol table and rebuild your image: +In case you experience kernel oopses it might prove helpful to enable the kernel symbol table which translates the cryptic numbers which are part of each kernel oops log into readable function names. This calltrace can help developers to analyze the problem. Use OpenWRT's config menu to enable the kernel symbol table and rebuild your image: -<pre> +{{{ make menuconfig Global build settings ---> Compile the kernel with symbol table information -</code></pre> +}}} -If you can't find this option you are using an older [[OpenWRT]] version which doesn't offer this config switch in the main menu. You have to modify the kernel settings directly: +If you can't find this option you are using an older OpenWRT version which doesn't offer this config switch in the main menu. You have to modify the kernel settings directly: -<pre> +{{{ make kernel_menuconfig General setup ---> Configure standard kernel features (for small systems) ---> Load all symbols for debugging/ksymoops -</code></pre> +}}} -</code></pre> +}}}

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Compatversion (6751060a)
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 6751060a6ddef44da8aa9ddb6ec794db7e67f24e Author: Sven Eckelmann <sven(a)narfation.org> Date: Wed Sep 1 22:56:13 2010 +0000 doc: batman-adv/Compatversion >--------------------------------------------------------------- 6751060a6ddef44da8aa9ddb6ec794db7e67f24e batman-adv/Compatversion.textile | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/batman-adv/Compatversion.textile b/batman-adv/Compatversion.textile new file mode 100644 index 00000000..62137173 --- /dev/null +++ b/batman-adv/Compatversion.textile @@ -0,0 +1,21 @@ += batman-adv COMPAT_VERSION = + +COMPAT_VERSION in packet.h is used to identify an incoming packet and check if it can processed by the current version. The packet structure should be identified by this version. The stuff which appears in a packet jumps a little bit with each version because we change stuff in trunk/master and in next and import those changes to the packet structure out-of-order. + +Following changes were identified and documented. The changes are to the last COMPAT_VERSION and not to the last change in a branch. So "added xyz on master, removed xyz on next and re-added xyz on master" does only mean that xyz was always there in master, but the version in next dropped that change and thus generated a new COMPAT_VERSION. + +|| Version || Branch || Changes || +|| 1 || trunk || Initial definitions of batman_packet, icmp_packet, unicast_packet, bcast_packet, ethernet type 0x0842 || +|| 5 || trunk || information in batman_packet was reordered, tq, old_orig and hnas were added || +|| 6 || trunk, v0.1 || vis_packet type added, version fields added to each packet, ethernet type changed to 0x4305 || +|| 7 || trunk || unused gw flags removed, reordered icmp and batman packet || +|| 8 || trunk, v0.2, v0.2.1, v2010.0.0 || source field introduced in vis packets || +|| 9 || trunk || Gateway flags added to batman_packet, primaries_first_hop flag added for bonding, special icmp messages for route record added || +|| 10 || trunk || 32 bit sequence numbers added/changed, ttl were added to broadcasts || +|| 11 || next, v2010.1.0* || gateway flags were removed || +|| 12 || trunk || unicast fragmentation added, gateway flags were readded || +|| 13 || next, v2010.2.0* || gateway flags were removed || + +(* means future version with already defined feature set) + +There is a special COMPAT_VERSION 200 which is only used by saxnet. This version is v6 with bcast seqno protection added.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/SubmittingLinux (49ed5949)
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 49ed5949650bc6564f0d5edf85bf257a6c47205b Author: Sven Eckelmann <sven(a)narfation.org> Date: Fri Aug 20 09:02:50 2010 +0000 doc: batman-adv/SubmittingLinux >--------------------------------------------------------------- 49ed5949650bc6564f0d5edf85bf257a6c47205b batman-adv/SubmittingLinux.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/batman-adv/SubmittingLinux.textile b/batman-adv/SubmittingLinux.textile index d7358887..0ff0f8f8 100644 --- a/batman-adv/SubmittingLinux.textile +++ b/batman-adv/SubmittingLinux.textile @@ -41,8 +41,8 @@ remote: Compressing objects: 100%25 (252781/252781), done. '-(%25)-(linux)> git checkout -b maint --track origin/maint Branch maint set up to track remote branch maint from origin. Switched to a new branch 'maint' -'-(%25)-(maint)> git pull http://git.open-mesh.org/batman-adv/ maint -From http://git.open-mesh.org/batman-adv +'-(%25)-(maint)> git pull http://git.open-mesh.org/batman-adv.git maint +From http://git.open-mesh.org/batman-adv.git * branch maint -> FETCH_HEAD Updating 1a0a622..9ec2d8f Fast-forward

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/UsingBatmanGit (30aa4850)
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 30aa4850f8d1d1b51a4d6e932d98a3d388e07dee Author: Sven Eckelmann <sven(a)narfation.org> Date: Fri Aug 20 22:18:16 2010 +0000 doc: open-mesh/UsingBatmanGit >--------------------------------------------------------------- 30aa4850f8d1d1b51a4d6e932d98a3d388e07dee open-mesh/UsingBatmanGit.textile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/open-mesh/UsingBatmanGit.textile b/open-mesh/UsingBatmanGit.textile index a5eff71e..53b53172 100644 --- a/open-mesh/UsingBatmanGit.textile +++ b/open-mesh/UsingBatmanGit.textile @@ -58,6 +58,9 @@ git checkout next git cherry-pick $SHA1 }}} +{{{ +#!div style="width: 40em; text-align: justify" + '''maint branch''' The maint is a branch only maintained in git to gather bug fixes and only bugfixes for the last release which were usually picked from next.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/SubmittingLinux: rename maint branch to next (bd66b387)
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 bd66b387f6d05c0146b1440e44c520937c72c0f3 Author: Sven Eckelmann <sven(a)narfation.org> Date: Fri Aug 20 22:22:11 2010 +0000 doc: batman-adv/SubmittingLinux: rename maint branch to next >--------------------------------------------------------------- bd66b387f6d05c0146b1440e44c520937c72c0f3 batman-adv/SubmittingLinux.textile | 40 +++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/batman-adv/SubmittingLinux.textile b/batman-adv/SubmittingLinux.textile index 0ff0f8f8..7c3516f6 100644 --- a/batman-adv/SubmittingLinux.textile +++ b/batman-adv/SubmittingLinux.textile @@ -1,13 +1,13 @@ = Submitting Patches to Linux = -We currently submit patches for Linux from our maint branch. I try to give a short overview about it using some patches submitted to GregKH. +We currently submit patches for Linux from our next branch. I try to give a short overview about it using some patches submitted to GregKH. Following steps must always be done: * get the linux-integration repository (we assume that the linux branch is up to date) - * get the newest patches from maint - * merge maint into linux + * get the newest patches from next + * merge next into linux * check for compat code - * check difference with maint + * check difference with next * tag the current commit * rebase on top of previous tag * squash/cleanup patches @@ -35,15 +35,15 @@ remote: Compressing objects: 100%25 (252781/252781), done. '-(%25)-> cd linux-merge }}} -== get the newest patches from maint == +== get the newest patches from next == {{{ -'-(%25)-(linux)> git checkout -b maint --track origin/maint -Branch maint set up to track remote branch maint from origin. -Switched to a new branch 'maint' -'-(%25)-(maint)> git pull http://git.open-mesh.org/batman-adv.git maint +'-(%25)-(linux)> git checkout -b next --track origin/next +Branch next set up to track remote branch next from origin. +Switched to a new branch 'next' +'-(%25)-(next)> git pull http://git.open-mesh.org/batman-adv.git next From http://git.open-mesh.org/batman-adv.git - * branch maint -> FETCH_HEAD + * branch next -> FETCH_HEAD Updating 1a0a622..9ec2d8f Fast-forward Makefile | 34 +++++++++++++++++++++------------- @@ -74,7 +74,7 @@ Fast-forward vis.c | 14 +++++++------- vis.h | 7 ++++++- 27 files changed, 135 insertions(+), 59 deletions(-) -'-(%25)-(maint)> git push origin maint +'-(%25)-(next)> git push origin next Counting objects: 80, done. Delta compression using up to 2 threads. Compressing objects: 100%25 (52/52), done. @@ -83,20 +83,20 @@ Total 52 (delta 43), reused 0 (delta 0) Generating commit mails...done fatal: Not a valid object name master:drivers/staging/batman-adv/TODO To git+ssh://git@open-mesh.org/srv/git/ecsv/linux-merge.git - 1a0a622..9ec2d8f maint -> maint + 1a0a622..9ec2d8f next -> next }}} -== merge maint into linux == +== merge next into linux == {{{ -'-(%25)-(maint)> git checkout linux +'-(%25)-(next)> git checkout linux Checking out files: 100%25 (32337/32337), done. Switched to branch 'linux' -'-(%25)-(linux)> git merge -s subtree maint +'-(%25)-(linux)> git merge -s subtree next Auto-merging drivers/staging/batman-adv/Makefile CONFLICT (content): Merge conflict in drivers/staging/batman-adv/Makefile -CONFLICT (delete/modify): drivers/staging/batman-adv/Makefile.kbuild deleted in HEAD and modified in maint. Version maint of drivers/staging/batman-adv/Makefile.kbuild left in tree. -CONFLICT (delete/modify): drivers/staging/batman-adv/compat.h deleted in HEAD and modified in maint. Version maint of drivers/staging/batman-adv/compat.h left in tree. +CONFLICT (delete/modify): drivers/staging/batman-adv/Makefile.kbuild deleted in HEAD and modified in next. Version next of drivers/staging/batman-adv/Makefile.kbuild left in tree. +CONFLICT (delete/modify): drivers/staging/batman-adv/compat.h deleted in HEAD and modified in next. Version next of drivers/staging/batman-adv/compat.h left in tree. Auto-merging drivers/staging/batman-adv/main.c Auto-merging drivers/staging/batman-adv/originator.c Auto-merging drivers/staging/batman-adv/routing.c @@ -114,7 +114,7 @@ rm 'drivers/staging/batman-adv/compat.h' '-(%25)-(linux)> vim drivers/staging/batman-adv/Makefile '-(%25)-(linux)> git add drivers/staging/batman-adv/Makefile '-(%25)-(linux)> git commit -[linux f2204f0] Merge branch 'maint' into linux +[linux f2204f0] Merge branch 'next' into linux }}} == check for compat code == @@ -124,10 +124,10 @@ git grep compat.h drivers/staging/batman-adv/ drivers/staging/batman-adv/CHANGELOG:* all kernel version compatibility functions has been moved to compat.h }}} -== check difference with maint == +== check difference with next == {{{ -git diff maint: linux:drivers/staging/batman-adv/ +git diff next: linux:drivers/staging/batman-adv/ }}} Here you should see the

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/UsingBatmanGit: rename maint branch to next (d38a452d)
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 d38a452d64a141f6b4f5bac93b39e76fbba0171d Author: Sven Eckelmann <sven(a)narfation.org> Date: Fri Aug 20 22:09:31 2010 +0000 doc: open-mesh/UsingBatmanGit: rename maint branch to next >--------------------------------------------------------------- d38a452d64a141f6b4f5bac93b39e76fbba0171d open-mesh/UsingBatmanGit.textile | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/open-mesh/UsingBatmanGit.textile b/open-mesh/UsingBatmanGit.textile index c7a4b34c..d35a18b0 100644 --- a/open-mesh/UsingBatmanGit.textile +++ b/open-mesh/UsingBatmanGit.textile @@ -40,21 +40,21 @@ The idea is that all upcoming changes are built on top of the SVN, so that chang In fact you will never work with this branch itself but one of the other branches. -'''maint branch''' +'''next branch''' -The maint is a branch only maintained in git to gather bug fixes for the latest release and well tested features taken from the master branch. Cherry-pick is used to get commits from the master branch and git-am to insert patches from mailboxes. +The next is a branch only maintained in git to gather bug fixes for the latest release and well tested features taken from the master branch. Cherry-pick is used to get commits from the master branch and git-am to insert patches from mailboxes. Create branch associated with the remote-tracking branch after cloning the repository }}} {{{ -git checkout -b maint --track origin/maint +git checkout -b next --track origin/next }}} Cherry-picking a commit from master branch {{{ -git checkout maint +git checkout next git cherry-pick $SHA1 }}} @@ -63,19 +63,19 @@ git cherry-pick $SHA1 === Linux integration === -The linux-merge repository is a clone of Linus Torvalds developer branch. With the help of some git voodoo the maint branch is merged with this branch in the folder: drivers/staging/batman-adv/. If you wish to merge the latest maint branch changes into the linux branch you need to pull the newest changes in maint from the batman-adv-git repository (we assume that you created the maint branch in your local linux-merge repsitory as explained above): +The linux-merge repository is a clone of Linus Torvalds developer branch. With the help of some git voodoo the next branch is merged with this branch in the folder: drivers/staging/batman-adv/. If you wish to merge the latest next branch changes into the linux branch you need to pull the newest changes in next from the batman-adv-git repository (we assume that you created the next branch in your local linux-merge repsitory as explained above): }}} {{{ -git checkout maint -git pull http://git.open-mesh.org/batman-adv.git maint +git checkout next +git pull http://git.open-mesh.org/batman-adv.git next }}} -and merge the maint branch into this one: +and merge the next branch into this one: {{{ git checkout master -git merge -s subtree maint +git merge -s subtree next }}} {{{ @@ -104,13 +104,13 @@ git push {{{ #!div style="width: 40em; text-align: justify" -'''difference between maint and linux-integration''' +'''difference between next and linux-integration''' -If you need to see the difference between the maint branch and the batman-adv driver in drivers/staging/batman-adv/ you can run this command: +If you need to see the difference between the next branch and the batman-adv driver in drivers/staging/batman-adv/ you can run this command: }}} {{{ -git diff maint: linux:drivers/staging/batman-adv/ +git diff next: linux:drivers/staging/batman-adv/ }}} {{{ @@ -126,8 +126,8 @@ git remote add $remote_name $git_url git fetch $remote_name git checkout -b $new_branch_name $remote_name/master -git merge -s ours --no-commit maint -git read-tree --prefix=drivers/staging/batman-adv/ -u maint +git merge -s ours --no-commit next +git read-tree --prefix=drivers/staging/batman-adv/ -u next git commit -m "Add batman-adv to my new branch" }}}

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multicast-ideas: multicast: No unicast-sel-packets to one-hop destinations (1e1b5650)
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 1e1b56502d66f5fa3c53a425da79617603aa57a1 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Tue Aug 17 17:31:59 2010 +0000 doc: batman-adv/Multicast-ideas: multicast: No unicast-sel-packets to one-hop destinations >--------------------------------------------------------------- 1e1b56502d66f5fa3c53a425da79617603aa57a1 batman-adv/Multicast-ideas.textile | 120 ++++++++++++++++++++++--------------- 1 file changed, 73 insertions(+), 47 deletions(-) diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index a7c83a7d..b6e02247 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -1,89 +1,111 @@ -= B.A.T.M.A.N.-Adv Multicast Awareness = -{{{ -#!div style="width: 40em; text-align: justify" +h1. B.A.T.M.A.N.-Adv Multicast Awareness + + +<pre> +<code class="div"> 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 === + +h3. 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 +* 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''' +*multicast group sensing* 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. -'''multicast group participation''' +*multicast group participation* Each batman-adv node floods the whole mesh network with the multicast groups it belongs to (it further will be referenced as MCA - multicast sender announcements) and also maintains a list of other nodes in the network belonging to the same multicast groups. In regular intervals unicast "breadcrump" packets are sent to all members of the multicast groups this node is part of unless the other member is not a next hop (these unicast packets just need to mark the forwarding nodes). These "breadcrump" packets are used to inform intermediate nodes which may or may not be part of the multicast group that they are "in the path" of a multicast group. -'''multicast data packet delivery''' +*multicast data packet delivery* Multicast data packets would still be treated as standard batman-adv data broadcast packets, but receive an additional flag to mark them as optimized multicast traffic (the flag is called BAT_MCAST). This packet type will only be rebroadcasted if all of the following conditions are met: - * the node was marked by a "breadcrump" packet from the same originator for this specific mutlicast group - * the sequence number of this multicast packet is a new one +* the node was marked by a "breadcrump" packet from the same originator for this specific mutlicast group +* the sequence number of this multicast packet is a new one 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 === + +h2. 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. -=== mcast_pathsel_packet === -{{{ + +h3. mcast_pathsel_packet + +<pre> /* marks the path for multicast streams */ struct mcast_pathsel_packet { uint8_t packet_type; /* BAT_MCAST_PSEL */ uint8_t version; /* batman version field */ - uint8_t src[6]; /* multicast mac address */ - uint8_t dest[6]; + uint8_t srcr6; /* multicast mac address */ + uint8_t destr6; uint8_t ttl; uint8_t align; -} __attribute__((packed)); -}}} -== Pros/Cons == - * As the mcast_path_sel packets are being forwarded via unicast, they'd create a multicast topology with determining shortest, direct paths according to BATMAN's unicast metric. ADAMA-SM for instance is not optimising in this way, instead it tries to reduce the number of forwarding nodes in general (which is nice for the mesh burdon itself, but might create unusable / too long paths for certain multicast receivers in real wireless networks). +} +attribute+((packed)); +</code></pre> + +h2. Pros/Cons + +* As the mcast_path_sel packets are being forwarded via unicast, they'd create a multicast topology with determining shortest, direct paths according to BATMAN's unicast metric. ADAMA-SM for instance is not optimising in this way, instead it tries to reduce the number of forwarding nodes in general (which is nice for the mesh burdon itself, but might create unusable / too long paths for certain multicast receivers in real wireless networks). ---- -== Further Extensions == -=== Distribution infrastructure initiation - bursting === + +h2. Further Extensions == + Distribution infrastructure initiation - bursting === To decrease the time needed for the initial infrastructure creation, the multicast announcements could be send with their own packet type instead of being attached to OGMs. They could then be send in a burst of for instance 5 identical packets. Furthermore, these packets could have a rebroadcast-count which means, that also every intermediate node would rebreadcast for instance 5 identical packets again. The wait-time to switch from pure flooding of the multicast packets to the optimised path selection could then for instance be set to 1 instead of the 5 seconds. After that, such designated multicast annuncement packets could be send at a much slower interval as the OGM packets (something like 5-10 seconds for instance). (Or if there'd be the planned NDP(neighbor discovery protocol) - HELLOs - as well as optional HNA entries (so a missing HNA in an OGM not causing it to be purged on other nodes in the mesh, a designated multicast announcement packet type would not be needed for this. We could just use a small OGM with less information, but still the TQ-value and sequence numbers, too, then as otherwise the ethernet frames' payload would be zero-padded to 46 Bytes anyway which would be a waste.) -=== still broadcast smaller/rare, but important multicast packets === + +h3. still broadcast smaller/rare, but important multicast packets + The smaller the packets, the less harmful the broadcasting would be for the mesh itself. However, the broadcasting would make the transportation of these packtes more robust in most topologies. The critirea for a "small" multicast packet could be: - * An IPv4 multicast packet from the "Local Network and Internet Work Control Blocks" (224.0.0.0/24, 224.0.1.0/24 - [http://tools.ietf.org/html/rfc3171 RFC3171]). These are for instance IGMP- or mDNS-packets. - * Well-known IPv6 multicast addresses, having the transient-flag unset. These are for instance the important IPv6 neighbor- and router-discovery packets or mDNS- or DHCPv6-packets. - * Threshold-triggering: Only if there've been sent for instance 5KB/s during the last second to the same multicast group destination, start building the optimised multicast distribution infrastructure. +* An IPv4 multicast packet from the "Local Network and Internet Work Control Blocks" (224.0.0.0/24, 224.0.1.0/24 - "RFC3171":http://tools.ietf.org/html/rfc3171). These are for instance IGMP- or mDNS-packets. +* Well-known IPv6 multicast addresses, having the transient-flag unset. These are for instance the important IPv6 neighbor- and router-discovery packets or mDNS- or DHCPv6-packets. +* Threshold-triggering: Only if there've been sent for instance 5KB/s during the last second to the same multicast group destination, start building the optimised multicast distribution infrastructure. + +For a nice table of multicast IP- and MAC-address ranges, also see "this":http://en.wikipedia.org/wiki/Multicast_address nice wikipedia-article -For a nice table of multicast IP- and MAC-address ranges, also see [http://en.wikipedia.org/wiki/Multicast_address this] nice wikipedia-article -=== broadcasting in dense multicast networks === +h3. broadcasting in dense multicast networks + If already about 50%25 of the nodes are part of the same multicast group, then such an optimised multicast distribution infrastructure's gain by minimising the number of forwarding nodes is not that much and because of the very high maintenance overhead the total-"gain" would even be negative. Therefore, if a multicast member notices that there are about 50%25 of the nodes in the originator table in the same multicast group, this node would not start sending mcast_pathsel packets and send the multicast data packets via BAT_BCAST instead. 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? +* 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 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 === + +h3. 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 === + +h3. 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. The packet-type would be a new one (i.e. BAT_MCAST_UNI) and the orig-field needs to be set to the multicast address. 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 unicast header. Otherwise it can forward the packet according to its table without having to reencapsulate it. +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 unicast header. Otherwise it can forward the packet according to its table without having to reencapsulate it. + + +h3. NAKs between neighbors -=== 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. +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 ("RFC3208":http://tools.ietf.org/html/rfc3208)is also using the NAK approach on the transport layer for multicast packets for instance. + + +h3. Only send MCAs as a receiver(/sender), if there is a sender(/receiver) too -=== Only send MCAs as a receiver(/sender), if there is a sender(/receiver) too === If there is no multicast sender available anyway, then a receiver does not have to announce its multicast member presence because there'd be no need for the distribution infrastructure with no sender anyway. Especially if the multicast sender might not be statically, permanently but adhoc, temporarily available instead, this can reduce the burdon on the mesh network quite a lot if there are also a lot of multicast receivers. Of course, the other way round, the benefits would be greater if doing it the other way round - receiver-based - if there'd be more multiple senders in the same multicast group and only one receiver there at a time with a very dynamic uptime. @@ -92,17 +114,21 @@ This probably depends on the usage scenarion, but the first option should be the A node can easily detect a receiver-host on its local network by listening to IGMP- or ICMPv6-MDN packets. A sender could be detected by the multicast-destination mac of data packets - however this should not initiate the path maintenance for all kinds of multicast packets as stated above (also IGMP/ICMPv6 are being send via multicast for instance - effectively making any node receiver a sender as well otherwise). -=== Only build paths from senders to receivers === + +h3. Only build paths from senders to receivers + In most cases, a multicast member won't be a sender and receiver at the same time. In such a case, a selected multicast path from the receiver to the sender is not necessary. Two additional flags MCAST_SENDER and MCAST_RECEIVER could be attached to an MCA. A node receiving an MCA, would then only start the unicasted mcast_pathsel stream if the following requirements are matched: - * I belong to the same multicast group stated in the received MCA. - * I am a sender of the MCA's multicast group. - * The received MCA has the MCAST_RECEIVER flag set. +* I belong to the same multicast group stated in the received MCA. +* I am a sender of the MCA's multicast group. +* The received MCA has the MCAST_RECEIVER flag set. Only then an optimised multicast path would be established to the MCA's originator. -=== Resources: === - * ADAMA (-SM/DM - sparse and dense mode) - "Multicast-Routing in mobilen Ad-hoc-Netzen", Oliver Stanze, ISBN-13: 978-3832266141 - * ODMRP [http://tools.ietf.org/html/draft-ietf-manet-odmrp-04 draft-ietf-manet-odmrp-04],[http://www.hpl.hp.com/personal/Sung-Ju_Lee/abst… wcnc99.pdf], - * SMF [http://tools.ietf.org/html/draft-ietf-manet-smf-10 draft-ietf-manet-smf-10] - * PGM [http://tools.ietf.org/html/rfc3208 rfc3208] -}}} +h3. Resources: + +* ADAMA (-SM/DM - sparse and dense mode) - "Multicast-Routing in mobilen Ad-hoc-Netzen", Oliver Stanze, ISBN-13: 978-3832266141 +* ODMRP "draft-ietf-manet-odmrp-04":http://tools.ietf.org/html/draft-ietf-manet-odmrp-04,"wcnc99.pdf":http://www.hpl.hp.com/personal/Sung-Ju_Lee/abstracts/papers/wcnc99.pdf, +* SMF "draft-ietf-manet-smf-10":http://tools.ietf.org/html/draft-ietf-manet-smf-10 +* PGM "rfc3208":http://tools.ietf.org/html/rfc3208 + +</code></pre>

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017