[commits] [doc] master: doc: Fix lists marked as non-list/literal asterisk (84af40a2)

Repository : ssh://git@open-mesh.org/doc

On branch : master

commit 84af40a2fe24ac9d55c973979830406defef0c34 Author: Sven Eckelmann sven@narfation.org Date: Fri Jul 14 13:21:31 2017 +0200

doc: Fix lists marked as non-list/literal asterisk

Signed-off-by: Sven Eckelmann sven@narfation.org

84af40a2fe24ac9d55c973979830406defef0c34 batman-adv/Bridge-loop-avoidance-II.rst | 10 ++--- batman-adv/Bridge-loop-avoidance.rst | 12 ++---- batman-adv/Broadcast-Avoidances-NHH-Assessment.rst | 10 ++--- batman-adv/Multicast-optimizations-bridges.rst | 2 +- batman-adv/Multicast-optimizations-flags.rst | 23 +++++------ .../Multicast-optimizations-report-suppresion.rst | 18 ++++----- batman-adv/Multicast-optimizations-tech.rst | 2 +- batman-adv/OGMv2.rst | 4 +- batman-adv/Packet-types.rst | 6 +-- batman-adv/RIP.rst | 8 ++-- batman-adv/TVLV.rst | 14 +++---- batmand/Coredump.rst | 9 ++--- open-mesh/Contribute.rst | 47 +++++++++------------- open-mesh/Wbmv6-batmandev-agenda.rst | 25 +++++------- 14 files changed, 85 insertions(+), 105 deletions(-)

diff --git a/batman-adv/Bridge-loop-avoidance-II.rst b/batman-adv/Bridge-loop-avoidance-II.rst index 1a8512fc..28d9ffdd 100644 --- a/batman-adv/Bridge-loop-avoidance-II.rst +++ b/batman-adv/Bridge-loop-avoidance-II.rst @@ -238,11 +238,11 @@ Features: Limitations: ~~~~~~~~~~~~

-* loops in higher-level structures may not be avoided. For example, if -there are two meshes and two backbones are interconnected as in the -illustration below, a loop is formed which can't be detected, since the -claim frames of one mesh won't travel along the mesh network of the -other. +* loops in higher-level structures may not be avoided. For example, if + there are two meshes and two backbones are interconnected as in the + illustration below, a loop is formed which can't be detected, since the + claim frames of one mesh won't travel along the mesh network of the + other.

|image10|

diff --git a/batman-adv/Bridge-loop-avoidance.rst b/batman-adv/Bridge-loop-avoidance.rst index 4d227ef5..d90dbe1c 100644 --- a/batman-adv/Bridge-loop-avoidance.rst +++ b/batman-adv/Bridge-loop-avoidance.rst @@ -78,24 +78,18 @@ compiled in.

Simple steps to see it in action:

-* add your wifi interface - -:: +* add your wifi interface::

batctl if add wlan0

-* create a bridge for bat0 and your lan - -:: +* create a bridge for bat0 and your lan::

ip link add name br-lan type bridge ip link set dev eth0 master br-lan ip link set dev bat0 master br-lan ip link set up dev br-lan

-* activate bridge loop avoidance - -:: +* activate bridge loop avoidance::

batctl bl 1

diff --git a/batman-adv/Broadcast-Avoidances-NHH-Assessment.rst b/batman-adv/Broadcast-Avoidances-NHH-Assessment.rst index 97f8e517..6a1864d8 100644 --- a/batman-adv/Broadcast-Avoidances-NHH-Assessment.rst +++ b/batman-adv/Broadcast-Avoidances-NHH-Assessment.rst @@ -184,7 +184,7 @@ Proof: Ingress TX (bcast)

We want to proof:

-* p(Amax) < Amin => p(AB) < ACn for any Cn. +* p(Amax) < Amin => p(AB) < ACn for any Cn.

One has:

@@ -208,7 +208,7 @@ Proof: Egress TX (bcast)

We want to proof:

-* p(Bmax) < Amin => p(BCn) < ACn +* p(Bmax) < Amin => p(BCn) < ACn

One has:

@@ -232,7 +232,7 @@ Proof: Ingress RX (OGM2)

We want to proof:

-* p(AB) < MIN(Amin, Cn-min) => p(AB) < CnA for any Cn. +* p(AB) < MIN(Amin, Cn-min) => p(AB) < CnA for any Cn.

One has:

@@ -252,7 +252,7 @@ Proof: Egress RX (OGM2)

We want to proof:

-* p(MAX(Amax, Cn-max)) < MIN(Amin, Cn-min) => p(AB) < CnA for any Cn. +* p(MAX(Amax, Cn-max)) < MIN(Amin, Cn-min) => p(AB) < CnA for any Cn.

One has:

@@ -288,7 +288,7 @@ neighborhood were formed 3e10 times per nanosecond.

See also:

-* https://en.wikipedia.org/wiki/Birthday%5C_attack +* https://en.wikipedia.org/wiki/Birthday%5C_attack

.. |image0| image:: wired-aps.svg .. |image1| image:: mobile-clusters.svg diff --git a/batman-adv/Multicast-optimizations-bridges.rst b/batman-adv/Multicast-optimizations-bridges.rst index f11b3aca..4cc111ac 100644 --- a/batman-adv/Multicast-optimizations-bridges.rst +++ b/batman-adv/Multicast-optimizations-bridges.rst @@ -3,7 +3,7 @@ Multicast Optimizations - Bridges

Prior Readings:

-* :doc:`Multicast Optimizations <Multicast-optimizations>` +* :doc:`Multicast Optimizations <Multicast-optimizations>`

For the multicast optimizations to work, potential receivers need to be known by batman-adv nodes sending multicast packets. To avoid any loss diff --git a/batman-adv/Multicast-optimizations-flags.rst b/batman-adv/Multicast-optimizations-flags.rst index 1fff4246..4dd58236 100644 --- a/batman-adv/Multicast-optimizations-flags.rst +++ b/batman-adv/Multicast-optimizations-flags.rst @@ -65,19 +65,18 @@ reports will be or might be sent:

|image2|

-* No MLD messages for the all-nodes IPv6 multicast (**ff02::1**) -address. `RFC4541 https://tools.ietf.org/html/rfc4541`__, section 3: +* No MLD messages for the all-nodes IPv6 multicast (**ff02::1**) + address. `RFC4541 https://tools.ietf.org/html/rfc4541`__, section 3:

-> [...] The only exception is the address FF02::1 which is the all hosts -link-scope address for which MLD messages are never sent. [...] + [...] The only exception is the address FF02::1 which is the all hosts + link-scope address for which MLD messages are never sent. [...] +* No requirement for IGMP messages for IPv4 link-local multicast + addresses (**224.0.0.x**). + `RFC4541 https://tools.ietf.org/html/rfc4541`__, section 2.1.2.2):

-* No requirement for IGMP messages for IPv4 link-local multicast -addresses (**224.0.0.x**). -`RFC4541 https://tools.ietf.org/html/rfc4541`__, section 2.1.2.2): - -> [...] This recommendation is based on the fact that many host systems -do not send Join IP multicast addresses in the [224.0.0.x] range before -sending or listening to IP multicast packets. [...] + [...] This recommendation is based on the fact that many host systems + do not send Join IP multicast addresses in the [224.0.0.x] range before + sending or listening to IP multicast packets. [...]

So multicast listeners for these addresses are only reliably known to the kernel of a multicast listener itself. @@ -109,7 +108,7 @@ but not the bridge / batman-adv node. A more detailed explanation for when and why this happens exactly can be found here:

-* :doc:`Multicast Optimizations – IGMP/MLD Report Suppression <Multicast-optimizations-report-suppresion>` +* :doc:`Multicast Optimizations – IGMP/MLD Report Suppression <Multicast-optimizations-report-suppresion>`

Multicast flags --------------- diff --git a/batman-adv/Multicast-optimizations-report-suppresion.rst b/batman-adv/Multicast-optimizations-report-suppresion.rst index f0a0caa3..9ad4d44c 100644 --- a/batman-adv/Multicast-optimizations-report-suppresion.rst +++ b/batman-adv/Multicast-optimizations-report-suppresion.rst @@ -28,14 +28,14 @@ IGMPv2):

|image1|

-* IGMPv2: `RFC2236 https://tools.ietf.org/html/rfc2236`__, section 3: +* IGMPv2: `RFC2236 https://tools.ietf.org/html/rfc2236`__, section 3:

-> [...] If the host receives another host's Report (version 1 or 2) -while it has a timer running, it stops its timer for the specified group -and does not send a Report, in order to suppress duplicate Reports. -[...] + [...] If the host receives another host's Report (version 1 or 2) + while it has a timer running, it stops its timer for the specified group + and does not send a Report, in order to suppress duplicate Reports. + [...]

-* MLDv1: `RFC2710 https://tools.ietf.org/html/rfc2710`__, section 4: +* MLDv1: `RFC2710 https://tools.ietf.org/html/rfc2710`__, section 4:

If a node receives another node's Report from an interface for a

multicast address while it has a timer running for that same address on @@ -58,10 +58,10 @@ snooping switches:

|image3|

-* `RFC4541 https://tools.ietf.org/html/rfc4541`__, section 2.1.1.1) +* `RFC4541 https://tools.ietf.org/html/rfc4541`__, section 2.1.1.1)

-> A snooping switch should forward IGMP Membership Reports only to those -ports where multicast routers are attached. [...] + A snooping switch should forward IGMP Membership Reports only to those + ports where multicast routers are attached. [...]

Which in turn can potentially lead to a batman-adv node not receiving any MLD/IGMP report for a certain multicast address from a bridge port diff --git a/batman-adv/Multicast-optimizations-tech.rst b/batman-adv/Multicast-optimizations-tech.rst index c6aaef65..99af8fa4 100644 --- a/batman-adv/Multicast-optimizations-tech.rst +++ b/batman-adv/Multicast-optimizations-tech.rst @@ -3,7 +3,7 @@ Multicast Optimizations – Technical Description

Prior Readings:

-* :doc:`Multicast Optimizations <Multicast-optimizations>` +* :doc:`Multicast Optimizations <Multicast-optimizations>`

Multicast Listener Announcements -------------------------------- diff --git a/batman-adv/OGMv2.rst b/batman-adv/OGMv2.rst index 2396f76d..5a3d9261 100644 --- a/batman-adv/OGMv2.rst +++ b/batman-adv/OGMv2.rst @@ -170,8 +170,8 @@ If the initial checks above have passed, the internal stats are updated: After that, we check the OGMv2 whether a router update should be done and the OGMv2 should be rebroadcasted

-* If the OGMv2 was received through a neighbor that is not (yet) a -router, drop the OGMv2 +* If the OGMv2 was received through a neighbor that is not (yet) a + router, drop the OGMv2

The passing OGMv2 will be considered for a router update:

diff --git a/batman-adv/Packet-types.rst b/batman-adv/Packet-types.rst index 79006d3a..80194ab1 100644 --- a/batman-adv/Packet-types.rst +++ b/batman-adv/Packet-types.rst @@ -39,6 +39,6 @@ purposes.

Further reading:

-* The latest packet type assignments can be reviewed in the source -code: -https://git.open-mesh.org/batman-adv.git/blob/refs/heads/master:/packet.h#l2... +* The latest packet type assignments can be reviewed in the source + code: + https://git.open-mesh.org/batman-adv.git/blob/refs/heads/master:/packet.h#l2... diff --git a/batman-adv/RIP.rst b/batman-adv/RIP.rst index 91020eff..0e6f00cd 100644 --- a/batman-adv/RIP.rst +++ b/batman-adv/RIP.rst @@ -120,10 +120,10 @@ distinguished by a flag. They basicly contain: Optimization Ideas ~~~~~~~~~~~~~~~~~~

-* we may also send the last valid OGM from a node which is not affected -by a death note - but only after making sure that the connection to the -destination still works (e.g. by using a ping). This would require some -more state to be saved. +* we may also send the last valid OGM from a node which is not affected + by a death note - but only after making sure that the connection to the + destination still works (e.g. by using a ping). This would require some + more state to be saved.

.. |image0| image:: circle-v2.svg

diff --git a/batman-adv/TVLV.rst b/batman-adv/TVLV.rst index 349b1270..2fd044d0 100644 --- a/batman-adv/TVLV.rst +++ b/batman-adv/TVLV.rst @@ -117,16 +117,16 @@ available:

Handler register flags:

-* BATADV_TVLV_HANDLER_OGM_CIFNOTFND: If the TVLV type has not been -found, call this handler anyway when the OGM parsing has been completed. -In this case the length argument will be 0 and the value will be NULL -and a flag to indicate this condition will be passed. +* BATADV_TVLV_HANDLER_OGM_CIFNOTFND: If the TVLV type has not been + found, call this handler anyway when the OGM parsing has been completed. + In this case the length argument will be 0 and the value will be NULL + and a flag to indicate this condition will be passed.

Flags passed to the handler by the TVLV API:

-* BATADV_TVLV_HANDLER_OGM_CIFNOTFND: Signals the handler whether -the TVLV container has been found or whether the call was invoked due to -the BATADV_TVLV_HANDLER_OGM_CIFNOTFND flag. +* BATADV_TVLV_HANDLER_OGM_CIFNOTFND: Signals the handler whether + the TVLV container has been found or whether the call was invoked due to + the BATADV_TVLV_HANDLER_OGM_CIFNOTFND flag.

TVLV definitions ---------------- diff --git a/batmand/Coredump.rst b/batmand/Coredump.rst index ae6b54f3..8510328b 100644 --- a/batmand/Coredump.rst +++ b/batmand/Coredump.rst @@ -39,11 +39,10 @@ Without the correct binary the coredump is useless!* I can't find the coredump ... -----------------------------

-* May be batman did not crash but just exited ? A coredump can be -created only on a segmentation fault. Your system logs should contain a -log entry similar to "Error - SIGSEGV received, trying to clean up ..." -otherwise batman did not crash. - +* May be batman did not crash but just exited ? A coredump can be + created only on a segmentation fault. Your system logs should contain a + log entry similar to "Error - SIGSEGV received, trying to clean up ..." + otherwise batman did not crash. * Did you check the ulimit section ? * The coredumping behaviour can be modified by changing some /proc parameters like /proc/sys/kernel/core_uses_pid and diff --git a/open-mesh/Contribute.rst b/open-mesh/Contribute.rst index 5a188f7c..8c5624d6 100644 --- a/open-mesh/Contribute.rst +++ b/open-mesh/Contribute.rst @@ -84,33 +84,26 @@ Submitting patches If you intend to send us patches, please consider the following guidelines:

-* Prefer small & digestible over long "all in one" patches. - -* No MIME, no links, no compression, no attachments. Just plain text -(patches are to be sent inline). - -* Patches sent to the mailing list should include "PATCH" in the -subject to make it easier to distinguish between patches and -discussions. - -* The mail's subject will become the first line in the commit message. -The body contains the longer patch description and the patch (unified -format) itself. Please also specify the target branch (e.g. batctl, -batman-adv, etc) at the beginning of the subject line. - -* Add a "Signed-off-by: Your Name you@example.com" line to the patch -message to make the ownership of the patch clear. - -* Patches for B.A.T.M.A.N. Advanced need to follow the linux kernel -coding style closely (use checkpatch.pl to verify your patch) as well as -the linux "how to submit patches" guidelines (search for the term -SubmitPatches to find thorough documentation). - -* Check it using static analysis tools like -`sparse https://sparse.wiki.kernel.org/`__ (cgcc) and -`cppcheck http://cppcheck.sourceforge.net/`__ - -* Patches against the batman-adv master branch must be formatted using +* Prefer small & digestible over long "all in one" patches. +* No MIME, no links, no compression, no attachments. Just plain text + (patches are to be sent inline). +* Patches sent to the mailing list should include "PATCH" in the + subject to make it easier to distinguish between patches and + discussions. +* The mail's subject will become the first line in the commit message. + The body contains the longer patch description and the patch (unified + format) itself. Please also specify the target branch (e.g. batctl, + batman-adv, etc) at the beginning of the subject line. +* Add a "Signed-off-by: Your Name you@example.com" line to the patch + message to make the ownership of the patch clear. +* Patches for B.A.T.M.A.N. Advanced need to follow the linux kernel + coding style closely (use checkpatch.pl to verify your patch) as well as + the linux "how to submit patches" guidelines (search for the term + SubmitPatches to find thorough documentation). +* Check it using static analysis tools like + `sparse https://sparse.wiki.kernel.org/`__ (cgcc) and + `cppcheck http://cppcheck.sourceforge.net/`__ +* Patches against the batman-adv master branch must be formatted using

::

diff --git a/open-mesh/Wbmv6-batmandev-agenda.rst b/open-mesh/Wbmv6-batmandev-agenda.rst index c642cec0..5b78461b 100644 --- a/open-mesh/Wbmv6-batmandev-agenda.rst +++ b/open-mesh/Wbmv6-batmandev-agenda.rst @@ -26,21 +26,16 @@ Testing Concept discussion ------------------

-* B.A.T.M.A.N. V (which includes bandwidth aware ELP and OGMv2) - -* OGMv3 (no-tt OGM) - -* Multicast (evolution) support inclusion - -* `Howto to optimise the Bandwidth based GW -selection https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2013-January/008964.html`__ - -* Multiple L3 border Gateways to the same network: how to choose the -best one assuming each of them has a different (L3) cost to the -destination - -* Some notes were taken in the past about possible improvements to the -GW feature. We may want to consider them: +* B.A.T.M.A.N. V (which includes bandwidth aware ELP and OGMv2) +* OGMv3 (no-tt OGM) +* Multicast (evolution) support inclusion +* `Howto to optimise the Bandwidth based GW + selection https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2013-January/008964.html`__ +* Multiple L3 border Gateways to the same network: how to choose the + best one assuming each of them has a different (L3) cost to the + destination +* Some notes were taken in the past about possible improvements to the + GW feature. We may want to consider them:

::