Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2017-07-13,master
commit c3a40d61dbf51b215e85fbd4dfdc2445c4e3c519 Author: Marek Lindner mareklindner@neomailbox.ch Date: Tue Nov 30 01:36:15 2010 +0000
doc: batman-adv/Wiki
c3a40d61dbf51b215e85fbd4dfdc2445c4e3c519 batman-adv/Wiki.textile | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/batman-adv/Wiki.textile b/batman-adv/Wiki.textile index 0e26e004..9545b7c3 100644 --- a/batman-adv/Wiki.textile +++ b/batman-adv/Wiki.textile @@ -1,28 +1,36 @@ -= B.A.T.M.A.N. advanced =
-{{{ -#!div style="width: 46em; text-align: justify" +h1. B.A.T.M.A.N. advanced
-B.A.T.M.A.N. advanced (often referenced as batman-adv) is an implementation of the B.A.T.M.A.N. routing protocol in form of a linux kernel module operating on layer 2. The rest of this document will explain the conceptual details and their implications. If you are looking for explanations how to use the module, please consult our [wiki:batman-adv-quick-start-guide quick start guide].
-=== Layer 2 ? === +<pre> +<code class="div"> + +B.A.T.M.A.N. advanced (often referenced as batman-adv) is an implementation of the B.A.T.M.A.N. routing protocol in form of a linux kernel module operating on layer 2. The rest of this document will explain the conceptual details and their implications. If you are looking for explanations how to use the module, please consult our [[batman-adv-quick-start-guide|quick start guide]]. + + +h3. Layer 2 ? +
Most other wireless routing protocol implementations (e.g. the batman daemon) operate on layer 3 which means they exchange routing information by sending UDP packets and bring their routing decision into effect by manipulating the kernel routing table. Batman-adv operates entirely on ISO/OSI Layer 2 - not only the routing information is transported using raw ethernet frames but also the data traffic is handled by batman-adv. It encapsulates and forwards all traffic until it reaches the destination, hence emulating a virtual network switch of all nodes participating. Therefore all nodes appear to be link local and are unaware of the network's topology as well as unaffected by any network changes.
This design bears some interesting characteristics: - * network-layer agnostic - you can run whatever you wish on top of batman-adv: IPv4, IPv6, DHCP, IPX .. - * nodes can participate in a mesh without having an IP - * easy integration of non-mesh (mobile) clients (no manual HNA fiddling required) - * roaming of non-mesh clients - * optimizing the data flow through the mesh (e.g. interface alternating, multicast, forward error correction, etc) +* network-layer agnostic - you can run whatever you wish on top of batman-adv: IPv4, IPv6, DHCP, IPX .. +* nodes can participate in a mesh without having an IP +* easy integration of non-mesh (mobile) clients (no manual HNA fiddling required) +* roaming of non-mesh clients +* optimizing the data flow through the mesh (e.g. interface alternating, multicast, forward error correction, etc) + + +h3. A kernel module ?
-=== A kernel module ? ===
A layer 2 routing protocol also has to handle the data traffic because usually one can't route/forward ethernet packets. Processing packets in userland is very expensive in terms of CPU cycles, as each packet has to be read() and write() to the kernel and back, which limits the sustainable bandwidth especially on low-end devices. To have good support for these devices as well, we implemented batman-adv as a kernel driver. It introduces a negligible packet processing overhead even under a high load.
-=== batctl ? === + +h3. batctl ? +
To still have a handy tool to configure & debug the batman-adv kernel module, the batctl tool was developed. It offers a convenient interface to all the module's settings as well as status information. It also contains a layer 2 version of ping, traceroute and tcpdump, since the virtual network switch is completely transparent for all protocols above layer 2.
-}}} +</code></pre>