diff options
author | Sven Eckelmann <sven@narfation.org> | 2010-12-13 06:19:28 -0500 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2010-12-16 16:44:24 -0500 |
commit | c6c8fea29769d998d94fcec9b9f14d4b52b349d3 (patch) | |
tree | 2c8dc8d1a64d48c5737a5745e3c510ff53a23047 /Documentation/networking | |
parent | b236da6931e2482bfe44a7865dd4e7bb036f3496 (diff) |
net: Add batman-adv meshing protocol
B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is a routing
protocol for multi-hop ad-hoc mesh networks. The networks may be wired or
wireless. See http://www.open-mesh.org/ for more information and user space
tools.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation/networking')
-rw-r--r-- | Documentation/networking/batman-adv.txt | 240 |
1 files changed, 240 insertions, 0 deletions
diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt new file mode 100644 index 000000000000..77f0cdd5b0dd --- /dev/null +++ b/Documentation/networking/batman-adv.txt | |||
@@ -0,0 +1,240 @@ | |||
1 | [state: 21-11-2010] | ||
2 | |||
3 | BATMAN-ADV | ||
4 | ---------- | ||
5 | |||
6 | Batman advanced is a new approach to wireless networking which | ||
7 | does no longer operate on the IP basis. Unlike the batman daemon, | ||
8 | which exchanges information using UDP packets and sets routing | ||
9 | tables, batman-advanced operates on ISO/OSI Layer 2 only and uses | ||
10 | and routes (or better: bridges) Ethernet Frames. It emulates a | ||
11 | virtual network switch of all nodes participating. Therefore all | ||
12 | nodes appear to be link local, thus all higher operating proto- | ||
13 | cols won't be affected by any changes within the network. You can | ||
14 | run almost any protocol above batman advanced, prominent examples | ||
15 | are: IPv4, IPv6, DHCP, IPX. | ||
16 | |||
17 | Batman advanced was implemented as a Linux kernel driver to re- | ||
18 | duce the overhead to a minimum. It does not depend on any (other) | ||
19 | network driver, and can be used on wifi as well as ethernet lan, | ||
20 | vpn, etc ... (anything with ethernet-style layer 2). | ||
21 | |||
22 | CONFIGURATION | ||
23 | ------------- | ||
24 | |||
25 | Load the batman-adv module into your kernel: | ||
26 | |||
27 | # insmod batman-adv.ko | ||
28 | |||
29 | The module is now waiting for activation. You must add some in- | ||
30 | terfaces on which batman can operate. After loading the module | ||
31 | batman advanced will scan your systems interfaces to search for | ||
32 | compatible interfaces. Once found, it will create subfolders in | ||
33 | the /sys directories of each supported interface, e.g. | ||
34 | |||
35 | # ls /sys/class/net/eth0/batman_adv/ | ||
36 | # iface_status mesh_iface | ||
37 | |||
38 | If an interface does not have the "batman_adv" subfolder it prob- | ||
39 | ably is not supported. Not supported interfaces are: loopback, | ||
40 | non-ethernet and batman's own interfaces. | ||
41 | |||
42 | Note: After the module was loaded it will continuously watch for | ||
43 | new interfaces to verify the compatibility. There is no need to | ||
44 | reload the module if you plug your USB wifi adapter into your ma- | ||
45 | chine after batman advanced was initially loaded. | ||
46 | |||
47 | To activate a given interface simply write "bat0" into its | ||
48 | "mesh_iface" file inside the batman_adv subfolder: | ||
49 | |||
50 | # echo bat0 > /sys/class/net/eth0/batman_adv/mesh_iface | ||
51 | |||
52 | Repeat this step for all interfaces you wish to add. Now batman | ||
53 | starts using/broadcasting on this/these interface(s). | ||
54 | |||
55 | By reading the "iface_status" file you can check its status: | ||
56 | |||
57 | # cat /sys/class/net/eth0/batman_adv/iface_status | ||
58 | # active | ||
59 | |||
60 | To deactivate an interface you have to write "none" into its | ||
61 | "mesh_iface" file: | ||
62 | |||
63 | # echo none > /sys/class/net/eth0/batman_adv/mesh_iface | ||
64 | |||
65 | |||
66 | All mesh wide settings can be found in batman's own interface | ||
67 | folder: | ||
68 | |||
69 | # ls /sys/class/net/bat0/mesh/ | ||
70 | # aggregated_ogms bonding fragmentation orig_interval | ||
71 | # vis_mode | ||
72 | |||
73 | |||
74 | There is a special folder for debugging informations: | ||
75 | |||
76 | # ls /sys/kernel/debug/batman_adv/bat0/ | ||
77 | # originators socket transtable_global transtable_local | ||
78 | # vis_data | ||
79 | |||
80 | |||
81 | Some of the files contain all sort of status information regard- | ||
82 | ing the mesh network. For example, you can view the table of | ||
83 | originators (mesh participants) with: | ||
84 | |||
85 | # cat /sys/kernel/debug/batman_adv/bat0/originators | ||
86 | |||
87 | Other files allow to change batman's behaviour to better fit your | ||
88 | requirements. For instance, you can check the current originator | ||
89 | interval (value in milliseconds which determines how often batman | ||
90 | sends its broadcast packets): | ||
91 | |||
92 | # cat /sys/class/net/bat0/mesh/orig_interval | ||
93 | # 1000 | ||
94 | |||
95 | and also change its value: | ||
96 | |||
97 | # echo 3000 > /sys/class/net/bat0/mesh/orig_interval | ||
98 | |||
99 | In very mobile scenarios, you might want to adjust the originator | ||
100 | interval to a lower value. This will make the mesh more respon- | ||
101 | sive to topology changes, but will also increase the overhead. | ||
102 | |||
103 | |||
104 | USAGE | ||
105 | ----- | ||
106 | |||
107 | To make use of your newly created mesh, batman advanced provides | ||
108 | a new interface "bat0" which you should use from this point on. | ||
109 | All interfaces added to batman advanced are not relevant any | ||
110 | longer because batman handles them for you. Basically, one "hands | ||
111 | over" the data by using the batman interface and batman will make | ||
112 | sure it reaches its destination. | ||
113 | |||
114 | The "bat0" interface can be used like any other regular inter- | ||
115 | face. It needs an IP address which can be either statically con- | ||
116 | figured or dynamically (by using DHCP or similar services): | ||
117 | |||
118 | # NodeA: ifconfig bat0 192.168.0.1 | ||
119 | # NodeB: ifconfig bat0 192.168.0.2 | ||
120 | # NodeB: ping 192.168.0.1 | ||
121 | |||
122 | Note: In order to avoid problems remove all IP addresses previ- | ||
123 | ously assigned to interfaces now used by batman advanced, e.g. | ||
124 | |||
125 | # ifconfig eth0 0.0.0.0 | ||
126 | |||
127 | |||
128 | VISUALIZATION | ||
129 | ------------- | ||
130 | |||
131 | If you want topology visualization, at least one mesh node must | ||
132 | be configured as VIS-server: | ||
133 | |||
134 | # echo "server" > /sys/class/net/bat0/mesh/vis_mode | ||
135 | |||
136 | Each node is either configured as "server" or as "client" (de- | ||
137 | fault: "client"). Clients send their topology data to the server | ||
138 | next to them, and server synchronize with other servers. If there | ||
139 | is no server configured (default) within the mesh, no topology | ||
140 | information will be transmitted. With these "synchronizing | ||
141 | servers", there can be 1 or more vis servers sharing the same (or | ||
142 | at least very similar) data. | ||
143 | |||
144 | When configured as server, you can get a topology snapshot of | ||
145 | your mesh: | ||
146 | |||
147 | # cat /sys/kernel/debug/batman_adv/bat0/vis_data | ||
148 | |||
149 | This raw output is intended to be easily parsable and convertable | ||
150 | with other tools. Have a look at the batctl README if you want a | ||
151 | vis output in dot or json format for instance and how those out- | ||
152 | puts could then be visualised in an image. | ||
153 | |||
154 | The raw format consists of comma separated values per entry where | ||
155 | each entry is giving information about a certain source inter- | ||
156 | face. Each entry can/has to have the following values: | ||
157 | -> "mac" - mac address of an originator's source interface | ||
158 | (each line begins with it) | ||
159 | -> "TQ mac value" - src mac's link quality towards mac address | ||
160 | of a neighbor originator's interface which | ||
161 | is being used for routing | ||
162 | -> "HNA mac" - HNA announced by source mac | ||
163 | -> "PRIMARY" - this is a primary interface | ||
164 | -> "SEC mac" - secondary mac address of source | ||
165 | (requires preceding PRIMARY) | ||
166 | |||
167 | The TQ value has a range from 4 to 255 with 255 being the best. | ||
168 | The HNA entries are showing which hosts are connected to the mesh | ||
169 | via bat0 or being bridged into the mesh network. The PRIMARY/SEC | ||
170 | values are only applied on primary interfaces | ||
171 | |||
172 | |||
173 | LOGGING/DEBUGGING | ||
174 | ----------------- | ||
175 | |||
176 | All error messages, warnings and information messages are sent to | ||
177 | the kernel log. Depending on your operating system distribution | ||
178 | this can be read in one of a number of ways. Try using the com- | ||
179 | mands: dmesg, logread, or looking in the files /var/log/kern.log | ||
180 | or /var/log/syslog. All batman-adv messages are prefixed with | ||
181 | "batman-adv:" So to see just these messages try | ||
182 | |||
183 | # dmesg | grep batman-adv | ||
184 | |||
185 | When investigating problems with your mesh network it is some- | ||
186 | times necessary to see more detail debug messages. This must be | ||
187 | enabled when compiling the batman-adv module. When building bat- | ||
188 | man-adv as part of kernel, use "make menuconfig" and enable the | ||
189 | option "B.A.T.M.A.N. debugging". | ||
190 | |||
191 | Those additional debug messages can be accessed using a special | ||
192 | file in debugfs | ||
193 | |||
194 | # cat /sys/kernel/debug/batman_adv/bat0/log | ||
195 | |||
196 | The additional debug output is by default disabled. It can be en- | ||
197 | abled during run time. Following log_levels are defined: | ||
198 | |||
199 | 0 - All debug output disabled | ||
200 | 1 - Enable messages related to routing / flooding / broadcasting | ||
201 | 2 - Enable route or hna added / changed / deleted | ||
202 | 3 - Enable all messages | ||
203 | |||
204 | The debug output can be changed at runtime using the file | ||
205 | /sys/class/net/bat0/mesh/log_level. e.g. | ||
206 | |||
207 | # echo 2 > /sys/class/net/bat0/mesh/log_level | ||
208 | |||
209 | will enable debug messages for when routes or HNAs change. | ||
210 | |||
211 | |||
212 | BATCTL | ||
213 | ------ | ||
214 | |||
215 | As batman advanced operates on layer 2 all hosts participating in | ||
216 | the virtual switch are completely transparent for all protocols | ||
217 | above layer 2. Therefore the common diagnosis tools do not work | ||
218 | as expected. To overcome these problems batctl was created. At | ||
219 | the moment the batctl contains ping, traceroute, tcpdump and | ||
220 | interfaces to the kernel module settings. | ||
221 | |||
222 | For more information, please see the manpage (man batctl). | ||
223 | |||
224 | batctl is available on http://www.open-mesh.org/ | ||
225 | |||
226 | |||
227 | CONTACT | ||
228 | ------- | ||
229 | |||
230 | Please send us comments, experiences, questions, anything :) | ||
231 | |||
232 | IRC: #batman on irc.freenode.org | ||
233 | Mailing-list: b.a.t.m.a.n@b.a.t.m.a.n@lists.open-mesh.org | ||
234 | (optional subscription at | ||
235 | https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n) | ||
236 | |||
237 | You can also contact the Authors: | ||
238 | |||
239 | Marek Lindner <lindner_marek@yahoo.de> | ||
240 | Simon Wunderlich <siwu@hrz.tu-chemnitz.de> | ||