Repository : ssh://git@open-mesh.org/doc
On branch : master
commit 19782144e32d5be4eab6ac506e01d1809b6220de Author: Sven Eckelmann sven@narfation.org Date: Thu Jul 13 21:17:46 2017 +0200
doc: Fix warnings about literal section endings
Signed-off-by: Sven Eckelmann sven@narfation.org
19782144e32d5be4eab6ac506e01d1809b6220de batman-adv/Broadcast-Avoidances.rst | 27 +-- batman-adv/Faq.rst | 195 +++++++++++---------- batman-adv/Multicast-optimizations-flags.rst | 12 +- .../Multicast-optimizations-listener-reports.rst | 14 +- batman-adv/Multicast-optimizations-tech.rst | 28 +-- batman-adv/Quick-start-guide.rst | 2 - batman-adv/TVLV.rst | 112 ++++++------ batman-adv/Understand-your-batman-adv-network.rst | 111 +----------- 8 files changed, 214 insertions(+), 287 deletions(-)
diff --git a/batman-adv/Broadcast-Avoidances.rst b/batman-adv/Broadcast-Avoidances.rst index 3a208a8..5e1c28a 100644 --- a/batman-adv/Broadcast-Avoidances.rst +++ b/batman-adv/Broadcast-Avoidances.rst @@ -163,19 +163,20 @@ Concept Neighborhood Hash TVLV Format ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| * Packet type: 0x03 (BATADV_ELP) -| * TVLV type: 0x01 (BATADV_TVLV_NHH) -| * Length: 68 bytes -| * Fixed TVLV fields: -| **** minimum throughput: the worst of all TX throughputs to any - neighbor a node sees on the according interface (4 bytes) -| **** maximum throughput: the best of all TX throughputs to any - neighbor a node sees on the according interface (4 bytes) -| **** neighorhood hash: a sha512 hash summarizing all neighbors a node - sees on the according interface; hash created from neighbor addresses - sorted alphabetically, concatenated, binary (64 bytes) - -* Definition: +* Packet type: 0x03 (BATADV_ELP) +* TVLV type: 0x01 (BATADV_TVLV_NHH) +* Length: 68 bytes +* Fixed TVLV fields: + + - minimum throughput: the worst of all TX throughputs to any + neighbor a node sees on the according interface (4 bytes) + - maximum throughput: the best of all TX throughputs to any + neighbor a node sees on the according interface (4 bytes) + - neighorhood hash: a sha512 hash summarizing all neighbors a node + sees on the according interface; hash created from neighbor addresses + sorted alphabetically, concatenated, binary (64 bytes) + +* Definition:
::
diff --git a/batman-adv/Faq.rst b/batman-adv/Faq.rst index 2bc2b16..412c1d0 100644 --- a/batman-adv/Faq.rst +++ b/batman-adv/Faq.rst @@ -16,22 +16,24 @@ page. B.A.T.M.A.N. General questions ------------------------------
-Does B.A.T.M.A.N. have simulator (NS2, Omnet\ **, etc) support? +Does B.A.T.M.A.N. have simulator (NS2, Omnet, etc) support? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** Does B.A.T.M.A.N. have his own simulator? -| **A:** At this point no, but 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 [[open-mesh:Emulation|read our emulation document]]. +**Q:** Does B.A.T.M.A.N. have his own simulator? + +**A:** At this point no, but 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 [[open-mesh:Emulation|read our emulation document]].
How to make my mesh network secure ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** Can I make my mesh network secure? -| **A:** This depends on the security you want or need. Security is a - big field. Probably you mean encryption and authentication. +**Q:** Can I make my mesh network secure? + +**A:** This depends on the security you want or need. Security is a +big field. Probably you mean encryption and authentication.
When you only want to make the whole WLAN stuff unreadable for the outside, you could just use WPA_NONE or IBSS RSN. But this doesn't @@ -56,12 +58,13 @@ for everything, against any attack and for every purpose" blob. Why does batman need so much time to detect a "dead" node? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** Why can I see a node in the originator table a long time after - it died? *Or:* Does batman really need 200 seconds (PURGE_TIMEOUT) to - switch the route? -| **A:** 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. +**Q:** Why can I see a node in the originator table a long time after +it died? *Or:* Does batman really need 200 seconds (PURGE_TIMEOUT) to +switch the route? + +**A:** 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 @@ -80,48 +83,52 @@ B.A.T.M.A.N. Advanced Questions What can B.A.T.M.A.N. Advanced do? And can't do? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** What offers batman-adv? And what are the 'limitations'? -| **A:** The batman-adv kernel module can only be used to route the - packages within a mesh network, it only simulates OSI layer 2 (data - link layer). It does that as fast as possible and in a smart way. Just - like a switch. +**Q:** What offers batman-adv? And what are the 'limitations'?
-| Batman has no security implemented. Also assigning IP addresses to the - node(s) is not Batman's task. -| You may want to use underlying security mechanisms, like: IBSS RSN. +**A:** The batman-adv kernel module can only be used to route the +packages within a mesh network, it only simulates OSI layer 2 (data +link layer). It does that as fast as possible and in a smart way. Just +like a switch. + +Batman has no security implemented. Also assigning IP addresses to the +node(s) is not Batman's task. +You may want to use underlying security mechanisms, like: IBSS RSN.
Read more about [[Wiki|BATMAN]].
Can batman-adv run on interfaces in AP / Station / etc mode ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** Can BATMAN advanced run on interfaces in AP / Station mode? -| **A:** Yes, because batman-adv doesn't know anything about stuff below - the ethernet interface. So you could also use it over layer 2 ethernet - tunnels, wifi ap, wifi sta, wifi adhoc, ethernet or even write a - virtual interface which prints everything on paper and scans the paper - on the remote machine (but you should be fast or increase the ogm - interval). +**Q:** Can BATMAN advanced run on interfaces in AP / Station mode? + +**A:** Yes, because batman-adv doesn't know anything about stuff below +the ethernet interface. So you could also use it over layer 2 ethernet +tunnels, wifi ap, wifi sta, wifi adhoc, ethernet or even write a +virtual interface which prints everything on paper and scans the paper +on the remote machine (but you should be fast or increase the ogm +interval).
How can I connect non-mesh clients to my batman-adv network ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** How can I connect non-mesh clients to batman-adv network? -| **A:** The [[batman-adv:Quick-start-guide|batman-adv - quick-start-guide]] explains how to bridge your standard AP / Ethernet - interfaces with bat0 which can be problematic if you only possess one - WiFi card. In these cases it might be desirable to run adhoc mode and - AP mode at the same time. Fortunately, some WiFi chips / drivers - support a so-called "multi VAP" (virtual AP) or "multi SSID" mode to - have multiple WiFi networks on the same WiFi interface. +**Q:** How can I connect non-mesh clients to batman-adv network? + +**A:** The [[batman-adv:Quick-start-guide|batman-adv +quick-start-guide]] explains how to bridge your standard AP / Ethernet +interfaces with bat0 which can be problematic if you only possess one +WiFi card. In these cases it might be desirable to run adhoc mode and +AP mode at the same time. Fortunately, some WiFi chips / drivers +support a so-called "multi VAP" (virtual AP) or "multi SSID" mode to +have multiple WiFi networks on the same WiFi interface.
How big networks does batman-adv support? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** How big networks (maximum nodes) does batman-adv support? -| **A:** That is a good question. It is not possible to give an exact - answer, but there are several parameters limiting the number of nodes - in your network: +**Q:** How big networks (maximum nodes) does batman-adv support? + +**A:** That is a good question. It is not possible to give an exact +answer, but there are several parameters limiting the number of nodes +in your network:
#. **Capacity of the wireless network** Usually, the performance of the wireless network renders unusable if @@ -137,11 +144,12 @@ How big networks does batman-adv support? How do I announce IP subnets using batman-adv? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** Can I setup differnt IP subnets using batman-adv? -| **A:** Batman-adv is a OSI layer 2 routing protocol and it does not - handle IP subnets at all. If you want to do IP subnetting, the - suggestion is to split the mesh network in different sub-meshes (e.g. - different ESSID/BSSID), and run a batman-adv instance in each of them. +**Q:** Can I setup differnt IP subnets using batman-adv? + +**A:** Batman-adv is a OSI layer 2 routing protocol and it does not +handle IP subnets at all. If you want to do IP subnetting, the +suggestion is to split the mesh network in different sub-meshes (e.g. +different ESSID/BSSID), and run a batman-adv instance in each of them.
|image0|
@@ -180,41 +188,47 @@ us if you want to do that. Log file doesn't exists in debugfs? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** The /sys/kernel/debug/batman_adv/bat0/log file doesn't exists? -| **A:** You need to compile the batman-adv with logging support. +**Q:** The /sys/kernel/debug/batman_adv/bat0/log file doesn't exists? + +**A:** You need to compile the batman-adv with logging support.
-| * Linux tree -| **** go to **code>Networking support ---> Networking options ---> - B.A.T.M.A.N. Advanced Meshing Protocol** and select - **code>B.A.T.M.A.N. debugging** -| * external module -| **** compile with make parameter **code>CONFIG_BATMAN_ADV_DEBUG=y** +* Linux tree + + - go to ``Networking support ---> Networking options ---> B.A.T.M.A.N. Advanced Meshing Protocol`` + and select ``B.A.T.M.A.N. debugging`` + +* external module + + - compile with make parameter ``CONFIG_BATMAN_ADV_DEBUG=y``
How to setup B.A.T.M.A.N. so it automatically assign IP addresses? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** How to assign IP addresses automatically? -| **A:** Batman-adv is not responsible for assigning IP addresses. - However, you can use for example a DHCP server. +**Q:** How to assign IP addresses automatically? + +**A:** Batman-adv is not responsible for assigning IP addresses. +However, you can use for example a DHCP server.
What about assigning IP addresses in a decentralized way? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** How to assign IP addresses automatically in a decentralized - way? -| **A:** IPv6 will help you to do this easier by using `Unique local - address https://en.wikipedia.org/wiki/Unique_local_address`__ (ULA). +**Q:** How to assign IP addresses automatically in a decentralized +way? + +**A:** IPv6 will help you to do this easier by using `Unique local +address https://en.wikipedia.org/wiki/Unique_local_address`__ (ULA).
What if I want to have a decentralized DNS solution? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** I like to setup a decentralized mesh network and would like to - have a DNS solution. I don't want to use the internet (WWW), but I do - want to have a human readable 'domains' names, just like DNS. What are - the options? -| **A:** Take a look at - `KadNode https://github.com/mwarning/KadNode`__. *Note:* This - software is still in beta. +**Q:** I like to setup a decentralized mesh network and would like to +have a DNS solution. I don't want to use the internet (WWW), but I do +want to have a human readable 'domains' names, just like DNS. What are +the options? + +**A:** Take a look at +`KadNode https://github.com/mwarning/KadNode`__. *Note:* This +software is still in beta.
B.A.T.M.A.N. Advanced - Bridge Loop Avoidance questions ------------------------------------------------------- @@ -222,20 +236,22 @@ B.A.T.M.A.N. Advanced - Bridge Loop Avoidance questions What is Bridge Loop Avoidance? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** What can you do with BLA? -| **A:** Bridge Loop Avoidance is used to detect and avoid loops due to - multiple batX interfaces. [[Bridge-loop-avoidance|Read more...]] +**Q:** What can you do with BLA? + +**A:** Bridge Loop Avoidance is used to detect and avoid loops due to +multiple batX interfaces. [[Bridge-loop-avoidance|Read more...]]
Why do we need BLA II if we can just use mesh on Ethernet? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| Under Discussion -> Features you say "no BATMAN packets on the - backbone". -| **Q:** Why would you want to use the mesh (which never has enough - bandwidth anyway) if you have a fast, reliable backbone link between - some of the nodes (eg. LAN)? -| *Or:* Wouldn't it make more sense to get as much done through the - backbone as possible? +Under Discussion -> Features you say "no BATMAN packets on the +backbone". + +**Q:** Why would you want to use the mesh (which never has enough +bandwidth anyway) if you have a fast, reliable backbone link between +some of the nodes (eg. LAN)? +*Or:* Wouldn't it make more sense to get as much done through the +backbone as possible?
**A:** You can explicitly use batman-adv on the mesh if you want to - batman-adv allows adding Ethernet interfaces as well. This is a good @@ -261,15 +277,16 @@ supposed to be shared is the users payload traffic. What about DHCP server for separate meshes? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| **Q:** I would like to setup a DHCP server in separate meshes? *Or:* - How can I make two separate meshes use a single DHCP server (using - gw_mode feature) in current blaII design? -| **A:** Each node at the edge to the wired network may announce itself - as a gateway, provided that a DHCP server is available in the LAN (or - any network behind it, e.g. a mesh). From a concept view, a gateway - (or maybe even multiple gateways) in mesh2 will not automatically - announced in mesh1 - this must be configured manually, or let batman - use Ethernet if this is explicitly required. +**Q:** I would like to setup a DHCP server in separate meshes? *Or:* +How can I make two separate meshes use a single DHCP server (using +gw_mode feature) in current blaII design? + +**A:** Each node at the edge to the wired network may announce itself +as a gateway, provided that a DHCP server is available in the LAN (or +any network behind it, e.g. a mesh). From a concept view, a gateway +(or maybe even multiple gateways) in mesh2 will not automatically +announced in mesh1 - this must be configured manually, or let batman +use Ethernet if this is explicitly required.
.. |image0| image:: quagga_integration.png
diff --git a/batman-adv/Multicast-optimizations-flags.rst b/batman-adv/Multicast-optimizations-flags.rst index f32dc63..874e61a 100644 --- a/batman-adv/Multicast-optimizations-flags.rst +++ b/batman-adv/Multicast-optimizations-flags.rst @@ -122,12 +122,12 @@ cases listed above is present for its bridged segment of the link. If so, it will set one or more of the following multicast flags in its multicast TVLV:
-| * Case !#1: -| **** BATADV_MCAST_WANT_ALL_UNSNOOPABLES -| * Case !#2 (no IGMP querier) or Case !#3 (a shadowing IGMP querier) -| **** BATADV_MCAST_WANT_ALL_IPV4 -| * Case !#2 (no MLD querier) or Case !#3 (a shadowing MLD querier) -| **** BATADV_MCAST_WANT_ALL_IPV6 +Case !#1: + BATADV_MCAST_WANT_ALL_UNSNOOPABLES +Case !#2 (no IGMP querier) or Case !#3 (a shadowing IGMP querier) + BATADV_MCAST_WANT_ALL_IPV4 +Case !#2 (no MLD querier) or Case !#3 (a shadowing MLD querier) + BATADV_MCAST_WANT_ALL_IPV6
BATADV_MCAST_WANT_ALL_UNSNOOPABLES (Bit 0): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/batman-adv/Multicast-optimizations-listener-reports.rst b/batman-adv/Multicast-optimizations-listener-reports.rst index 4f43f01..734a21c 100644 --- a/batman-adv/Multicast-optimizations-listener-reports.rst +++ b/batman-adv/Multicast-optimizations-listener-reports.rst @@ -67,19 +67,19 @@ batman-adv nodes.
*Advantages:*
-| * Simplicity: -| **** No multicast query snooping needed, only multicast report - snooping -| **** No state for querier +* Simplicity: + + - No multicast query snooping needed, only multicast report snooping + - No state for querier
*Disadvantages:*
-| * Multicast report overhead for every node (both throughput and +* Multicast report overhead for every node (both throughput and memory) -| * Might cause issues for switches if more than 4k hosts on the +* Might cause issues for switches if more than 4k hosts on the network: Usually the MAC table of hardware switches only allows up to 4k clients (there are batman-adv networks with 1.5k hosts already). -| * Central querier(s) +* Central querier(s)
(Yet another simple approach to tackle these disadvantages could be through segmenting the IGMP/MLD domain. The OpenWRT-based firmware diff --git a/batman-adv/Multicast-optimizations-tech.rst b/batman-adv/Multicast-optimizations-tech.rst index 30e43d6..a514f0e 100644 --- a/batman-adv/Multicast-optimizations-tech.rst +++ b/batman-adv/Multicast-optimizations-tech.rst @@ -189,26 +189,28 @@ Limitations Next Steps / Roadmap --------------------
-| * optimization for groups with two or more members: -| **** many-to-some: implement batman-adv multicast packet type - supporting a list of destination addresses (to reduce ICMPv6 overhead - like Neighbor Solicitation Messages, Router Solicitation Messages, MLD - Reports, ...) -| **** some-to-many / streaming: implement path tracking and use these - patches (see [[Multicast-ideas-updated]]) -| * implement `Multicast Router +* optimization for groups with two or more members: + + - many-to-some: implement batman-adv multicast packet type + supporting a list of destination addresses (to reduce ICMPv6 overhead + like Neighbor Solicitation Messages, Router Solicitation Messages, MLD + Reports, ...) + - some-to-many / streaming: implement path tracking and use these + patches (see [[Multicast-ideas-updated]]) + +* implement `Multicast Router Discovery https://tools.ietf.org/search/rfc4286`__ to support scopes greater than link-local, too -| * implement some faster listener roaming mechanism for bridged in +* implement some faster listener roaming mechanism for bridged in hosts (for instance announce (multicast-address, source address) pairs and use general TT roaming mechanism) -| * perform multicast listener adition/reduction via TT immediately +* perform multicast listener adition/reduction via TT immediately instead of every OGM interval to reduce join/leave latency in setups with a slow OGM interval -| * implement source-specific multicast in Linux bridge and batman-adv -| * multicast TT announcements and forwarding have to be performed per +* implement source-specific multicast in Linux bridge and batman-adv +* multicast TT announcements and forwarding have to be performed per VLAN -| * ... +* ...
Further Readings ---------------- diff --git a/batman-adv/Quick-start-guide.rst b/batman-adv/Quick-start-guide.rst index 79491f1..b07c217 100644 --- a/batman-adv/Quick-start-guide.rst +++ b/batman-adv/Quick-start-guide.rst @@ -151,8 +151,6 @@ through the mesh according to the destination's mac address.
For the MTU-part have a look at the note above.
-** - Distribution specific examples ------------------------------
diff --git a/batman-adv/TVLV.rst b/batman-adv/TVLV.rst index 05a1c8b..7726b86 100644 --- a/batman-adv/TVLV.rst +++ b/batman-adv/TVLV.rst @@ -137,19 +137,21 @@ TVLV definitions Gateway announcement ~~~~~~~~~~~~~~~~~~~~
-| * tvlv type: 0x01 -| * function: Each batman-adv gateway server announces it's available +* tvlv type: 0x01 +* function: Each batman-adv gateway server announces it's available internet connection speed, so that batman-adv gateway clients can select their preferable server. -| * purpose: Every node keeps a list of batman-adv gateways in the mesh +* purpose: Every node keeps a list of batman-adv gateways in the mesh to later the preferred gateway. -| * length: 8 byte gateway bandwidth information -| * Fixed TVLV fields: -| **** gateway bandwidth down: announced gateway download bandwidth in - MBit/s/10 (4Bytes) -| **** gateway bandwidth up: announced gateway upload bandwidth in - MBit/s/10 (4Bytes) -| * definition: +* length: 8 byte gateway bandwidth information +* Fixed TVLV fields: + + - gateway bandwidth down: announced gateway download bandwidth in + MBit/s/10 (4Bytes) + - gateway bandwidth up: announced gateway upload bandwidth in + MBit/s/10 (4Bytes) + +* definition:
::
@@ -204,36 +206,42 @@ Network coding (also known as catwoman) Translation table messages ~~~~~~~~~~~~~~~~~~~~~~~~~~
-| * tvlv type: 0x04 -| * function: Local non-mesh clients advertisement mechanism. This +* tvlv type: 0x04 +* function: Local non-mesh clients advertisement mechanism. This particular component needs some parameters that are propagated by the OGM. -| * purpose: Exchange of translation table state information. -| * length: variable. It is equal to the size of the fixed TVLV field + +* purpose: Exchange of translation table state information. +* length: variable. It is equal to the size of the fixed TVLV field + the size of the TT VLAN headers + the size of the TT client change entries. -| * Fixed TVLV fields: -| **** flags: translation table flags (1Byte) -| **** ttvn: translation table version number (1Byte) -| **** num_vlan: number of TT VLAN data structures inside the tvlv - container (2Bytes) -| * Each TT VLAN data structure contains: -| **** crc: crc32 checksum of the local translation (sub-)table - containing entries belonging to this VLAN only (4Bytes) -| **** vid: the identifier of this VLAN (2Bytes) -| **** reserved: not used. Defined for alignment purposes (2Bytes) -| * Each TT client change (one per announced client) contains: -| **** flags: flags associated with this client -| **** reserved: not used. Defined for alignment purposes (3Bytes) -| **** addr: mac address of the announced client -| **** vid: identifier of the VLAN where this client is connected to -| * layout: +* Fixed TVLV fields: + + - flags: translation table flags (1Byte) + - ttvn: translation table version number (1Byte) + - num_vlan: number of TT VLAN data structures inside the tvlv + container (2Bytes) + +* Each TT VLAN data structure contains: + + - crc: crc32 checksum of the local translation (sub-)table + containing entries belonging to this VLAN only (4Bytes) + - vid: the identifier of this VLAN (2Bytes) + - reserved: not used. Defined for alignment purposes (2Bytes) + +* Each TT client change (one per announced client) contains: + + - flags: flags associated with this client + - reserved: not used. Defined for alignment purposes (3Bytes) + - addr: mac address of the announced client + - vid: identifier of the VLAN where this client is connected to + +* layout:
::
....
-* definition: +* definition:
::
@@ -282,18 +290,19 @@ Translation table messages Roaming Advertisement message ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-| * tvlv type: 0x05 -| * function: Reduce a non-mesh client's packet loss when it roams from +* tvlv type: 0x05 +* function: Reduce a non-mesh client's packet loss when it roams from one AP to the next. -| * purpose: Inform the old AP about the new location of the non-mesh +* purpose: Inform the old AP about the new location of the non-mesh client. -| * length: 8 bytes non-mesh client information -| * Fixed TVLV fields: -| **** client mac address: mac address of the roaming non-mesh client (6 - bytes) -| **** vid: vlan tag id of the roaming non-mesh client (2 bytes) +* length: 8 bytes non-mesh client information +* Fixed TVLV fields:
-* definition: + - client mac address: mac address of the roaming non-mesh client (6 + bytes) + - vid: vlan tag id of the roaming non-mesh client (2 bytes) + +* definition:
::
@@ -310,22 +319,23 @@ Roaming Advertisement message Multicast capability ~~~~~~~~~~~~~~~~~~~~
-| * tvlv type: 0x06 -| * function: Reduces the airtime consumed by multicast packets, e.g. +* tvlv type: 0x06 +* function: Reduces the airtime consumed by multicast packets, e.g. by using multicast awareness to decide whether a frame can be sent via unicast or dropped. -| * purpose: Lets other nodes know whether an originator is capable of +* purpose: Lets other nodes know whether an originator is capable of announcing its multicast listeners via the translation table. The flags further inform other nodes about whether an originator needs to receive all multicast traffic of a certain type. -| * length: 4 bytes (1 byte flag information) -| * Fixed TVLV fields: -| **** flags: multicast flags announced by the orig node (1 byte), see - [[Multicast-optimizations-flags|the multicast flags page]] for - details -| **** reserved: not used. Defined for alignment purposes (3 bytes) - -* definition: +* length: 4 bytes (1 byte flag information) +* Fixed TVLV fields: + + - flags: multicast flags announced by the orig node (1 byte), see + [[Multicast-optimizations-flags|the multicast flags page]] for + details + - reserved: not used. Defined for alignment purposes (3 bytes) + +* definition:
::
diff --git a/batman-adv/Understand-your-batman-adv-network.rst b/batman-adv/Understand-your-batman-adv-network.rst index 937161b..024af6b 100644 --- a/batman-adv/Understand-your-batman-adv-network.rst +++ b/batman-adv/Understand-your-batman-adv-network.rst @@ -35,14 +35,6 @@ neighbor table
::
- - - - -Sample output: - -:: - cat /sys/kernel/debug/batman_adv/bat0/neighbors [B.A.T.M.A.N. adv d5e8ba8, MainIF/MAC: eth0/fe:fe:00:00:01:01 (bat0 BATMAN_IV)] IF Neighbor last-seen @@ -52,15 +44,6 @@ Sample output:
::
- - - - - -Sample output: - -:: - cat /sys/kernel/debug/batman_adv/bat0/neighbors [B.A.T.M.A.N. adv 2016.1, MainIF/MAC: eth0/fe:fe:00:00:01:01 (bat1 BATMAN_V)] Neighbor last-seen ( throughput) [ IF] @@ -82,17 +65,6 @@ line contains information regarding a specific originator:
::
- - - - - - - -Sample output: - -:: - cat /sys/kernel/debug/batman_adv/bat0/originators [B.A.T.M.A.N. adv d5e8ba8, MainIF/MAC: eth0/fe:fe:00:00:01:01 (bat0 BATMAN_IV)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... @@ -102,17 +74,6 @@ Sample output:
::
- - - - - - - -Sample output: - -:: - cat /sys/kernel/debug/batman_adv/bat0/originators [B.A.T.M.A.N. adv 2016.1, MainIF/MAC: eth1/fe:fe:00:00:01:01 (bat0 BATMAN_V)] Originator last-seen ( throughput) Nexthop [outgoingIF]: Potential nexthops ... @@ -146,16 +107,6 @@ be found in the transtable_local file:
::
- - - - - - -Sample output: - -:: - cat /sys/kernel/debug/batman_adv/bat0/transtable_local Locally retrieved addresses (from bat0) announced via TT (TTVN: 2): Client VID Flags Last seen (CRC ) @@ -186,18 +137,6 @@ can be found in the transtable_global file:
::
- - - - - - - - -Sample output: - -:: - cat /sys/kernel/debug/batman_adv/bat0/transtable_global Globally announced TT entries received via the mesh bat0 Client VID (TTVN) Originator (Curr TTVN) (CRC ) Flags @@ -233,17 +172,6 @@ this feature). Each line contains information about a specific gateway:
::
- - - - - - - -For example: - -:: - Gateway (#/255) Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2014.0.0, MainIF/MAC: eth0/fe:fe:00:00:01:01 (bat0)] fe:fe:00:00:01:01 (233) fe:fe:00:00:01:01 [ eth0]: 2.0/0.5 MBit => fe:fe:00:00:02:01 (255) fe:fe:00:00:02:01 [ eth0]: 10.0/2.0 MBit @@ -256,18 +184,10 @@ avoidance]] code and contains all claimed clients as announced on the bridge. Each line contains a claimed non-mesh client propagated through the mesh:
-:: - - - - - - - Note:
-| * Clients claimed by the node itself are marked with an '[x]'. -| * If no VLAN was found a VID of '-1' is printed. +* Clients claimed by the node itself are marked with an '[x]'. +* If no VLAN was found a VID of '-1' is printed.
::
@@ -285,20 +205,12 @@ avoidance]] code and contains all backbone gateways. Each line contains a backbone gateway which is reachable via LAN and mesh (that means, it is in the same bla group):
-:: - - - - - - - Note:
-| * the own originator address is not printed, only other backbone +* the own originator address is not printed, only other backbone gateways -| * If no VLAN was found a VID of '-1' is printed. -| * the last seen time should be between 0 and 10 seconds if there is +* If no VLAN was found a VID of '-1' is printed. +* the last seen time should be between 0 and 10 seconds if there is no packet lost
:: @@ -323,13 +235,6 @@ Distributed ARP Table - local cache table which the node is in charge to handle in the [[DistributedARPTable-technical|DHT]]
-:: - - - - - - For example:
:: @@ -355,12 +260,6 @@ NC code to search for potential coding opportunities, where a relay determines if two receivers are likely to be able to decode a network coded transmission.
-:: - - - - - This example shows the entry for the one-hop originator with address fe:fe:00:00:02:01. Since a originator can always overhear packets to and from itself, its own address is listed as the first. In this case, the