commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Troubleshooting (fc2cfafd)
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 fc2cfafd4618cce7a0db3d9ba2cee6b01dd53df6 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Mar 26 20:22:46 2011 +0000 doc: batman-adv/Troubleshooting >--------------------------------------------------------------- fc2cfafd4618cce7a0db3d9ba2cee6b01dd53df6 batman-adv/Troubleshooting.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Troubleshooting.textile b/batman-adv/Troubleshooting.textile index 7fca62e7..59649364 100644 --- a/batman-adv/Troubleshooting.textile +++ b/batman-adv/Troubleshooting.textile @@ -1,6 +1,6 @@ h1. B.A.T.M.A.N.-Adv Troubleshooting -_B.A.T.M.A.N.-Adv does net work as expected, what can I do now?_ +h2. B.A.T.M.A.N.-Adv does net work as expected, what can I do now? First, try to minimise the complexity of your setup, i.e. just try to build a simple mesh network between two devices. Usually just following the [[batman-adv-quick-start-guide|quick-start-guide]] is a good way to start with.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/ELP (cfe2dfb0)
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 cfe2dfb025ba58364ccf68a07334b24ae9fd83e9 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Mar 26 20:28:20 2011 +0000 doc: batman-adv/ELP >--------------------------------------------------------------- cfe2dfb025ba58364ccf68a07334b24ae9fd83e9 batman-adv/ELP.textile | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/batman-adv/ELP.textile b/batman-adv/ELP.textile index 4514895b..0c28cade 100644 --- a/batman-adv/ELP.textile +++ b/batman-adv/ELP.textile @@ -214,11 +214,11 @@ Now node R moves from B to A within the first second, so he'll arrive at B befor *t = 0:* -[[Image(NDP-mobile-loop-0s.png, 20%25)]] +!NDP-mobile-loop-0s.png! *t = 1:* -[[Image(NDP-mobile-loop-1s.png, 20%25)]] +!NDP-mobile-loop-1s.png! 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. @@ -228,4 +228,3 @@ The following [[table]] will hold some more in detail information with the times * 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. -</code></pre>

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bcast-hidden-node (0cb46cb8)
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 0cb46cb8f00729d51c74298e09c34f3ddd3637bb Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Mar 26 20:27:50 2011 +0000 doc: batman-adv/Bcast-hidden-node >--------------------------------------------------------------- 0cb46cb8f00729d51c74298e09c34f3ddd3637bb batman-adv/Bcast-hidden-node.textile | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/batman-adv/Bcast-hidden-node.textile b/batman-adv/Bcast-hidden-node.textile index d40d97a0..2d05f5e5 100644 --- a/batman-adv/Bcast-hidden-node.textile +++ b/batman-adv/Bcast-hidden-node.textile @@ -1,16 +1,21 @@ -= Hidden Node Problem = -See [http://en.wikipedia.org/wiki/Hidden_node here] for a general description of the problem. +h1. Hidden Node Problem -= Hidden Node Problem and NDP/OGMs = -Especially in indoor scenarios like the one shown below where corners and thick walls are involved, hidden nodes can be a severe problem. Usually activating [http://en.wikipedia.org/wiki/802.11_RTS/CTS RTS/CTS] is a common way of solving this problem at least to some degree. However, [http://en.wikipedia.org/wiki/802.11_RTS/CTS RTS/CTS] can only be applied for unicast packets. Therefore a node C sending a lot of data packets to B, even with RTS/CTS those packets will interfere with BATMAN's broadcast packets (e.g. [http://www.open-mesh.org/wiki/batman-adv-ndp NDP] packets or OGMs). The effect is, that with this stream, only the TQ from A -> B will decrease dramatically, the rest will stay relatively equal. +See "here":http://en.wikipedia.org/wiki/Hidden_node for a general description of the problem. + + +h1. Hidden Node Problem and NDP/OGMs + +Especially in indoor scenarios like the one shown below where corners and thick walls are involved, hidden nodes can be a severe problem. Usually activating "RTS/CTS":http://en.wikipedia.org/wiki/802.11_RTS/CTS is a common way of solving this problem at least to some degree. However, "RTS/CTS":http://en.wikipedia.org/wiki/802.11_RTS/CTS can only be applied for unicast packets. Therefore a node C sending a lot of data packets to B, even with RTS/CTS those packets will interfere with BATMAN's broadcast packets (e.g. "NDP":http://www.open-mesh.org/wiki/batman-adv-ndp packets or OGMs). The effect is, that with this stream, only the TQ from A -> B will decrease dramatically, the rest will stay relatively equal. In the worst case, this can lead to route flapping to the shorter path, due to all these lost packets, A will switch its route towards C to the direct one if occasionally some NDP/OGMs had been received over this link, which might however not be usable for i.e. TCP traffic due to a too high packet loss. -[[Image(wiki:bcast-hidden-node:topology-scheme.png, 25%25)]] +!topology-scheme.png! + + +h1. Solution Proposal -= Solution Proposal = In BATMAN-Adv. we have the possibility to control not only the routing protocols control packets (like NDP packets or OGMs), but also the data flow. Furthermore the period when a node is sending an NDP packet / OGM is relatively constant (+ some jitter), which allows finding a solution which does not need an active channel reserving like RTS/CTS. Roughly the following steps could be done to decrease the number of lost control packets in case of hidden nodes: - * When sending an NDP packet, attach both the neighbor's NDP interval and the relative interval time offset. In other words, also add the amount of milliseconds when this node expects to receive the next NDP packet from this neighbor. - * Any neighbor receiving an NDP packet with this new information then knows at which times sending data packets could result in collisions (due to e.g. hidden nodes). - * A node then halts its unicast packet transmissions at these times. +* When sending an NDP packet, attach both the neighbor's NDP interval and the relative interval time offset. In other words, also add the amount of milliseconds when this node expects to receive the next NDP packet from this neighbor. +* Any neighbor receiving an NDP packet with this new information then knows at which times sending data packets could result in collisions (due to e.g. hidden nodes). +* A node then halts its unicast packet transmissions at these times. The benefit of this also is, that even if there was no hidden node problem in such a scenario, still a congested links (e.g. saturated bc. of many UDP packet transfers) could lead to switching to the unusable, direct link A - C. This solution also eliminates the influence of congestion on BATMAN's control packets. \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Compatversion (824403ea)
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 824403eaf1067c861e8265728d4c1a9709ab96eb Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Mar 26 20:24:21 2011 +0000 doc: batman-adv/Compatversion >--------------------------------------------------------------- 824403eaf1067c861e8265728d4c1a9709ab96eb batman-adv/Compatversion.textile | 45 +++++++++++++++++++++++++--------------- 1 file changed, 28 insertions(+), 17 deletions(-) diff --git a/batman-adv/Compatversion.textile b/batman-adv/Compatversion.textile index 013e1668..7dac9a84 100644 --- a/batman-adv/Compatversion.textile +++ b/batman-adv/Compatversion.textile @@ -1,30 +1,35 @@ -= batman-adv COMPAT_VERSION = +h1. 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, v2011.0.0* || unicast fragmentation added, gateway flags were readded || -|| 13 || next, v2010.2.0 || gateway flags were removed || +| 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, v2011.0.0 | 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. -== COMPAT_VERSION size problem == + +h2. COMPAT_VERSION size problem + Currently the size of the version field in all packets is a single byte. This means that after COMPAT_VERSION 255 no new version can be assigned. Thus a variable-length number must be used. -=== 255-COMPAT_VERSION for second byte indicator === + +h3. 255-COMPAT_VERSION for second byte indicator + The solution by dotslash is to use a second byte after the current version field when the first version field reaches 255. The COMPAT_VERSION_2 field is now increased as usual and keep COMPAT_VERSION as 255. @@ -32,16 +37,22 @@ This seems to be ineffective as only 510 numbers can be encoded that way with tw So the amount of information per bit converges against 0. -=== MSB as indicator for new byte === + +h3. MSB as indicator for new byte + The most significant bit in each byte is used to determine if the next byte should also be read. 127 would be encoded as 0x7F and 128 as 0x8000. This means that we can encode every number in its little bit encoding with the maximum overhead of 1 byte. So "only" 2**(bytes*8-1) numbers are stored for each amount of bytes. This means every second number needs an extra byte. So the amount of information per bit is 1. The average amount of overhead against a method which magically know the needed amount of bytes to encode/decode a number is 1/2 byte, but the size of the number is not limited by the encoding. -=== EBML encoding === + +h3. EBML encoding + Not usable because the most significant 1 and the leading zeros define the amount of bytes. Thus we had to use that 1 as MSB already for our one byte version. -=== Leading bits define number of bytes === + +h3. Leading bits define number of bytes + The leading 4 bit (as example) in the first byte can be used to encode the length of the data. So the maximum of 2**4 byte can be used when 0000 means 1 byte to use. This has the problem that 0 for example could be encoded in 2**4 ways.

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Emulation (01bddbf0)
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 01bddbf0272b89c892ec246138858f08e4301483 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Mar 26 20:35:44 2011 +0000 doc: open-mesh/Emulation >--------------------------------------------------------------- 01bddbf0272b89c892ec246138858f08e4301483 open-mesh/Emulation.textile | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/open-mesh/Emulation.textile b/open-mesh/Emulation.textile index b71173df..bd596e8c 100644 --- a/open-mesh/Emulation.textile +++ b/open-mesh/Emulation.textile @@ -1,4 +1,3 @@ - h1. Emulation Setup @@ -57,12 +56,12 @@ ifconfig bat0 inet 192.168.0.${NUM} up 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: +A sample openwrt image can be found here: http://packetmixer.de/openwrt-x86-jffs2-128k.image -* "h3. vde_switch +h3. 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 "vde_switch":http://wiki.virtualsquare.org/wiki/index.php/VDE_Basic_Networking 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. @@ -78,7 +77,7 @@ 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 h3. wirefilter

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/New_papers (7756b5d8)
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 7756b5d88995ef49f0248449b3e2285e78c86b45 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Mar 26 20:43:26 2011 +0000 doc: open-mesh/New_papers >--------------------------------------------------------------- 7756b5d88995ef49f0248449b3e2285e78c86b45 open-mesh/New_papers.textile | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/open-mesh/New_papers.textile b/open-mesh/New_papers.textile index c929cdf7..ece05786 100644 --- a/open-mesh/New_papers.textile +++ b/open-mesh/New_papers.textile @@ -1,30 +1,31 @@ This is just a list of papers which need a review before going to the experience site: -h1. "free" papers = - Wi-Me - Wireless Mesh Network Implementation (K. Babu, L.M. Cortes-Pena, P. Shah, S.S. Krishnan) === +h1. "free" papers - Compares BATMAN and OLSR with a static routing scheme in a small test bed. +h2. Wi-Me - Wireless Mesh Network Implementation (K. Babu, L.M. Cortes-Pena, P. Shah, S.S. Krishnan) + +Compares BATMAN and OLSR with a static routing scheme in a small test bed. * http://users.ece.gatech.edu/~cortes/files/Wi-Me.pdf -h3. Experimental evaluation of two open source solutions for wireless mesh routing at layer two (R.G. Garroppo, S. Giordano, L. Tavanti) +h2. Experimental evaluation of two open source solutions for wireless mesh routing at layer two (R.G. Garroppo, S. Giordano, L. Tavanti) - Compares batman-adv and open80211s in a small testbed. +Compares batman-adv and open80211s in a small testbed. * http://wwwtlc.iet.unipi.it/research/ggt-iswpc10.pdf -h3. WMM - Wireless Mesh Monitoring +h2. WMM - Wireless Mesh Monitoring +Introduction to WMMs and some implementations like AODV, OLSR, BATMAN ... - Introduction to WMMs and some implementations like AODV, OLSR, BATMAN ... * http://www.gsd.inesc-id.pt/~ler/reports/ricardopinto-midterm.pdf -h3. more resources +h2. more resources * find some more: http://scholar.google.com/scholar?start=20&q=BATMAN+OLSR&hl=en&as_sdt=2000

1 0

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

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/FAQ (e8c62a67)
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 e8c62a67183a473ad7d43adef20a7b721919ab5f Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Sat Mar 26 18:15:15 2011 +0000 doc: open-mesh/FAQ >--------------------------------------------------------------- e8c62a67183a473ad7d43adef20a7b721919ab5f open-mesh/FAQ.textile | 76 +++++++++++++++++++++++++-------------------------- 1 file changed, 38 insertions(+), 38 deletions(-) diff --git a/open-mesh/FAQ.textile b/open-mesh/FAQ.textile index cc6ed3eb..71f57f96 100644 --- a/open-mesh/FAQ.textile +++ b/open-mesh/FAQ.textile @@ -1,87 +1,85 @@ +h1. FAQ -= FAQ = -{{{ -#!div style="width: 46em; text-align: justify" +If you are missing a question/answer (quite likely) please use the [[MailingList|BATMAN mailing list]] or [[IRC|IRC channel]] to trigger us. -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? === +h2. 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 [wiki:Emulation read our emulation document]. -=== 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 [[Emulation|read our emulation document]]. -What kind of security do you need? Security is a big field. Maybe you just -mean encryption and authentication..... -When you only want to make the whole wlan stuff unreadable for the outside, -you could just use WPA_NONE. But this doesn't resolve the problem that the key -could leak and make the mesh attackable - but that is something which could -always happen. So it is probably not a solution for wifi community projects, but for -mesh networks controlled by a company. +h2. How to make my mesh network secure ? -There are other ideas for traffic over batman-adv. Just forget about -encrypting your data on the wifi layer, but instead do everything some layers above. -Some people experimented with the idea of implementing the needed authentication and -encryption over IPsec. -And most of the encryption and authentication stuff has to be resolved by the -user and not by the network provider. This means https for sensible data -instead of http, ssh instead of telnet, pop3s instead of pop3 and so on. +What kind of security do you need? Security is a big field. Maybe you just mean encryption and authentication..... -So it really depends what you want and cannot be resolved in a "security for -everything, against any attack and for every purpose" blob. +When you only want to make the whole wlan stuff unreadable for the outside, you could just use WPA_NONE. But this doesn't resolve the problem that the key could leak and make the mesh attackable - but that is something which could always happen. So it is probably not a solution for wifi community projects, but for mesh networks controlled by a company. +There are other ideas for traffic over batman-adv. Just forget about encrypting your data on the wifi layer, but instead do everything some layers above. Some people experimented with the idea of implementing the needed authentication and encryption over IPsec. -=== Why does batman need so much time to detect a "dead" node ? === +And most of the encryption and authentication stuff has to be resolved by the user and not by the network provider. This means https for sensible data instead of http, ssh instead of telnet, pop3s instead of pop3 and so on. + +So it really depends what you want and cannot be resolved in a "security for everything, against any attack and for every purpose" blob. + +h2. 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. -=== Understanding the version and compatibility number === + +h2. 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? === + +h2. 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 === + +h2. 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 -}}} +</pre> Then start batmand and pipe the output into netcat: -{{{ +<pre> batmand -d 4 <your_interfaces> | nc -l -p <any_unused_port> -}}} +</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 -}}} +</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. ;-) @@ -91,10 +89,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? === + +h2. 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. -}}} +</pre>

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multicast-ideas (0f0ddd84)
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 0f0ddd843ab07123991ba782dd5bc2845b070e54 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Mar 26 20:13:55 2011 +0000 doc: batman-adv/Multicast-ideas >--------------------------------------------------------------- 0f0ddd843ab07123991ba782dd5bc2845b070e54 batman-adv/Multicast-ideas.textile | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index b6e02247..65d4520a 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -1,11 +1,6 @@ - - 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. @@ -35,14 +30,16 @@ Multicast data packets would still be treated as standard batman-adv data broadc 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. -h2. New batman-adv packet types == - BAT_MCAST === +h2. New batman-adv packet types + +h3. 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. h3. mcast_pathsel_packet -<pre> +<pre></code> /* marks the path for multicast streams */ struct mcast_pathsel_packet { uint8_t packet_type; /* BAT_MCAST_PSEL */ @@ -51,16 +48,17 @@ struct mcast_pathsel_packet { uint8_t destr6; uint8_t ttl; uint8_t align; -} +attribute+((packed)); +} __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). ----- -h2. Further Extensions == - Distribution infrastructure initiation - bursting === +h2. Further Extensions + +h3. 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.)

1 0

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

14 Jul '17

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017