commits July 2020

commits@lists.open-mesh.org

1 participants
76 discussions

[doc] backup-redmine/2020-07-12,master: doc: batmand/InternetTuning (7c0ebf6)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit 7c0ebf6bc344cb7c541da38fbad1405c5fab7583 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:20:35 2020 +0000 doc: batmand/InternetTuning >--------------------------------------------------------------- 7c0ebf6bc344cb7c541da38fbad1405c5fab7583 batmand/InternetTuning.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batmand/InternetTuning.textile b/batmand/InternetTuning.textile index da1a3b2..7fb7ad8 100644 --- a/batmand/InternetTuning.textile +++ b/batmand/InternetTuning.textile @@ -71,7 +71,7 @@ If you plan to attach non-batman clients to your batman internet client you have h3. batman 0.3.2 and later -The batman daemon will try to locate the iptables binary to setup the masquerading automatically. This behaviour can be disabled using the "--disable-client-nat" option. If the outgoing packets are not masqueraded (the iptables binary wasn't found / the automatism disabled) batman will switch to the "half tunnel" mode which operates without masquerading. Beware: This mode +requires+ the gateway to have a routing entry for each client that accesses the internet (e.g. non-batman clients may be announced via HNA). Also, batman won't be able to automatically detect whether the chosen gateway is connected to the internet or not as only outgoing packets go through gate0. +The batman daemon will try to locate the iptables binary to setup the masquerading automatically. This behaviour can be turned off using the "--disable-client-nat" option. If the outgoing packets are not masqueraded (the iptables binary wasn't found / the automatism deactivated) batman will switch to the "half tunnel" mode which operates without masquerading. Beware: This mode +requires+ the gateway to have a routing entry for each client that accesses the internet (e.g. non-batman clients may be announced via HNA). Also, batman won't be able to automatically detect whether the chosen gateway is connected to the internet or not as only outgoing packets go through gate0. h2. Tuning

1 0

[doc] backup-redmine/2020-07-12,master: doc: batmand/Coredump (e262b20)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit e262b20142113b0731d77bc5b10d6be48b37ec47 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:19:35 2020 +0000 doc: batmand/Coredump >--------------------------------------------------------------- e262b20142113b0731d77bc5b10d6be48b37ec47 batmand/Coredump.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batmand/Coredump.textile b/batmand/Coredump.textile index 4a788ab..1e3d4c8 100644 --- a/batmand/Coredump.textile +++ b/batmand/Coredump.textile @@ -7,7 +7,7 @@ A coredump is the state of the programs memory when it crashed. It allows progra h2. Why do I need ulimit and what does it do ? -As coredumps save the programs memory on the hard disk the coredump files can become quite large because some applications consume a lot of memory. On embedded devices (e.g. small routers) a coredump can fill the entire disk easily. Therefore the tool "ulimit" allows you to control what memory size is safe to be saved on disk. A "ulimit -c 20000" saves coredumps of up to 20MB, "ulimit -c unlimited" saves everything no matter how big it is. You can check your systems default by running "ulimit -c" without any value. If the setting is too small or coredumping is disabled you have to run "ulimit -c <value>" each time before you start batman. +As coredumps save the programs memory on the hard disk the coredump files can become quite large because some applications consume a lot of memory. On embedded devices (e.g. small routers) a coredump can fill the entire disk easily. Therefore the tool "ulimit" allows you to control what memory size is safe to be saved on disk. A "ulimit -c 20000" saves coredumps of up to 20MB, "ulimit -c unlimited" saves everything no matter how big it is. You can check your systems default by running "ulimit -c" without any value. If the setting is too small or coredumping is deactivated, you have to run "ulimit -c <value>" each time before you start batman. h2. How to get a batman coredump ?

1 0

[doc] backup-redmine/2020-07-12,master: doc: batmand/VisOutput (9c85764)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit 9c85764a075ee0d7349ba5bd62418e42fd36ed8d Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:39:30 2020 +0000 doc: batmand/VisOutput >--------------------------------------------------------------- 9c85764a075ee0d7349ba5bd62418e42fd36ed8d batmand/VisOutput.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/batmand/VisOutput.textile b/batmand/VisOutput.textile index b7a0021..47b76b7 100644 --- a/batmand/VisOutput.textile +++ b/batmand/VisOutput.textile @@ -34,9 +34,9 @@ h2. Batman to batman connection The batman node 5.174.37.225 has a connection towards the batman node 5.224.160.202 with a link quality of "2.13" whereas the 5.224.160.202 has a link quality of "1.28" towards the 5.174.37.225. The connection is listed twice because each node reports it individually which gives you the option of seeing asymetric links if you want to display it. -The link quality gives information how batman evaluates this link. 1.00 means 100%25 link quality, 2.00 means 50%25, 3.00 is 33.3%25 and 4.00 is 25%25, etc. The number tells you how many packets you need to send in order to get a single successful transmission. +The link quality gives information how batman evaluates this link. 1.00 means 100% link quality, 2.00 means 50%, 3.00 is 33.3% and 4.00 is 25%, etc. The number tells you how many packets you need to send in order to get a single successful transmission. -While looking at originator tables, debug logs or other batman output you might see different numbers. Due to performance considerations batman uses his own format (TQ value) to express link quality. Its max value is 255 and goes down to 0 (float operations are quite expensive on embedded devices). The vis server transforms the TQ value into its own format before outputting it. +While looking at originator tables, debug logs or other batman output you might see different numbers. Due to performance considerations batmand uses its own format (TQ value) to express link quality. Its max value is 255 and goes down to 0 (float operations are quite expensive on embedded devices). The vis server transforms the TQ value into its own format before outputting it.

1 0

[doc] backup-redmine/2020-07-12,master: doc: open-mesh/The-olsr-story (8b6513c)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit 8b6513c76d993ef3a1c5f7c046c3fbd2d23699d7 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:19:15 2020 +0000 doc: open-mesh/The-olsr-story >--------------------------------------------------------------- 8b6513c76d993ef3a1c5f7c046c3fbd2d23699d7 open-mesh/The-olsr-story.textile | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/open-mesh/The-olsr-story.textile b/open-mesh/The-olsr-story.textile index 10593a2..f802a22 100644 --- a/open-mesh/The-olsr-story.textile +++ b/open-mesh/The-olsr-story.textile @@ -3,7 +3,7 @@ h1. The OLSR.ORG story Proactive protocols (Link State Routing Protocols) generate a lot of overhead because they have to keep topoloy information and routing tables in sync amongst all or at least amongst adjacent nodes. If the protocol does not manage to keep the routing tables synced it is likely that the payload will spin in routing loops until the TimeToLive (TTL) is expired. Apart from high traffic-overhead and CPU-Load this is the biggest issue for Link State Routing Protocols. ��We were actively involved in the evolution of olsrd from olsr.org. Actually we were the people that made it functional. RFC3626 - the initial IETF-draft of olsr - does not work in real life. If you want to find out what it's developers intended it to be and how it should work, I would like to suggest reading the RFC3626 after you have seen the presentation of Andreas T��ennesen on the OLSR.ORG website about RFC3626. -We heavily modified olsr over the time. We disabled almost everything that the inital designers of olsr thought was smart and replaced it with the LQ/ETX-Mechanism and Fish-Eye Mechanism tp update topology information. +We heavily modified olsr over the time. We turned off almost everything that the inital designers of olsr thought was smart and replaced it with the LQ/ETX-Mechanism and Fish-Eye Mechanism tp update topology information. What we did to improve olsr (in historical order): @@ -30,10 +30,10 @@ Conclusion: What we did: -* Disable hysteresis. -* Disable MPRs - all nodes forward topology information. +* Deactivate hysteresis. +* Deactivate MPRs - all nodes forward topology information. -Now almost everything that was meant to optimize Link State Routing was disabled - a simple proactive link-state routing protocol with support for multiple interfaces was all that was left. We started to deploy OLSR in the Freifunk Mesh in Berlin - rather we should have named it LSR back then. But since the implementation came from olsr.org and everything could be switched on and off by the configuration file we didn't think about starting a new project and renaming it. This became later a source of confusion and disappointment for all people that tried olsr.org and had no idea what was going on in Berlin. If you use the standard configuration file that is shipped with olsr.org, olsrd will still behave according to RFC3626. So if you want to see how miserable RFC3626 +Now almost everything that was meant to optimize Link State Routing was turned off - a simple proactive link-state routing protocol with support for multiple interfaces was all that was left. We started to deploy OLSR in the Freifunk Mesh in Berlin - rather we should have named it LSR back then. But since the implementation came from olsr.org and everything could be switched on and off by the configuration file we didn't think about starting a new project and renaming it. This became later a source of confusion and disappointment for all people that tried olsr.org and had no idea what was going on in Berlin. If you use the standard configuration file that is shipped with olsr.org, olsrd will still behave according to RFC3626. So if you want to see how miserable RFC3626 works - try it with the default configuration file. _Deployment of OLSR (with 'Optimizations' removed) in the Berlin Freifunk ��mesh cloud - 2004_

1 0

[doc] backup-redmine/2020-07-12,master: doc: batman-adv/Tweaking (f56fb44)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit f56fb449515455e6fe3059c9913bae3c1d8d1126 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:17:46 2020 +0000 doc: batman-adv/Tweaking >--------------------------------------------------------------- f56fb449515455e6fe3059c9913bae3c1d8d1126 batman-adv/Tweaking.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Tweaking.textile b/batman-adv/Tweaking.textile index 6a4503b..53b7a74 100644 --- a/batman-adv/Tweaking.textile +++ b/batman-adv/Tweaking.textile @@ -160,7 +160,7 @@ batctl meshif bat0 gw_mode server 10Mbit/2Mbit # switch to client and and use selection class 20 batctl meshif bat0 gw_mode client 20 -# disable gateway mode +# turn off gateway mode batctl meshif bat0 gw_mode off </pre>

1 0

[doc] backup-redmine/2020-07-12,master: doc: batman-adv/Tweaking (025fc79)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit 025fc79038270988d3cd2d539aac5b90d356699e Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:17:22 2020 +0000 doc: batman-adv/Tweaking >--------------------------------------------------------------- 025fc79038270988d3cd2d539aac5b90d356699e batman-adv/Tweaking.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Tweaking.textile b/batman-adv/Tweaking.textile index 29e7eb8..6a4503b 100644 --- a/batman-adv/Tweaking.textile +++ b/batman-adv/Tweaking.textile @@ -147,7 +147,7 @@ batctl meshif bat0 gw_mode server (announced bw: 10.0/2.0 MBit) </pre> -A batman-adv node can either run in server mode (sharing its internet connection with the mesh) or in client mode (searching for the most suitable internet connection in the mesh) or having the gateway support disabled entirely (which is the default setting). Gateways can tweak the announced internet bandwidth whereas clients can configure the manner in which batman-adv chooses its gateway. +A batman-adv node can either run in server mode (sharing its internet connection with the mesh) or in client mode (searching for the most suitable internet connection in the mesh) or having the gateway support turned off entirely (which is the default setting). Gateways can tweak the announced internet bandwidth whereas clients can configure the manner in which batman-adv chooses its gateway. If multiple batman-adv gateways are available a batman-adv client node selects its best gateway based on certain criteria such as link quality / announced bandwidth / etc. The selection algorithm can be modified to best serve the requirements. The gateway selection class of '20' is the default value. All available gateway selection classes are thoroughly explained in the "batctl manpage":https://downloads.open-mesh.org/batman/manpages/batctl.8.html.

1 0

[doc] backup-redmine/2020-07-12,master: doc: batman-adv/Gateways (2a8ab5c)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit 2a8ab5c8a41ed5ea728d5b60c27ae014b8e73c79 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:16:57 2020 +0000 doc: batman-adv/Gateways >--------------------------------------------------------------- 2a8ab5c8a41ed5ea728d5b60c27ae014b8e73c79 batman-adv/Gateways.textile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/batman-adv/Gateways.textile b/batman-adv/Gateways.textile index 7067074..3d42d24 100644 --- a/batman-adv/Gateways.textile +++ b/batman-adv/Gateways.textile @@ -80,8 +80,7 @@ The mode of the current node can be seen by running: batctl gw_mode </pre> - h2. Controversy -The subject of manipulating the IP (layer 3) default route with a layer 2 routing protocol has stirred up controversy between those who believe in a clean network layer separation and those who need this functionality. The former claim that a well-designed protocol should not mess with other layers but instead collaborate with tools made for higher layers. The latter group has pointed out that the rule of network layer separation can be bent in real-world applications to improve usability. To achieve a compromise the gateway mechanism is disabled per default and only operates on top of DHCP (details below). Feel free to contact us in case you want to propose alternative ideas. +The subject of manipulating the IP (layer 3) default route with a layer 2 routing protocol has stirred up controversy between those who believe in a clean network layer separation and those who need this functionality. The former claim that a well-designed protocol should not mess with other layers but instead collaborate with tools made for higher layers. The latter group has pointed out that the rule of network layer separation can be bent in real-world applications to improve usability. To achieve a compromise the gateway mechanism is turned off per default and only operates on top of DHCP (details below). Feel free to contact us in case you want to propose alternative ideas. \ No newline at end of file

1 0

[doc] backup-redmine/2020-07-12,master: doc: batman-adv/Tweaking (73b7c94)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit 73b7c94a1ed605a41a8ef2d22e5f64ac4652f4bf Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:17:10 2020 +0000 doc: batman-adv/Tweaking >--------------------------------------------------------------- 73b7c94a1ed605a41a8ef2d22e5f64ac4652f4bf batman-adv/Tweaking.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Tweaking.textile b/batman-adv/Tweaking.textile index 1d228e7..29e7eb8 100644 --- a/batman-adv/Tweaking.textile +++ b/batman-adv/Tweaking.textile @@ -81,7 +81,7 @@ h3. ap isolation Available since: batman-adv 2011.4.0 -Standard WiFi AccessPoints support a feature known as 'AP isolation' which prevents one connected wireless client to talk to another wireless client. In most situations this is considered a security feature. If the WiFi AP interface is bridged into a batman-adv mesh network it might be desirable to extend this wireless client isolation throughout the mesh network, therefore batman-adv has the ability to do just that (disabled by default). This setting only affects packets without any VLAN tag (untagged packets). The ap isolation setting for VLAN tagged packets is modifiable through the per-VLAN settings. +Standard WiFi AccessPoints support a feature known as 'AP isolation' which prevents one connected wireless client to talk to another wireless client. In most situations this is considered a security feature. If the WiFi AP interface is bridged into a batman-adv mesh network it might be desirable to extend this wireless client isolation throughout the mesh network, therefore batman-adv has the ability to do just that (turned off by default). This setting only affects packets without any VLAN tag (untagged packets). The ap isolation setting for VLAN tagged packets is modifiable through the per-VLAN settings. <pre> batctl meshif bat0 ap_isolation

1 0

[doc] backup-redmine/2020-07-12,master: doc: batman-adv/Multicast-optimizations-listener-reports (f7dd4ef)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit f7dd4ef8311f72c939c4759d19718814a7952697 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:13:21 2020 +0000 doc: batman-adv/Multicast-optimizations-listener-reports >--------------------------------------------------------------- f7dd4ef8311f72c939c4759d19718814a7952697 batman-adv/Multicast-optimizations-listener-reports.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Multicast-optimizations-listener-reports.textile b/batman-adv/Multicast-optimizations-listener-reports.textile index 86d2427..05ed802 100644 --- a/batman-adv/Multicast-optimizations-listener-reports.textile +++ b/batman-adv/Multicast-optimizations-listener-reports.textile @@ -54,7 +54,7 @@ _Disadvantages:_ h4. Side note 1: Why does the current implementation without bridge support have no such issues? -There are usually two parties interested in multicast listener reports. For one thing, bridges ("software switches") and snooping switches (enterprise hardware switches). For another thing, multicast routers want IGMP/MLD reports. If the former, a bridge, exists then multicast optimizations are disabled at the moment, so the issue can't occure. For the latter, reports to multicast routers, let's consider the following two cases: +There are usually two parties interested in multicast listener reports. For one thing, bridges ("software switches") and snooping switches (enterprise hardware switches). For another thing, multicast routers want IGMP/MLD reports. If the former, a bridge, exists then multicast optimizations are turned off at the moment, so the issue can't occure. For the latter, reports to multicast routers, let's consider the following two cases: a) Multicast listeners joining a link-local address b) Multicast listeners joining a non-link-local address

1 0

[doc] backup-redmine/2020-07-12,master: doc: batman-adv/NetworkCoding (f8b3008)
by postmaster＠open-mesh.org 12 Jul '20

12 Jul '20

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2020-07-12,master >--------------------------------------------------------------- commit f8b3008959d0b7f1c21c08a1220e9fe81d1cb779 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 20 21:14:54 2020 +0000 doc: batman-adv/NetworkCoding >--------------------------------------------------------------- f8b3008959d0b7f1c21c08a1220e9fe81d1cb779 batman-adv/NetworkCoding.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/NetworkCoding.textile b/batman-adv/NetworkCoding.textile index aefa4ed..bab9e04 100644 --- a/batman-adv/NetworkCoding.textile +++ b/batman-adv/NetworkCoding.textile @@ -24,7 +24,7 @@ There are a few requirements to your setup, if you want to benefit from network * For network coding to work, it is required to have an enabled and working promiscuous mode on all nodes, as promiscuity is used to both overhear packets and receive network coded packets. Be aware that many wireless devices have no functioning promiscuous mode, so some testing might be required. * Your wireless device must support an MTU of 1546, as the batman-adv header for network coded packets carries more information than usual unicast packets. -To enable network coding, enable it a compile time (consult "the README.external file":https://git.open-mesh.org/batman-adv.git/blob/refs/heads/master:/README.external to learn how to set the compile option). It can be disabled at runtime with batctl: +To enable network coding, enable it a compile time (consult "the README.external file":https://git.open-mesh.org/batman-adv.git/blob/refs/heads/master:/README.external to learn how to set the compile option). It can be turned off at runtime with batctl: <pre> # batctl nc 0 </pre>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2020