* replaced the bmf plugin with the most recent 1.3 from sf.net with the
[olsrd.git] / lib / bmf / README_BMF.txt
1 BASIC MULTICAST FORWARDING PLUGIN FOR OLSRD
2 by Erik Tromp (erik.tromp@nl.thalesgroup.com, erik_tromp@hotmail.com)
3 Version 1.3
4
5 1. Introduction
6 ---------------
7
8 The Basic Multicast Forwarding Plugin floods IP-multicast and
9 IP-local-broadcast traffic over an OLSRD network. It uses the
10 Multi-Point Relays (MPRs) as identified by the OLSR protocol
11 to optimize the flooding of multicast and local broadcast packets
12 to all the hosts in the network. To prevent broadcast storms, a
13 history of packets is kept; only packets that have not been seen
14 in the past 3-6 seconds are forwarded.
15
16
17 2. How to build and install
18 ---------------------------
19
20 Download the olsr-bmf-v1.3.tar.gz file and save it into your OLSRD
21 base install directory.
22
23 Change directory (cd) to your OLSRD base install directory.
24
25 At the command prompt, type:
26
27   tar -zxvf ./olsr-bmf-v1.3.tar.gz
28
29 then type:
30
31   make build_all
32
33 followed by:
34
35   make install_all
36
37 Next, turn on the possibility to create a tuntap interface (see also
38 /usr/src/linux/Documentation/networking/tuntap.txt):
39
40   mkdir /dev/net # if it doesn't exist already
41   mknod /dev/net/tun c 10 200
42   
43 Set permissions, e.g.:
44
45   chmod 0700 /dev/net/tun
46
47 To configure BMF in OLSR, you must edit the file /etc/olsrd.conf
48 to load the BMF plugin. For example, add the following lines:
49
50   LoadPlugin "olsrd_bmf.so.1.3"
51   {
52     # No PlParam entries required for basic operation
53   }
54
55
56 3. How to run
57 -------------
58
59 After building and installing OLSRD with the BMF plugin, run the
60 olsrd daemon by entering at the shell prompt:
61
62   olsrd
63
64 Look at the output; it should list the BMF plugin, e.g.:
65
66   ---------- Plugin loader ----------
67   Library: olsrd_bmf.so.1.3
68   OLSRD Basic Multicast Forwarding plugin 1.3 (Dec 18 2006 11:23:51)
69     (C) Thales Communications Huizen, Netherlands
70     Erik Tromp (erik.tromp@nl.thalesgroup.com)
71   Checking plugin interface version...  4 - OK
72   Trying to fetch plugin init function... OK
73   Trying to fetch param function... OK
74   Sending parameters...
75   "NonOlsrIf"/"eth0"... OK
76   Running plugin_init function...
77   OLSRD Basic Multicast Forwarding (BMF) plugin: opened 6 sockets
78   ---------- LIBRARY LOADED ----------
79
80
81 4. How to check if it works
82 ---------------------------
83
84 Enter the following command on the command prompt:
85   
86   ping 224.0.0.1
87     
88 All OLSR-BMF hosts in the OLSR network should respond. For example,
89 assume we have three hosts, with IP addresses 192.168.151.50,
90 192.168.151.53 and 192.168.151.55. On host 192.168.151.50 we enter
91 the following ping command:
92
93 root@IsdbServer:~# ping 224.0.0.1
94 PING 224.0.0.1 (224.0.0.1) from 192.168.151.50 eth1: 56(84) bytes of data.
95 64 bytes from 192.168.151.50: icmp_seq=1 ttl=64 time=0.511 ms
96 64 bytes from 192.168.151.53: icmp_seq=1 ttl=64 time=4.67 ms (DUP!)
97 64 bytes from 192.168.151.55: icmp_seq=1 ttl=63 time=10.7 ms (DUP!)
98 64 bytes from 192.168.151.50: icmp_seq=2 ttl=64 time=0.076 ms
99 64 bytes from 192.168.151.53: icmp_seq=2 ttl=64 time=1.23 ms (DUP!)
100 64 bytes from 192.168.151.55: icmp_seq=2 ttl=63 time=1.23 ms (DUP!)
101 64 bytes from 192.168.151.50: icmp_seq=3 ttl=64 time=0.059 ms
102 64 bytes from 192.168.151.53: icmp_seq=3 ttl=64 time=2.94 ms (DUP!)
103 64 bytes from 192.168.151.55: icmp_seq=3 ttl=63 time=5.62 ms (DUP!)
104 64 bytes from 192.168.151.50: icmp_seq=4 ttl=64 time=0.158 ms
105 64 bytes from 192.168.151.53: icmp_seq=4 ttl=64 time=1.14 ms (DUP!)
106 64 bytes from 192.168.151.55: icmp_seq=4 ttl=63 time=1.16 ms (DUP!)
107
108 We can see the response from the originating host (192.168.151.50)
109 (it is normal behaviour for hosts sending multicast packets to
110 receive their own packets). We can also see the responses by the
111 other hosts (correctly seen as DUPlicates by ping).
112
113
114 5. How does it work
115 -------------------
116
117 In the IP header there is room for only two IP-addresses:
118 * the destination IP address (in our case either a multicast
119   IP-address 224.0.0.0...239.255.255.255, or a local broadcast
120   address e.g. 192.168.1.255), and
121 * the source IP address (the originator).
122
123 For optimized flooding, however, we need more information. Let's
124 assume we are the BMF process on one host. We will need to know which
125 host forwarded the IP packet to us. Since OLSR keeps track of which
126 hosts select our host as MPR (see the olsr_lookup_mprs_set(...) function),
127 we can determine if the host that forwarded the packet, has selected us as
128 MPR. If so, we must also forward the packet, changing the 'forwarded-by'
129 IP-address to that of us. If not, we do not forward the packet.
130
131 Because we need more information than fits in a normal IP-header, the
132 original packets are encapsulated into a new IP packet. Encapsulated
133 packets are transported in UDP, port 50698. The source address of the
134 encapsulation packet is set to the address of the forwarder instead of
135 the originator. Of course, the payload of the encapsulation packet is
136 the original IP packet.
137
138 For local reception, each received encapsulated packets is unpacked
139 and passed into a tuntap interface which is specially created for
140 this purpose.
141
142 There are other flooding solutions available that do not use
143 encapsulation. The problem with these solutions is that they cannot
144 prevent duplicates of forwarded packets to enter the IP stack. For
145 example, if a host is receiving flooded (unencapsulated, native IP)
146 packets via two MPR hosts, there is no way to stop the reception of
147 the packets coming in via the second MPR host. To prevent this, BMF
148 uses a combination of encapsulated flooding and local reception via
149 a tuntap interface.
150
151 Here is in short how the flooding works (see also the
152 BmfEncapsulatedPacketReceived(...) function; details with respect to
153 the forwarding towards non-OLSR enabled hosts are omitted):
154   
155   On all OLSR-enabled interfaces, setup reception of packets
156     on UDP port 50698.
157   Upon reception of such a packet:
158     If the received packet was sent by myself, drop it.
159     If the packet was recently seen, drop it.
160     Unpack the encapsulated packet and send a copy to myself via the
161       TunTap interface.
162     If I am an MPR for the host that forwarded the packet to me,
163       forward the packet to all OLSR-enabled interfaces *including*
164       the interface on which it was received.
165
166
167 6. Advanced configuration
168 -------------------------
169
170 All configuration of BMF is done via the "LoadPlugin" section in
171 the /etc/olsrd.conf file.
172
173 The following gives an overview of all plugin parameters that can be
174 configured:
175
176   LoadPlugin "olsrd_bmf.so.1.3"
177   {
178     # Specify the name of the BMF network interface.
179     # Defaults to "bmf0".
180     PlParam "BmfInterface" "mybmf0"
181
182     # Specify the type of the BMF network interface: either "tun" or
183     # "tap". Defaults to "tun".
184     PlParam "BmfInterfaceType" "tap"
185
186     # Specify the IP address and mask for the BMF network interface.
187     # By default, the IP address of the first OLSR interface is copied.
188     # The default prefix length is 32.
189     PlParam "BmfInterfaceIp" "10.10.10.234/24"
190
191     # Enable or disable the flooding of local broadcast packets
192     # (e.g. packets with IP destination 192.168.1.255). Either "yes"
193     # or "no". Defaults to "yes".
194     PlParam "DoLocalBroadcast" "no"
195
196     # Enable or disable the capturing packets on the OLSR-enabled
197     # interfaces (in promiscuous mode). Either "yes" or "no". Defaults
198     # to "no".
199     # The multicast (and, if configured, local broadcast) packets sent on
200     # the non-OLSR network interfaces and on the BMF network interface will
201     # always be flooded over the OLSR network.
202     # If this parameter is "yes", also the packets sent on the OLSR-enabled
203     # network interfaces will be flooded over the OLSR network.
204     # NOTE: This parameter should be set consistently on all hosts throughout
205     # the network. If not, hosts may receive multicast packets in duplicate.
206     PlParam "CapturePacketsOnOlsrInterfaces" "yes"
207
208     # List of non-OLSR interfaces to include
209     PlParam     "NonOlsrIf"  "eth2"
210     PlParam     "NonOlsrIf"  "eth3"
211   }
212
213 BmfInterfaceIp
214 --------------
215
216 By default, the BMF network interface will get the IP address of the
217 first OLSR interface, with a prefix length of 32. Having two network
218 interfaces with the same IP address may seem strange, but it is not
219 a problem, since the BMF network interface is not used in any point-to-
220 point routing.
221
222 The advantage of assigning a known OLSR IP address to the BMF network
223 interface is that multicast packets, sent via the BMF network interface,
224 get a known IP source address, to which the receivers of the packets
225 can reply. That is useful when using, for example, the command
226 "ping 224.0.0.1".
227
228 An advantage of using a prefix length of 32 is that the Linux IP
229 stack will not automatically enter a subnet routing entry (via the BMF
230 network interface) into the kernel routing table. Such a routing entry
231 would be useless, because the BMF network interface does not forward
232 point-to-point traffic.
233
234 If you configure a specific IP address and mask via the "BmfInterfaceIp"
235 parameter, BMF will cause the specified IP host address to be advertised
236 into the OLSR network via the HNA mechanism, so that the other hosts in
237 the network know how to route back.
238
239 CapturePacketsOnOlsrInterfaces
240 ------------------------------
241
242 If "CapturePacketsOnOlsrInterfaces" is set to "yes", any multicast
243 or local broadcast IP packet, sent by an application on *any* OLSR
244 interface, will be flooded over the OLSR network. Each OLSR host
245 will receive the packet on its BMF network interface, "bmf0". The
246 OLSR-interfaces will be in promiscuous mode to capture the multicast
247 or local broadcast packets.
248
249 For example, if "eth1" is an OLSR interface, the following command
250 will result in one response from each OLSR host in the network:
251
252   ping -I eth1 224.0.0.1
253
254 A disadvantage of this configuration is that a host may, in rare
255 cases, receive a multicast packet twice. This is best explained
256 by looking at the following network diagram:
257
258         eth0   eth0
259       A ----------- B
260  eth1 |            / eth1
261       |           /
262  eth0 |          /
263       C --------+
264         eth1
265
266 Suppose host A is running a ping session that is sending ping
267 packets on "eth1". The BMF process on host A will see the outgoing
268 packets on "eth1", encapsulates these packets and sends the
269 encapsulated packets on "eth0". Let's assume we are using the link
270 quality extensions of OLSR, and the 2-hop path A - B - C is better
271 (in terms of ETX) than the 1-hop path A - C. In that case host B is
272 an MPR for host A. Host B receives the encapsulated packets of host A
273 on its "eth0" interface, and, since it is an MPR, it decides to
274 forward them on "eth1".
275
276 In most cases, host C will receive the original, unencapsulated
277 ping packet on its "eth0" interface before the encapsulated
278 ping packet from host B arrives on its "eth1" interface. When the
279 encapsulated packet from B arrives, the BMF process will then see
280 that it is a duplicate and discard it.
281
282 However, in the IP world, there are no guarantees, so it may
283 happen that host C receives the encapsulated packet from host B
284 first. That packet is then unpacked and locally delivered to the
285 BMF network interface "bmf0". When the original, unencapsulated
286 packet then comes in on "eth0", there is no way to stop it from
287 being received (for a second time) by the Linux IP stack.
288
289 As said, this may be a rare case. Besides, most applications
290 can deal with a duplicate reception of the same packet. But if
291 you're a purist and want everything to work correct, you should
292 leave "CapturePacketsOnOlsrInterfaces" to its default value "no".
293
294 A disadvantage of leaving "CapturePacketsOnOlsrInterfaces" to its
295 default value "no" is that all multicast traffic must go via the
296 BMF network interface "bmf0". However, this should not be a problem,
297 since a route to all multicast addresses via the BMF network
298 interface "bmf0" is automatically added when BMF is started.
299
300
301 7. Adding non-OLSR interfaces to the multicast flooding
302 -------------------------------------------------------
303
304 As a special feature, it is possible to also forward from and to
305 non-OLSR interfaces.
306
307 If you have network interfaces on which OLSR is *not* running, but you *do*
308 want to forward multicast and local-broadcast IP packets, specify these
309 interfaces one by one as "NonOlsrIf" parameters in the BMF plugin section
310 of /etc/olsrd.conf. For example:
311
312   LoadPlugin "olsrd_bmf.so.1.3"
313   {
314     # Non-OLSR interfaces to participate in the multicast flooding
315     PlParam     "NonOlsrIf"  "eth2"
316     PlParam     "NonOlsrIf"  "eth3"
317   }
318
319 If an interface is listed both as "NonOlsrIf" for BMF, and in the
320 Interfaces { ... } section of olsrd.conf, it will be seen by BMF
321 as an OLSR-enabled interface.
322
323
324 8. Interworking with other multicast routers
325 --------------------------------------------
326
327 In a typical interworking configuration there is a network of OLSR hosts
328 in which one host acts as a gateway to a fixed infrastructure network.
329 Usually that host will be advertising a default route via the HNA
330 mechanism, e.g. by adding the following lines to its /etc/olsrd.conf
331 file:
332
333   Hna4
334   {
335   #   Internet gateway:
336       0.0.0.0      0.0.0.0
337   }
338
339 Alternatively, the gateway is running OLSRDs dynamic internet gateway
340 plugin; read the file ../../lib/dyn_gw/README_DYN_GW .
341
342 The gateway host will usually have at least one OLSR-interface, and
343 at least one non-OLSR interface, running a third-party routing protocol
344 like OSPF.
345
346 It is beyond the scope of this document to deal with the interworking
347 between BMF and all possible multicast routing daemons. As an example,
348 let's assume the gateway is running the mrouted multicast daemon (which
349 implements the DVMRP protocol). Also, assume that all the IP addresses
350 in the OLSR network are within the IP subnet 10.0.0.0/8 . Then mrouted
351 on the gateway needs to be configured to accept IGMP requests from IP
352 clients within the 10.0.0.0/8 subnet on the BMF network interface
353 ("bmf0"). This is easily configured by adding a line to the
354 /etc/mrouted.conf configuration file:
355
356   phyint bmf0 altnet 10.0.0.0/8
357
358 Not strictly necessary, but clean, is to disable the DVMRP protocol
359 on the OLSR interfaces, as no DVMRP routers are expected inside the
360 OLSR network. Suppose the gateway is running OLSR on "eth1", then
361 add the following line /etc/mrouted.conf :
362
363   phyint eth1 disable
364
365 Finally, mrouted does not accept interfaces with prefix length 32.
366 Therefore, override the default IP address and prefix length of
367 the BMF network interface, by editing the /etc/olsrd.conf file.
368 For example:
369
370   LoadPlugin "olsrd_bmf.so.1.3"
371   {
372       PlParam "BmfInterfaceIp" "10.10.10.4/24"
373   }
374
375 Note that it is not necessary, and even incorrect, to pass the
376 non-OLSR interface to BMF as a "NonOlsrIf" parameter in the
377 "LoadPlugin" section of the gateway host. When the mrouted
378 multicast daemon is running, the forwarding of multicast traffic
379 between the OLSR interface and the non-OLSR interface is done by
380 the Linux kernel.
381
382 The remaining text in this section has nothing to do with BMF or
383 OLSR, but is added to give a number of helpful hints you might
384 need when your multicast interworking, for some reason, is not working.
385
386 When using the mrouted multicast daemon, there is a useful command,
387 mrinfo, that gives information about what mrouted thinks of its
388 neighbor hosts. For example:
389
390   root@node-4:/# mrinfo
391   127.0.0.1 (localhost.localdomain) [DVMRPv3 compliant]:
392     10.1.2.4 -> 10.1.2.2 (10.1.2.2) [1/1/querier]
393     10.0.6.4 -> 0.0.0.0 (local) [1/1/disabled]
394     10.255.255.253 -> 0.0.0.0 (local) [1/1/querier/leaf]
395
396 In this example, the line starting with "10.1.2.4" is for the
397 non-OLSR interface "eth0", on which mrouted has found an
398 mrouted-neighbor host "10.1.2.2". The next line is for the OLSR
399 interface "eth1", which is disabled for mrouted. The last line
400 is for the BMF interface "bmf0". It is clear that mrouted sees no
401 mrouted-neighbors on that interface (leaf).
402
403 To see what multicast traffic has flown through the gateway, view
404 the files /proc/net/ip_mr_vif and /proc/net/ip_mr_cache:
405
406   root@node-4:/# cat /proc/net/ip_mr_vif
407   Interface      BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote
408    0 eth0          27832      98     14200      50 00000 0402010A 00000000
409    2 bmf0          14484      51     13916      49 00000 FDFFFF0A 00000000
410   root@node-4:/# cat /proc/net/ip_mr_cache
411   Group    Origin   Iif     Pkts    Bytes    Wrong Oifs
412   4D4237EA C747010A 0         51    14484        0  2:1
413   4D4237EA C702010A 0         51    14484        0  2:1
414   4D4237EA C84C000A 2         53    15052        0  0:1
415
416 From the above we can deduce that traffic from input interface 0
417 (Iif 0, "eth0") is forwarded on output interface 2 (Oifs 2, = "bmf0"),
418 and traffic from input interface 2 (Iif 2, "bmf0") is forwarded on
419 output interface 0 (Oifs 0, "eth0"). The ":1" behind the Oifs numbers
420 indicates the TTL thresholds, in this case packets with TTL value 1
421 or less will not be forwarded.
422
423 When you are connecting an OLSR-BMF network to another multicast network
424 (e.g. a DVMRP network), you might be surprised that, when you ping the
425 all-routers multicast address 224.0.0.1 from within the OLSR network,
426 only the OLSR hosts respond. This is, however, compliant behaviour:
427 packets with their destination IP address in the range 224.0.0.0 -
428 224.0.0.255 are not routed by normal multicast protocols (i.e. their
429 TTL is implicitly assumed to be 1).
430
431
432 9. Testing in a lab environment
433 -------------------------------
434
435 When using equipment like switches or hubs, usually all the hosts see each
436 other. In an OLSR lab environment, we sometimes want to simulate the
437 situation that some hosts in the network cannot directly see other hosts
438 (as 1-hop neighbors) but only indirectly (as 2- or more-hop neighbors).
439 To simulate that situation, the iptables tool is often used. For BMF,
440 however, that is nog enough.
441
442 For OLSR testing, setup iptables on each host to drop packets from
443 all other hosts which are not direct (1-hop) neigbors. For example, to
444 drop all packets from the hosts with MAC addresses 00:0C:29:51:32:88,
445 00:0C:29:61:34:B7 and 00:0C:29:28:0E:CC, enter at the shell prompt:
446
447   iptables -A INPUT -m mac --mac-source 00:0C:29:51:32:88 -j DROP
448   iptables -A INPUT -m mac --mac-source 00:0C:29:61:34:B7 -j DROP
449   iptables -A INPUT -m mac --mac-source 00:0C:29:28:0E:CC -j DROP
450
451 For BMF testing, edit the file /etc/olsrd.conf, and specify the MAC
452 addresses of the hosts we do not want to see. (Even though packets from
453 these hosts are dropped by iptables, they are still received on network
454 interfaces if they are in promiscuous mode.) For example:
455
456   LoadPlugin "olsrd_bmf.so.1.3"
457   {
458     # Drop all packets received from the following MAC sources
459     PlParam     "DropMac"    "00:0C:29:51:32:88" # RemoteClient1
460     PlParam     "DropMac"    "00:0C:29:61:34:B7" # SimpleClient1
461     PlParam     "DropMac"    "00:0C:29:28:0E:CC" # SimpleClient2
462   }
463
464
465
466 10. Common problems, FAQ
467 ------------------------
468
469 ---------
470 Question:
471 On which platforms does BMF currently compile?
472
473 Answer:
474 Only on Linux. No compilation on Windows (yet). The oldest Linux
475 kernel on which the BMF plugin was tested was version 2.4.18.
476
477
478 ---------
479 Question:
480 When starting OLSRD with the BMF plugin, I can see the following
481 error message:
482
483 OLSRD Basic Multicast Forwarding (BMF) plugin: error opening /dev/net/tun: No such file or directory
484
485 Wat to do?
486
487 Answer:
488 Turn on the possibility to create a tuntap interface; see section 2 of this
489 file.
490
491 ---------
492 Question:
493 When starting OLSRD with the BMF plugin, I can see the following
494 error message:
495
496 OLSRD Basic Multicast Forwarding (BMF) plugin: error opening /dev/net/tun: No such device
497
498 Wat to do?
499
500 Answer:
501 First, turn on the possibility to create a tuntap interface; see section 2 of this
502 file. Check if the device is there:
503  
504   ~ # ls -l /dev/net/tun
505   crw-------    1 root     root      10, 200 Sep  9  2006 /dev/net/tun
506
507 If the device is there, but the error message remains to appear, the
508 tap/tun device is not compiled in your kernel. Try the command:
509
510   modprobe tun
511
512 If "modprobe tun" says something like "module tun not found", then either
513 it is not compiled at all or it is not compiled into the kernel. 
514
515
516 ---------
517 Question:
518 I have enabled BMF, but my multicast application is not receiving any
519 multicast packets.
520
521 Answer:
522 Many multicast applications must be configured to listen to a specific
523 network interface. Make sure that your multicast application is listening on
524 the BMF network interface, either by specifying the interface name itself
525 (e.g. "bmf0") or by specifying its IP address.
526
527
528 11. Version history
529 -------------------
530
531 18 Dec 2006: Version 1.3
532 * Added the possibility to configure the BMF network interface:
533   name (e.g. "bmf0"), type (tun or tap), IP address and subnet
534   mask.
535 * Flooding of local broadcast packets (e.g. with destination
536   IP address 192.168.1.255) can now be turned off by configuration.
537 * When an application sends packets to the BMF network interface, BMF
538   also floods these packets over the OLSR network.
539 * Removed the TTL decrementing so that equipment connected to
540   a non-OLSR interface can still send their IGMP messages (TTL = 1)
541   to a fixed multicast router (running e.g. mrouted - DVMRP)
542   connected to a non-OLSR interface on another host in
543   the OLSR network. In this way, a whole OLSR network, including
544   its non-OLSR capable hosts, can be made multicast-routable
545   from a fixed multicast-enabled IP network.
546   For an example of such a configuration read section 8 above.
547 * Removed the check for 'IsNullMacAddress' when creating a network
548   interface object. The check was not necessary and prevented
549   BMF to work on non-ethernet interfaces such as ppp.
550 * Bug fix: in case there are multiple OLSR interfaces, when an
551   application sends packets to one OLSR interface, BMF did not
552   flood these packets via the other OLSR interfaces. This is
553   fixed. Also, packets sent to an OLSR interface are transmitted
554   on the non-OLSR interfaces.
555
556 23 Oct 2006: Version 1.2
557 * Packets to a local broadcast destination have their destination
558   IP address adapted to the subnet on which they are forwarded.
559   This makes it possible to use broadcast-based services (such as
560   NetBIOS) across different IP subnets.
561 * The code to relate fragments with their main IP packet did not
562   work when the fragment arrived earlier than the main packet.
563   This would cause fragments of BMF-packets to be falsely forwarded.
564   For now, removed the forwarding of IP fragments. (Who's using
565   IP-fragments anyway?)
566 * Packets are forwarded from one non-OLSR interface to the other
567   non-OLSR interfaces.
568 * Various small optimizations and style improvements.
569
570 12 Jul 2006: Version 1.1
571 * Major updates in code forwarding from and to non-OLSR enabled
572   network interfaces.
573 * Debug level 9 gives a better indication of what happens to each
574   handled multicast/broadcast packet. To run the olsr daemon with
575   debug level 9, run "olsrd -d 9".
576 * Can now deal with network interface removal ("ifdown eth1") and
577   addition ("ifup eth1").
578 * CRC-calculation for duplicate detection is done over first 256
579   bytes in packet instead of over full packet length.
580 * CRC calculated only on captured packets, and is subsequently
581   passed on in a special OLSR-BMF encapsulation header.
582 * Deals correctly with fragmented packets
583
584 27 Apr 2006: Version 1.0.1
585 * First release.
586