also try configuring ad-hoc after interface is up, if not already in ad-hoc mode...
[olsrd.git] / lib / bmf / README_BMF
1 BASIC MULTICAST FORWARDING PLUGIN FOR OLSRD
2 by Erik Tromp (eriktromp@users.sourceforge.net, erik_tromp@hotmail.com)
3 Version 1.7.0
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.7.0.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.7.0.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.7.0"
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   ---------- LOADING LIBRARY olsrd_bmf.so.1.7.0 ----------
67   OLSRD Basic Multicast Forwarding (BMF) plugin 1.7.0 (Mar 22 2010 21:44:23)
68     (C) Thales Communications Huizen, Netherlands
69     Erik Tromp (eriktromp@users.sourceforge.net)
70   Checking plugin interface version:  5 - OK
71   Trying to fetch plugin init function: OK
72   Trying to fetch parameter table and it's size...
73   Sending parameters...
74   "NonOlsrIf"/"eth4"... NonOlsrIf: OK
75   Running plugin_init function...
76   OLSRD Basic Multicast Forwarding (BMF) plugin: opened 5 sockets
77   ---------- LIBRARY olsrd_bmf.so.1.7.0 LOADED ----------
78
79
80 4. How to check if it works
81 ---------------------------
82
83 Enter the following command on the command prompt:
84   
85   ping 224.0.0.1
86
87 All OLSR-BMF hosts in the OLSR network should respond. For example,
88 assume we have three hosts, with IP addresses 192.168.151.50,
89 192.168.151.53 and 192.168.151.55. On host 192.168.151.50 we enter
90 the following ping command:
91
92 root@IsdbServer:~# ping 224.0.0.1
93 PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data.
94 64 bytes from 192.168.151.50: icmp_seq=1 ttl=64 time=0.511 ms
95 64 bytes from 192.168.151.53: icmp_seq=1 ttl=64 time=4.67 ms (DUP!)
96 64 bytes from 192.168.151.55: icmp_seq=1 ttl=63 time=10.7 ms (DUP!)
97 64 bytes from 192.168.151.50: icmp_seq=2 ttl=64 time=0.076 ms
98 64 bytes from 192.168.151.53: icmp_seq=2 ttl=64 time=1.23 ms (DUP!)
99 64 bytes from 192.168.151.55: icmp_seq=2 ttl=63 time=1.23 ms (DUP!)
100 64 bytes from 192.168.151.50: icmp_seq=3 ttl=64 time=0.059 ms
101 64 bytes from 192.168.151.53: icmp_seq=3 ttl=64 time=2.94 ms (DUP!)
102 64 bytes from 192.168.151.55: icmp_seq=3 ttl=63 time=5.62 ms (DUP!)
103 64 bytes from 192.168.151.50: icmp_seq=4 ttl=64 time=0.158 ms
104 64 bytes from 192.168.151.53: icmp_seq=4 ttl=64 time=1.14 ms (DUP!)
105 64 bytes from 192.168.151.55: icmp_seq=4 ttl=63 time=1.16 ms (DUP!)
106
107 We can see the response from the originating host (192.168.151.50)
108 (it is normal behaviour for hosts sending multicast packets to
109 receive their own packets). We can also see the responses by the
110 other hosts (correctly seen as DUPlicates by ping).
111
112 Note: when using an older version of ping than the standard from
113 iputils-20020927, as found in most current Linux distributions, you may want
114 to test BMF by specifying the output interface to the ping command:
115
116   ping -I bmf0 224.0.0.1
117
118 Older versions of 'ping' (e.g. as found in iputils-20020124) may bind to the
119 autoselected source address, which may be incorrect. Since BMF re-uses
120 one of the existing IP addresses for the "bmf0" network interface, the
121 older-version ping command may 'autobind' to the wrong interface.
122
123 See also the note in the iputils-20020927/RELNOTES file:
124 "* Mads Martin Jørgensen <mmj@suse.de>: ping should not bind to autoselected
125   source address, it used to work when routing changes. Return classic
126   behaviour, option -B is added to enforce binding."
127
128
129 5. How does it work
130 -------------------
131
132 In the IP header there is room for only two IP-addresses:
133 * the destination IP address (in our case either a multicast
134   IP-address 224.0.0.0...239.255.255.255, or a local broadcast
135   address e.g. 192.168.1.255), and
136 * the source IP address (the originator).
137
138 For optimized flooding, however, we need more information. Let's
139 assume we are the BMF process on one host. We will need to know which
140 host forwarded the IP packet to us. Since OLSR keeps track of which
141 hosts select our host as MPR (see the olsr_lookup_mprs_set(...) function),
142 we can determine if the host that forwarded the packet, has selected us as
143 MPR. If so, we must also forward the packet, changing the 'forwarded-by'
144 IP-address to that of us. If not, we do not forward the packet.
145
146 Because we need more information than fits in a normal IP-header, the
147 original packets are encapsulated into a new IP packet. Encapsulated
148 packets are transported in UDP, port 50698. The source address of the
149 encapsulation packet is set to the address of the forwarder instead of
150 the originator. Of course, the payload of the encapsulation packet is
151 the original IP packet. For an exact specification of the encapsulation
152 format, refer to paragraph 10 below.
153
154 For local reception, each received encapsulated packets is unpacked
155 and passed into a tuntap interface which is specially created for
156 this purpose.
157
158 There are other flooding solutions available that do not use
159 encapsulation. The problem with these solutions is that they cannot
160 prevent duplicates of forwarded packets to enter the IP stack. For
161 example, if a host is receiving flooded (unencapsulated, native IP)
162 packets via two MPR hosts, there is no way to stop the reception of
163 the packets coming in via the second MPR host. To prevent this, BMF
164 uses a combination of encapsulated flooding and local reception via
165 a tuntap interface.
166
167 Here is in short how the flooding works (see also the
168 BmfEncapsulatedPacketReceived(...) function; details with respect to
169 the forwarding towards non-OLSR enabled hosts are omitted):
170   
171   On all OLSR-enabled interfaces, setup reception of packets
172     on UDP port 50698.
173   Upon reception of such a packet:
174     If the received packet was sent by myself, drop it.
175     If the packet was recently seen, drop it.
176     Unpack the encapsulated packet and send a copy to myself via the
177       TunTap interface.
178     If I am an MPR for the host that forwarded the packet to me,
179       forward the packet to all OLSR-enabled interfaces *including*
180       the interface on which it was received.
181
182
183 6. Advanced configuration
184 -------------------------
185
186 All configuration of BMF is done via the "LoadPlugin" section in
187 the /etc/olsrd.conf file.
188
189 The following gives an overview of all plugin parameters that can be
190 configured. Unless otherwise stated, settings may differ for each node in the
191 network.
192
193   LoadPlugin "olsrd_bmf.so.1.7.0"
194   {
195     # Specify the name of the BMF network interface.
196     # Defaults to "bmf0".
197     PlParam "BmfInterface" "bmf0"
198
199     # Specify the IP address and mask for the BMF network interface.
200     # By default, the IP address of the first OLSR interface is copied.
201     # The default prefix length is 32.
202     PlParam "BmfInterfaceIp" "10.10.10.234/24"
203
204     # Enable or disable the flooding of local broadcast packets
205     # (e.g. packets with IP destination 192.168.1.255). Either "yes"
206     # or "no". Defaults to "yes".
207     # Note: all nodes in the same network should have the same setting for
208     # this plugin parameter.
209     PlParam "DoLocalBroadcast" "yes"
210
211     # Enable or disable the capturing packets on the OLSR-enabled
212     # interfaces (in promiscuous mode). Either "yes" or "no". Defaults
213     # to "no".
214     # The multicast (and, if configured, local broadcast) packets sent on
215     # the non-OLSR network interfaces and on the BMF network interface will
216     # always be flooded over the OLSR network.
217     # If this parameter is "yes", also the packets sent on the OLSR-enabled
218     # network interfaces will be flooded over the OLSR network.
219     # NOTE: This parameter should be set consistently on all hosts throughout
220     # the network. If not, hosts may receive multicast packets in duplicate.
221     PlParam "CapturePacketsOnOlsrInterfaces" "no"
222
223     # The forwarding mechanism to use. Either "Broadcast" or
224     # "UnicastPromiscuous". Defaults to "Broadcast".
225     # In the "UnicastPromiscuous" mode, packets are forwarded (unicast) to the
226     # best candidate neighbor; other neighbors listen promiscuously. IP-local
227     # broadcast is not used. This saves air time on 802.11 WLAN networks,
228     # on which unicast packets are usually sent at a much higher bit rate
229     # than broadcast packets (which are sent at a basic bit rate).
230     # Note: all nodes in the same network should have the same setting for
231     # this plugin parameter.
232     PlParam "BmfMechanism" "Broadcast"
233
234     # The number of times BMF will transmit the same packet whenever it decides
235     # to use broadcast to forward a packet. Defaults to 1. Not used if
236     # "BmfMechanism" is set to "UnicastPromiscuous".
237     PlParam "BroadcastRetransmitCount" "1"
238
239     # If the number of neighbors to forward to is less than or equal to the
240     # FanOutLimit, then packets to be relayed will be sent via unicast.
241     # If the number is greater than the FanOutLimit the packet goes out
242     # as broadcast. Legal values are 0...10. See MAX_UNICAST_NEIGHBORS
243     # as defined in NetworkInterfaces.h . 0 means broadcast is always used,
244     # even if there is only 1 neighbor to forward to. Defaults to 2. 
245     # This plugin parameter is not used if "BmfMechanism" is set to
246     # "UnicastPromiscuous".
247     PlParam "FanOutLimit" "2"
248
249     # List of non-OLSR interfaces to include
250     PlParam     "NonOlsrIf"  "eth2"
251     PlParam     "NonOlsrIf"  "eth3"
252   }
253
254 BmfInterfaceIp
255 --------------
256
257 By default, the BMF network interface will get the IP address of the
258 first OLSR interface, with a prefix length of 32. Having two network
259 interfaces with the same IP address may seem strange, but it is not
260 a problem, since the BMF network interface is not used in any point-to-
261 point routing.
262
263 The advantage of assigning a known OLSR IP address to the BMF network
264 interface is that multicast packets, sent via the BMF network interface,
265 get a known IP source address, to which the receivers of the packets
266 can reply. That is useful when using, for example, the command
267 "ping 224.0.0.1".
268
269 An advantage of using a prefix length of 32 is that the Linux IP
270 stack will not automatically enter a subnet routing entry (via the BMF
271 network interface) into the kernel routing table. Such a routing entry
272 would be useless, because the BMF network interface does not forward
273 point-to-point traffic.
274
275 If you configure a specific IP address and mask via the "BmfInterfaceIp"
276 parameter, BMF will cause the specified IP host address to be advertised
277 into the OLSR network via the HNA mechanism, so that the other hosts in
278 the network know how to route back.
279
280 CapturePacketsOnOlsrInterfaces
281 ------------------------------
282
283 If "CapturePacketsOnOlsrInterfaces" is set to "yes", any multicast
284 or local broadcast IP packet, sent by an application on *any* OLSR
285 interface, will be flooded over the OLSR network. Each OLSR host
286 will receive the packet on its BMF network interface, "bmf0". The
287 OLSR-interfaces will be in promiscuous mode to capture the multicast
288 or local broadcast packets.
289
290 For example, if "eth1" is an OLSR interface, the following command
291 will result in one response from each OLSR host in the network:
292
293   ping -I eth1 224.0.0.1
294
295 A disadvantage of this configuration is that a host may, in rare
296 cases, receive a multicast packet twice. This is best explained
297 by looking at the following network diagram:
298
299         eth0   eth0
300       A ----------- B
301  eth1 |            / eth1
302       |           /
303  eth0 |          /
304       C --------+
305         eth1
306
307 Suppose host A is running a ping session that is sending ping
308 packets on "eth1". The BMF process on host A will see the outgoing
309 packets on "eth1", encapsulates these packets and sends the
310 encapsulated packets on "eth0". Let's assume we are using the link
311 quality extensions of OLSR, and the 2-hop path A - B - C is better
312 (in terms of ETX) than the 1-hop path A - C. In that case host B is
313 an MPR for host A. Host B receives the encapsulated packets of host A
314 on its "eth0" interface, and, since it is an MPR, it decides to
315 forward them on "eth1".
316
317 In most cases, host C will receive the original, unencapsulated
318 ping packet on its "eth0" interface before the encapsulated
319 ping packet from host B arrives on its "eth1" interface. When the
320 encapsulated packet from B arrives, the BMF process will then see
321 that it is a duplicate and discard it.
322
323 However, in the IP world, there are no guarantees, so it may
324 happen that host C receives the encapsulated packet from host B
325 first. That packet is then unpacked and locally delivered to the
326 BMF network interface "bmf0". When the original, unencapsulated
327 packet then comes in on "eth0", there is no way to stop it from
328 being received (for a second time) by the Linux IP stack.
329
330 As said, this may be a rare case. Besides, most applications
331 can deal with a duplicate reception of the same packet. But if
332 you're a purist and want everything to work correct, you should
333 leave "CapturePacketsOnOlsrInterfaces" to its default value "no".
334
335 A disadvantage of leaving "CapturePacketsOnOlsrInterfaces" to its
336 default value "no" is that all multicast traffic must go via the
337 BMF network interface "bmf0". However, this should not be a problem,
338 since a route to all multicast addresses via the BMF network
339 interface "bmf0" is automatically added when BMF is started.
340
341
342 7. Adding non-OLSR interfaces to the multicast flooding
343 -------------------------------------------------------
344
345 As a special feature, it is possible to also forward from and to
346 non-OLSR interfaces.
347
348 If you have network interfaces on which OLSR is *not* running, but you *do*
349 want to forward multicast and local-broadcast IP packets, specify these
350 interfaces one by one as "NonOlsrIf" parameters in the BMF plugin section
351 of /etc/olsrd.conf. For example:
352
353   LoadPlugin "olsrd_bmf.so.1.7.0"
354   {
355     # Non-OLSR interfaces to participate in the multicast flooding
356     PlParam     "NonOlsrIf"  "eth2"
357     PlParam     "NonOlsrIf"  "eth3"
358   }
359
360 If an interface is listed both as "NonOlsrIf" for BMF, and in the
361 Interfaces { ... } section of olsrd.conf, it will be seen by BMF
362 as an OLSR-enabled interface.
363
364
365 8. Interworking with other multicast routers
366 --------------------------------------------
367
368 In a typical interworking configuration there is a network of OLSR hosts
369 in which one host acts as a gateway to a fixed infrastructure network.
370 Usually that host will be advertising a default route via the HNA
371 mechanism, e.g. by adding the following lines to its /etc/olsrd.conf
372 file:
373
374   Hna4
375   {
376   #   Internet gateway:
377       0.0.0.0      0.0.0.0
378   }
379
380 Alternatively, the gateway is running OLSRDs dynamic internet gateway
381 plugin; read the file ../../lib/dyn_gw/README_DYN_GW .
382
383 The gateway host will usually have at least one OLSR-interface, and
384 at least one non-OLSR interface, running a third-party routing protocol
385 like OSPF.
386
387 It is beyond the scope of this document to deal with the interworking
388 between BMF and all possible multicast routing daemons. As an example,
389 let's assume the gateway is running the mrouted multicast daemon (which
390 implements the DVMRP protocol). Also, assume that all the IP addresses
391 in the OLSR network are within the IP subnet 10.0.0.0/8 . Then mrouted
392 on the gateway needs to be configured to accept IGMP requests from IP
393 clients within the 10.0.0.0/8 subnet on the BMF network interface
394 ("bmf0"). This is easily configured by adding a line to the
395 /etc/mrouted.conf configuration file:
396
397   phyint bmf0 altnet 10.0.0.0/8
398
399 Not strictly necessary, but clean, is to disable the DVMRP protocol
400 on the OLSR interfaces, as no DVMRP routers are expected inside the
401 OLSR network. Suppose the gateway is running OLSR on "eth1", then
402 add the following line /etc/mrouted.conf :
403
404   phyint eth1 disable
405
406 Finally, mrouted does not accept interfaces with prefix length 32.
407 Therefore, override the default IP address and prefix length of
408 the BMF network interface, by editing the /etc/olsrd.conf file.
409 For example:
410
411   LoadPlugin "olsrd_bmf.so.1.7.0"
412   {
413       PlParam "BmfInterfaceIp" "10.10.10.4/24"
414   }
415
416 Note that it is not necessary, and even incorrect, to pass the
417 non-OLSR interface to BMF as a "NonOlsrIf" parameter in the
418 "LoadPlugin" section of the gateway host. When the mrouted
419 multicast daemon is running, the forwarding of multicast traffic
420 between the OLSR interface and the non-OLSR interface is done by
421 the Linux kernel.
422
423 The remaining text in this section has nothing to do with BMF or
424 OLSR, but is added to give a number of helpful hints you might
425 need when your multicast interworking, for some reason, is not working.
426
427 When using the mrouted multicast daemon, there is a useful command,
428 mrinfo, that gives information about what mrouted thinks of its
429 neighbor hosts. For example:
430
431   root@node-4:/# mrinfo
432   127.0.0.1 (localhost.localdomain) [DVMRPv3 compliant]:
433     10.1.2.4 -> 10.1.2.2 (10.1.2.2) [1/1/querier]
434     10.0.6.4 -> 0.0.0.0 (local) [1/1/disabled]
435     10.255.255.253 -> 0.0.0.0 (local) [1/1/querier/leaf]
436
437 In this example, the line starting with "10.1.2.4" is for the
438 non-OLSR interface "eth0", on which mrouted has found an
439 mrouted-neighbor host "10.1.2.2". The next line is for the OLSR
440 interface "eth1", which is disabled for mrouted. The last line
441 is for the BMF interface "bmf0". It is clear that mrouted sees no
442 mrouted-neighbors on that interface (leaf).
443
444 To see what multicast traffic has flown through the gateway, view
445 the files /proc/net/ip_mr_vif and /proc/net/ip_mr_cache:
446
447   root@node-4:/# cat /proc/net/ip_mr_vif
448   Interface      BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote
449    0 eth0          27832      98     14200      50 00000 0402010A 00000000
450    2 bmf0          14484      51     13916      49 00000 FDFFFF0A 00000000
451   root@node-4:/# cat /proc/net/ip_mr_cache
452   Group    Origin   Iif     Pkts    Bytes    Wrong Oifs
453   4D4237EA C747010A 0         51    14484        0  2:1
454   4D4237EA C702010A 0         51    14484        0  2:1
455   4D4237EA C84C000A 2         53    15052        0  0:1
456
457 From the above we can deduce that traffic from input interface 0
458 (Iif 0, "eth0") is forwarded on output interface 2 (Oifs 2, = "bmf0"),
459 and traffic from input interface 2 (Iif 2, "bmf0") is forwarded on
460 output interface 0 (Oifs 0, "eth0"). The ":1" behind the Oifs numbers
461 indicates the TTL thresholds, in this case packets with TTL value 1
462 or less will not be forwarded.
463
464 Note that when you are connecting an OLSR-BMF network to another multicast
465 network (e.g. a DVMRP-mrouted network), you might be surprised that, when
466 you ping the all-routers multicast address 224.0.0.1 from within the OLSR
467 network, only the OLSR hosts respond. This is, however, compliant behaviour:
468 packets with their destination IP address in the range 224.0.0.0 -
469 224.0.0.255 are not routed by normal multicast protocols (i.e. their
470 TTL is implicitly assumed to be 1). It doesn't mean that multicast is
471 not working; if your application uses a multicast address outisde the
472 range 224.0.0.0 - 224.0.0.255, it should work.
473
474
475 9. Common problems, FAQ
476 ------------------------
477
478 ---------
479 Question:
480 On which platforms does BMF currently compile?
481
482 Answer:
483 Only on Linux. No compilation on Windows (yet). The oldest Linux
484 kernel on which the BMF plugin was tested was version 2.4.18.
485
486
487 ---------
488 Question:
489 When starting OLSRD with the BMF plugin, I can see the following
490 error message:
491
492 OLSRD Basic Multicast Forwarding (BMF) plugin: error opening /dev/net/tun: No such file or directory
493
494 Wat to do?
495
496 Answer:
497 Turn on the possibility to create a tuntap interface; see section 2 of this
498 file.
499
500
501 ---------
502 Question:
503 When starting OLSRD with the BMF plugin, I can see the following
504 error message:
505
506 OLSRD Basic Multicast Forwarding (BMF) plugin: error opening /dev/net/tun: No such device
507
508 Wat to do?
509
510 Answer:
511 First, turn on the possibility to create a tuntap interface; see section 2 of this
512 file. Check if the device is there:
513  
514   ~ # ls -l /dev/net/tun
515   crw-------    1 root     root      10, 200 Sep  9  2006 /dev/net/tun
516
517 If the device is there, but the error message remains to appear, the
518 tap/tun device is not compiled in your kernel. Try the command:
519
520   modprobe tun
521
522 If "modprobe tun" says something like "modprobe: Can't locate module tun", then either
523 it is not compiled at all or it is not compiled into the kernel. 
524
525 Note: if you do not want to receive multicast packets, only forward the packets
526 that other hosts send, then you do not need the tuntap interface. This could be the
527 case if your host is purely an OLSR router; normally no traffic will be directed
528 to the router itself. In that case you can ignore this error message. Beware, though,
529 that you will then not be able to do the simple 'ping 224.0.0.1' test (as described in
530 section 4. How to check if it works) to check for the presence of all OLSR-BMF routers
531 in the network. 
532
533
534 ---------
535 Question:
536 I have enabled BMF, but my multicast application is not receiving any
537 multicast packets.
538
539 Answer:
540 Many multicast applications must be configured to listen to a specific
541 network interface. Make sure that your multicast application is listening on
542 the BMF network interface, either by specifying the interface name itself
543 (e.g. "bmf0") or by specifying its IP address.
544
545
546 10. Version history
547 -------------------
548
549 21 March 2010: Version 1.7.0
550
551 * Ported 1.6.2 back into OLSRd for 0.5.7.0 release: the BMF functions are
552   registered with OLSR so that a separate thread for BMF to run in is no longer
553   necessary. This also removes the need for a mutex to guarantee safe access to
554   OLSR data. Done by Henning Rogge <hrogge@googlemail.com>.
555 * Code Cleanup: duplicate code moved to separate functions
556   'ForwardPacket (...)' and 'EncapsulateAndForwardPacket (...)'
557 * Prevent the calling of 'sendto' when that would lead to blocking the
558   thread --> thanks to Daniele Lacamera for finding and solving this issue.
559 * Changed the legal range of the 'FanOutLimit' plugin parameter from 1...10
560   to 0...10 .
561
562 23 November 2008: Version 1.6.2
563
564 * Fixed a bug that prevented the route for multicast traffic to be updated
565   when a network interface was added at runtime --> thanks to Daniele Lacamera
566   for finding and solving this bug.
567
568 22 July 2008: Version 1.6.1
569
570 * Introduced a mutex for safe access to the OLSR data by the BMF thread.
571
572 4 July 2008: Version 1.6
573
574 * Fixed a bug in the CreateInterface() function: missing initialization
575   of newIf->next to NULL.
576
577 24 February 2008: Version 1.5.3
578
579 * Fixed a bug so that dying or dead end edges are not taken into account.
580   As of OLSRd version 0.5.4 , stale TC entries are not cleaned up, but
581   marked with a flag OLSR_TC_EDGE_DOWN. This flag was not taken into account
582   by BMF.
583
584 7 December 2007: Version 1.5.2
585
586 * Fixed a bug that would cause BMF to always send encapsulated broadcast
587   packets twice --> thanks to Frank Renwick and Joseph Giovatto for finding
588   this bug :-)
589 * Added the plugin parameters "BroadcastRetransmitCount" and "FanOutLimit";
590   thanks to Frank and Joe for the idea.
591
592 3 September 2007: Version 1.5.1
593
594 * Fixed a bug that would cause BMF to crash (and OLSR with it) if a link
595   was timing out --> thanks to Frank Renwick
596 * Fixed bug in the checking of the packet length --> thanks to Frank Renwick
597 * Fixed a bug in shutdown, which cause a crash if the BMF thread was not
598   yet running --> thanks to Bernd Petrovitsch
599 * Updated to OLSR plugin interface version 5.
600
601 16 May 2007: Version 1.5
602
603 * Improved packet history list to take into account the full 32 bits
604   of the packet fingerprint.
605   Previous versions derived a 16-bits value from the 32-bits packet
606   fingerprint and used that 16-bits value to determine packet unicity. In
607   situations with high packet rates (e.g. multicast video), this leads to
608   packets being incorrectly seen as duplicates of other, previously received
609   packets.
610
611 * New encapsulation format. In previous versions, a complete Ethernet
612   frame was encapsulated. This is unnecessary, and not very clean; e.g.
613   from packets coming in on non-Ethernet media such as PPP, the data in
614   the Ethernet header is bogus.
615   The new encapsulation format encapsulates only the IP packet. An
616   outer IP header [1], UDP header [2] and BMF Encapsulation Header are
617   inserted before the datagram's existing IP header, as follows:
618
619                                        +---------------------------+
620                                        |                           |
621                                        |      Outer IP Header      |
622                                        +---------------------------+
623                                        |                           |
624                                        |        UDP Header         |
625                                        +---------------------------+
626                                        |      BMF Encapsulation    |
627                                        |           Header          |
628    +---------------------------+       +---------------------------+
629    |                           |       |                           |
630    |         IP Header         |       |         IP Header         |
631    +---------------------------+ ====> +---------------------------+
632    |                           |       |                           |
633    |         IP Payload        |       |         IP Payload        |
634    |                           |       |                           |
635    |                           |       |                           |
636    +---------------------------+       +---------------------------+
637
638   The BMF encapsulation header has a typical type-length-value (TLV)
639   format:
640
641     0                   1                   2                   3
642     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
643    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
644    |     Type      |    Length     |            Reserved           |
645    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
646    |                       Packet fingerprint                      |
647    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
648
649    Type                1
650
651    Length              6.  Length in bytes of this extension, not
652                        including the Type and Length bytes.
653
654    Reserved            Reserved for future use. MUST be set to 0 on
655                        sending, MUST be verified as 0 on receipt;
656                        otherwise the extension must be handled as not
657                        understood and silently skipped.
658
659    Packet fingerprint  32-bits unique fingerprint inserted by the
660                        encapsulator. MAY be used by the receiver to
661                        determine duplicate packet reception.
662
663   The new encapsulation format is incompatible with those of previous
664   BMF versions, implying that all network nodes need to be updated.
665
666
667 31 Mar 2007: Version 1.4
668 * Optimized the standard forwarding mechanism in such a way that
669   retransmissions of packets are only done on those network interfaces
670   that make a host a multi-point relay (MPR) for the sender. I.e.:
671   retransmitting a packet on a network interface is not done if that
672   does not lead to any new hosts being reached.
673 * Optimized the standard forwarding mechanism such that, if the network
674   topology indicates there is only one neighbor on an interface, packets are
675   sent to the specific IP address (unicast) of that neighbor. If the network
676   topology indicates there are multiple neighbors, then BMF will still send
677   packets to the IP local-broadcast address.
678 * Introduced a new forwarding mechanism, using only IP-unicast to
679   forward packets. Packets are forwarded to the best candidate neighbor;
680   other neighbors listen promiscuously. IP-local broadcast is not used.
681   This saves air time on 802.11 WLAN networks, on which unicast packets are
682   usually sent at a much higher bit rate than broadcast packets (which are
683   sent at a basic bit rate).
684   This mechanism can be activated by specifying the following plugin
685   parameter:
686     PlParam "BmfMechanism" "UnicastPromiscuous"
687   See also section 6 - Advanced configuration.
688
689 18 Dec 2006: Version 1.3
690 * Added the possibility to configure the BMF network interface:
691   name (e.g. "bmf0"), type (tun or tap), IP address and subnet
692   mask.
693 * Flooding of local broadcast packets (e.g. with destination
694   IP address 192.168.1.255) can now be turned off by configuration.
695 * When an application sends packets to the BMF network interface, BMF
696   also floods these packets over the OLSR network.
697 * Removed the TTL decrementing so that equipment connected to
698   a non-OLSR interface can still send their IGMP messages (TTL = 1)
699   to a fixed multicast router (running e.g. mrouted - DVMRP)
700   connected to a non-OLSR interface on another host in
701   the OLSR network. In this way, a whole OLSR network, including
702   its non-OLSR capable hosts, can be made multicast-routable
703   from a fixed multicast-enabled IP network.
704   For an example of such a configuration read section 8 above.
705 * Removed the check for 'IsNullMacAddress' when creating a network
706   interface object. The check was not necessary and prevented
707   BMF to work on non-ethernet interfaces such as ppp.
708 * Bug fix: in case there are multiple OLSR interfaces, when an
709   application sends packets to one OLSR interface, BMF did not
710   flood these packets via the other OLSR interfaces. This is
711   fixed. Also, packets sent to an OLSR interface are transmitted
712   on the non-OLSR interfaces.
713
714 23 Oct 2006: Version 1.2
715 * Packets to a local broadcast destination have their destination
716   IP address adapted to the subnet on which they are forwarded.
717   This makes it possible to use broadcast-based services (such as
718   NetBIOS) across different IP subnets.
719 * The code to relate fragments with their main IP packet did not
720   work when the fragment arrived earlier than the main packet.
721   This would cause fragments of BMF-packets to be falsely forwarded.
722   For now, removed the forwarding of IP fragments. (Who's using
723   IP-fragments anyway?)
724 * Packets are forwarded from one non-OLSR interface to the other
725   non-OLSR interfaces.
726 * Various small optimizations and style improvements.
727
728 12 Jul 2006: Version 1.1
729 * Major updates in code forwarding from and to non-OLSR enabled
730   network interfaces.
731 * Debug level 9 gives a better indication of what happens to each
732   handled multicast/broadcast packet. To run the olsr daemon with
733   debug level 9, run "olsrd -d 9"; if you're only interested in
734   BMF debug messages, run "olsrd -d 9 | grep -i bmf".
735 * Can now deal with network interface removal ("ifdown eth1") and
736   addition ("ifup eth1").
737 * CRC-calculation for duplicate detection is done over first 256
738   bytes in packet instead of over full packet length.
739 * CRC calculated only on captured packets, and is subsequently
740   passed on in a special OLSR-BMF encapsulation header.
741 * Deals correctly with fragmented packets
742
743 27 Apr 2006: Version 1.0.1
744 * First release.
745
746
747 11. Normative References
748 ------------------------
749
750    [1]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
751
752    [2]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
753         1980.
754