1 BASIC MULTICAST FORWARDING PLUGIN FOR OLSRD
2 by Erik Tromp (erik.tromp@nl.thalesgroup.com, erik_tromp@hotmail.com)
3 Version 1.4
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.4.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.4.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.4"
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.4
68 OLSRD Basic Multicast Forwarding plugin 1.4 (Mar 30 2007 14:30:57)
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) 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 Note: when using an older version of ping than the standard from
114 iputils-20020927, as found in most current Linux distributions, you may want
115 to test BMF by specifying the output interface to the ping command:
116
117 ping -I bmf0 224.0.0.1
118
119 Older versions of 'ping' (e.g. as found in iputils-20020124) may bind to the
120 autoselected source address, which may be incorrect. Since BMF re-uses
121 one of the existing IP addresses for the "bmf0" network interface, the
122 older-version ping command may 'autobind' to the wrong interface.
123
124 See also the note in the iputils-20020927/RELNOTES file:
125 "* Mads Martin Jørgensen <mmj@suse.de>: ping should not bind to autoselected
126 source address, it used to work when routing changes. Return classic
127 behaviour, option -B is added to enforce binding."
128
129
130 5. How does it work
131 -------------------
132
133 In the IP header there is room for only two IP-addresses:
134 * the destination IP address (in our case either a multicast
135 IP-address 224.0.0.0...239.255.255.255, or a local broadcast
136 address e.g. 192.168.1.255), and
137 * the source IP address (the originator).
138
139 For optimized flooding, however, we need more information. Let's
140 assume we are the BMF process on one host. We will need to know which
141 host forwarded the IP packet to us. Since OLSR keeps track of which
142 hosts select our host as MPR (see the olsr_lookup_mprs_set(...) function),
143 we can determine if the host that forwarded the packet, has selected us as
144 MPR. If so, we must also forward the packet, changing the 'forwarded-by'
145 IP-address to that of us. If not, we do not forward the packet.
146
147 Because we need more information than fits in a normal IP-header, the
148 original packets are encapsulated into a new IP packet. Encapsulated
149 packets are transported in UDP, port 50698. The source address of the
150 encapsulation packet is set to the address of the forwarder instead of
151 the originator. Of course, the payload of the encapsulation packet is
152 the original IP packet.
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:
191
192 LoadPlugin "olsrd_bmf.so.1.4"
193 {
194 # Specify the name of the BMF network interface.
195 # Defaults to "bmf0".
196 PlParam "BmfInterface" "mybmf0"
197
198 # Specify the type of the BMF network interface: either "tun" or
199 # "tap". Defaults to "tun".
200 PlParam "BmfInterfaceType" "tap"
201
202 # Specify the IP address and mask for the BMF network interface.
203 # By default, the IP address of the first OLSR interface is copied.
204 # The default prefix length is 32.
205 PlParam "BmfInterfaceIp" "10.10.10.234/24"
206
207 # Enable or disable the flooding of local broadcast packets
208 # (e.g. packets with IP destination 192.168.1.255). Either "yes"
209 # or "no". Defaults to "yes".
210 PlParam "DoLocalBroadcast" "no"
211
212 # Enable or disable the capturing packets on the OLSR-enabled
213 # interfaces (in promiscuous mode). Either "yes" or "no". Defaults
214 # to "no".
215 # The multicast (and, if configured, local broadcast) packets sent on
216 # the non-OLSR network interfaces and on the BMF network interface will
217 # always be flooded over the OLSR network.
218 # If this parameter is "yes", also the packets sent on the OLSR-enabled
219 # network interfaces will be flooded over the OLSR network.
220 # NOTE: This parameter should be set consistently on all hosts throughout
221 # the network. If not, hosts may receive multicast packets in duplicate.
222 PlParam "CapturePacketsOnOlsrInterfaces" "yes"
223
224 # The forwarding mechanism to use. Either "Broadcast" or
225 # "UnicastPromiscuous". Defaults to "Broadcast".
226 # In the "UnicastPromiscuous" mode, packets are forwarded (unicast) to the
227 # best candidate neighbor; other neighbors listen promiscuously. IP-local
228 # broadcast is not used. This saves air time on 802.11 WLAN networks,
229 # on which unicast packets are usually sent at a much higher bit rate
230 # than broadcast packets (which are sent at a basic bit rate).
231 PlParam "BmfMechanism" "UnicastPromiscuous"
232
233 # List of non-OLSR interfaces to include
234 PlParam "NonOlsrIf" "eth2"
235 PlParam "NonOlsrIf" "eth3"
236 }
237
238 BmfInterfaceIp
239 --------------
240
241 By default, the BMF network interface will get the IP address of the
242 first OLSR interface, with a prefix length of 32. Having two network
243 interfaces with the same IP address may seem strange, but it is not
244 a problem, since the BMF network interface is not used in any point-to-
245 point routing.
246
247 The advantage of assigning a known OLSR IP address to the BMF network
248 interface is that multicast packets, sent via the BMF network interface,
249 get a known IP source address, to which the receivers of the packets
250 can reply. That is useful when using, for example, the command
251 "ping 224.0.0.1".
252
253 An advantage of using a prefix length of 32 is that the Linux IP
254 stack will not automatically enter a subnet routing entry (via the BMF
255 network interface) into the kernel routing table. Such a routing entry
256 would be useless, because the BMF network interface does not forward
257 point-to-point traffic.
258
259 If you configure a specific IP address and mask via the "BmfInterfaceIp"
260 parameter, BMF will cause the specified IP host address to be advertised
261 into the OLSR network via the HNA mechanism, so that the other hosts in
262 the network know how to route back.
263
264 CapturePacketsOnOlsrInterfaces
265 ------------------------------
266
267 If "CapturePacketsOnOlsrInterfaces" is set to "yes", any multicast
268 or local broadcast IP packet, sent by an application on *any* OLSR
269 interface, will be flooded over the OLSR network. Each OLSR host
270 will receive the packet on its BMF network interface, "bmf0". The
271 OLSR-interfaces will be in promiscuous mode to capture the multicast
272 or local broadcast packets.
273
274 For example, if "eth1" is an OLSR interface, the following command
275 will result in one response from each OLSR host in the network:
276
277 ping -I eth1 224.0.0.1
278
279 A disadvantage of this configuration is that a host may, in rare
280 cases, receive a multicast packet twice. This is best explained
281 by looking at the following network diagram:
282
283 eth0 eth0
284 A ----------- B
285 eth1 | / eth1
286 | /
287 eth0 | /
288 C --------+
289 eth1
290
291 Suppose host A is running a ping session that is sending ping
292 packets on "eth1". The BMF process on host A will see the outgoing
293 packets on "eth1", encapsulates these packets and sends the
294 encapsulated packets on "eth0". Let's assume we are using the link
295 quality extensions of OLSR, and the 2-hop path A - B - C is better
296 (in terms of ETX) than the 1-hop path A - C. In that case host B is
297 an MPR for host A. Host B receives the encapsulated packets of host A
298 on its "eth0" interface, and, since it is an MPR, it decides to
299 forward them on "eth1".
300
301 In most cases, host C will receive the original, unencapsulated
302 ping packet on its "eth0" interface before the encapsulated
303 ping packet from host B arrives on its "eth1" interface. When the
304 encapsulated packet from B arrives, the BMF process will then see
305 that it is a duplicate and discard it.
306
307 However, in the IP world, there are no guarantees, so it may
308 happen that host C receives the encapsulated packet from host B
309 first. That packet is then unpacked and locally delivered to the
310 BMF network interface "bmf0". When the original, unencapsulated
311 packet then comes in on "eth0", there is no way to stop it from
312 being received (for a second time) by the Linux IP stack.
313
314 As said, this may be a rare case. Besides, most applications
315 can deal with a duplicate reception of the same packet. But if
316 you're a purist and want everything to work correct, you should
317 leave "CapturePacketsOnOlsrInterfaces" to its default value "no".
318
319 A disadvantage of leaving "CapturePacketsOnOlsrInterfaces" to its
320 default value "no" is that all multicast traffic must go via the
321 BMF network interface "bmf0". However, this should not be a problem,
322 since a route to all multicast addresses via the BMF network
323 interface "bmf0" is automatically added when BMF is started.
324
325
326 7. Adding non-OLSR interfaces to the multicast flooding
327 -------------------------------------------------------
328
329 As a special feature, it is possible to also forward from and to
330 non-OLSR interfaces.
331
332 If you have network interfaces on which OLSR is *not* running, but you *do*
333 want to forward multicast and local-broadcast IP packets, specify these
334 interfaces one by one as "NonOlsrIf" parameters in the BMF plugin section
335 of /etc/olsrd.conf. For example:
336
337 LoadPlugin "olsrd_bmf.so.1.4"
338 {
339 # Non-OLSR interfaces to participate in the multicast flooding
340 PlParam "NonOlsrIf" "eth2"
341 PlParam "NonOlsrIf" "eth3"
342 }
343
344 If an interface is listed both as "NonOlsrIf" for BMF, and in the
345 Interfaces { ... } section of olsrd.conf, it will be seen by BMF
346 as an OLSR-enabled interface.
347
348
349 8. Interworking with other multicast routers
350 --------------------------------------------
351
352 In a typical interworking configuration there is a network of OLSR hosts
353 in which one host acts as a gateway to a fixed infrastructure network.
354 Usually that host will be advertising a default route via the HNA
355 mechanism, e.g. by adding the following lines to its /etc/olsrd.conf
356 file:
357
358 Hna4
359 {
360 # Internet gateway:
361 0.0.0.0 0.0.0.0
362 }
363
364 Alternatively, the gateway is running OLSRDs dynamic internet gateway
365 plugin; read the file ../../lib/dyn_gw/README_DYN_GW .
366
367 The gateway host will usually have at least one OLSR-interface, and
368 at least one non-OLSR interface, running a third-party routing protocol
369 like OSPF.
370
371 It is beyond the scope of this document to deal with the interworking
372 between BMF and all possible multicast routing daemons. As an example,
373 let's assume the gateway is running the mrouted multicast daemon (which
374 implements the DVMRP protocol). Also, assume that all the IP addresses
375 in the OLSR network are within the IP subnet 10.0.0.0/8 . Then mrouted
376 on the gateway needs to be configured to accept IGMP requests from IP
377 clients within the 10.0.0.0/8 subnet on the BMF network interface
378 ("bmf0"). This is easily configured by adding a line to the
379 /etc/mrouted.conf configuration file:
380
381 phyint bmf0 altnet 10.0.0.0/8
382
383 Not strictly necessary, but clean, is to disable the DVMRP protocol
384 on the OLSR interfaces, as no DVMRP routers are expected inside the
385 OLSR network. Suppose the gateway is running OLSR on "eth1", then
386 add the following line /etc/mrouted.conf :
387
388 phyint eth1 disable
389
390 Finally, mrouted does not accept interfaces with prefix length 32.
391 Therefore, override the default IP address and prefix length of
392 the BMF network interface, by editing the /etc/olsrd.conf file.
393 For example:
394
395 LoadPlugin "olsrd_bmf.so.1.4"
396 {
397 PlParam "BmfInterfaceIp" "10.10.10.4/24"
398 }
399
400 Note that it is not necessary, and even incorrect, to pass the
401 non-OLSR interface to BMF as a "NonOlsrIf" parameter in the
402 "LoadPlugin" section of the gateway host. When the mrouted
403 multicast daemon is running, the forwarding of multicast traffic
404 between the OLSR interface and the non-OLSR interface is done by
405 the Linux kernel.
406
407 The remaining text in this section has nothing to do with BMF or
408 OLSR, but is added to give a number of helpful hints you might
409 need when your multicast interworking, for some reason, is not working.
410
411 When using the mrouted multicast daemon, there is a useful command,
412 mrinfo, that gives information about what mrouted thinks of its
413 neighbor hosts. For example:
414
415 root@node-4:/# mrinfo
416 127.0.0.1 (localhost.localdomain) [DVMRPv3 compliant]:
417 10.1.2.4 -> 10.1.2.2 (10.1.2.2) [1/1/querier]
418 10.0.6.4 -> 0.0.0.0 (local) [1/1/disabled]
419 10.255.255.253 -> 0.0.0.0 (local) [1/1/querier/leaf]
420
421 In this example, the line starting with "10.1.2.4" is for the
422 non-OLSR interface "eth0", on which mrouted has found an
423 mrouted-neighbor host "10.1.2.2". The next line is for the OLSR
424 interface "eth1", which is disabled for mrouted. The last line
425 is for the BMF interface "bmf0". It is clear that mrouted sees no
426 mrouted-neighbors on that interface (leaf).
427
428 To see what multicast traffic has flown through the gateway, view
429 the files /proc/net/ip_mr_vif and /proc/net/ip_mr_cache:
430
431 root@node-4:/# cat /proc/net/ip_mr_vif
432 Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote
433 0 eth0 27832 98 14200 50 00000 0402010A 00000000
434 2 bmf0 14484 51 13916 49 00000 FDFFFF0A 00000000
435 root@node-4:/# cat /proc/net/ip_mr_cache
436 Group Origin Iif Pkts Bytes Wrong Oifs
437 4D4237EA C747010A 0 51 14484 0 2:1
438 4D4237EA C702010A 0 51 14484 0 2:1
439 4D4237EA C84C000A 2 53 15052 0 0:1
440
441 From the above we can deduce that traffic from input interface 0
442 (Iif 0, "eth0") is forwarded on output interface 2 (Oifs 2, = "bmf0"),
443 and traffic from input interface 2 (Iif 2, "bmf0") is forwarded on
444 output interface 0 (Oifs 0, "eth0"). The ":1" behind the Oifs numbers
445 indicates the TTL thresholds, in this case packets with TTL value 1
446 or less will not be forwarded.
447
448 When you are connecting an OLSR-BMF network to another multicast network
449 (e.g. a DVMRP network), you might be surprised that, when you ping the
450 all-routers multicast address 224.0.0.1 from within the OLSR network,
451 only the OLSR hosts respond. This is, however, compliant behaviour:
452 packets with their destination IP address in the range 224.0.0.0 -
453 224.0.0.255 are not routed by normal multicast protocols (i.e. their
454 TTL is implicitly assumed to be 1).
455
456
457 9. Testing in a lab environment
458 -------------------------------
459
460 When using equipment like switches or hubs, usually all the hosts see each
461 other. In an OLSR lab environment, we sometimes want to simulate the
462 situation that some hosts in the network cannot directly see other hosts
463 (as 1-hop neighbors) but only indirectly (as 2- or more-hop neighbors).
464 To simulate that situation, the iptables tool is often used (see
465 www.netfilter.org). For BMF, however, that is nog enough.
466
467 For OLSR testing, setup iptables on each host to drop packets from
468 all other hosts which are not direct (1-hop) neigbors. For example, to
469 drop all packets from the hosts with MAC addresses 00:0C:29:51:32:88,
470 00:0C:29:61:34:B7 and 00:0C:29:28:0E:CC, enter at the shell prompt:
471
472 iptables -A INPUT -m mac --mac-source 00:0C:29:51:32:88 -j DROP
473 iptables -A INPUT -m mac --mac-source 00:0C:29:61:34:B7 -j DROP
474 iptables -A INPUT -m mac --mac-source 00:0C:29:28:0E:CC -j DROP
475
476 For BMF testing, edit the file /etc/olsrd.conf, and specify the MAC
477 addresses of the hosts we do not want to see. (Even though packets from
478 these hosts are dropped by iptables, they are still received on network
479 interfaces if they are in promiscuous mode.) For example:
480
481 LoadPlugin "olsrd_bmf.so.1.4"
482 {
483 # Drop all packets received from the following MAC sources
484 PlParam "DropMac" "00:0C:29:51:32:88" # RemoteClient1
485 PlParam "DropMac" "00:0C:29:61:34:B7" # SimpleClient1
486 PlParam "DropMac" "00:0C:29:28:0E:CC" # SimpleClient2
487 }
488
489 See also the notes in the 'packet' manpage ("Packet sockets are not
490 subject to the input or output firewall chains").
491
492
493 10. Common problems, FAQ
494 ------------------------
495
496 ---------
497 Question:
498 On which platforms does BMF currently compile?
499
500 Answer:
501 Only on Linux. No compilation on Windows (yet). The oldest Linux
502 kernel on which the BMF plugin was tested was version 2.4.18.
503
504
505 ---------
506 Question:
507 When starting OLSRD with the BMF plugin, I can see the following
508 error message:
509
510 OLSRD Basic Multicast Forwarding (BMF) plugin: error opening /dev/net/tun: No such file or directory
511
512 Wat to do?
513
514 Answer:
515 Turn on the possibility to create a tuntap interface; see section 2 of this
516 file.
517
518
519 ---------
520 Question:
521 When starting OLSRD with the BMF plugin, I can see the following
522 error message:
523
524 OLSRD Basic Multicast Forwarding (BMF) plugin: error opening /dev/net/tun: No such device
525
526 Wat to do?
527
528 Answer:
529 First, turn on the possibility to create a tuntap interface; see section 2 of this
530 file. Check if the device is there:
531
532 ~ # ls -l /dev/net/tun
533 crw------- 1 root root 10, 200 Sep 9 2006 /dev/net/tun
534
535 If the device is there, but the error message remains to appear, the
536 tap/tun device is not compiled in your kernel. Try the command:
537
538 modprobe tun
539
540 If "modprobe tun" says something like "modprobe: Can't locate module tun", then either
541 it is not compiled at all or it is not compiled into the kernel.
542
543 Note: if you do not want to receive multicast packets, only forward the packets
544 that other hosts send, then you do not need the tuntap interface. This could be the
545 case if your host is purely an OLSR router; normally no traffic will be directed
546 to the router itself. In that case you can ignore this error message. Beware, though,
547 that you will then not be able to do the simple 'ping 224.0.0.1' test (as described in
548 section 4. How to check if it works) to check for the presence of all OLSR-BMF routers
549 in the network.
550
551
552 ---------
553 Question:
554 I have enabled BMF, but my multicast application is not receiving any
555 multicast packets.
556
557 Answer:
558 Many multicast applications must be configured to listen to a specific
559 network interface. Make sure that your multicast application is listening on
560 the BMF network interface, either by specifying the interface name itself
561 (e.g. "bmf0") or by specifying its IP address.
562
563
564 11. Version history
565 -------------------
566
567 31 Mar 2007: Version 1.4
568 * Optimized the standard forwarding mechanism in such a way that
569 retransmissions of packets are only done on those network interfaces
570 that make a host a multi-point relay (MPR) for the sender. I.e.:
571 retransmitting a packet on a network interface is not done if that
572 does not lead to any new hosts being reached.
573 * Optimized the standard forwarding mechanism such that, if the network
574 topology indicates there is only one neighbor on an interface, packets are
575 sent to the specific IP address (unicast) of that neighbor. If the network
576 topology indicates there are multiple neighbors, then BMF will still send
577 packets to the IP local-broadcast address.
578 * Introduced a new forwarding mechanism, using only IP-unicast to
579 forward packets. Packets are forwarded to the best candidate neighbor;
580 other neighbors listen promiscuously. IP-local broadcast is not used.
581 This saves air time on 802.11 WLAN networks, on which unicast packets are
582 usually sent at a much higher bit rate than broadcast packets (which are
583 sent at a basic bit rate).
584 This mechanism can be activated by specifying the following plugin
585 parameter:
586 PlParam "BmfMechanism" "UnicastPromiscuous"
587 See also section 6 - Advanced configuration.
588
589 18 Dec 2006: Version 1.3
590 * Added the possibility to configure the BMF network interface:
591 name (e.g. "bmf0"), type (tun or tap), IP address and subnet
592 mask.
593 * Flooding of local broadcast packets (e.g. with destination
594 IP address 192.168.1.255) can now be turned off by configuration.
595 * When an application sends packets to the BMF network interface, BMF
596 also floods these packets over the OLSR network.
597 * Removed the TTL decrementing so that equipment connected to
598 a non-OLSR interface can still send their IGMP messages (TTL = 1)
599 to a fixed multicast router (running e.g. mrouted - DVMRP)
600 connected to a non-OLSR interface on another host in
601 the OLSR network. In this way, a whole OLSR network, including
602 its non-OLSR capable hosts, can be made multicast-routable
603 from a fixed multicast-enabled IP network.
604 For an example of such a configuration read section 8 above.
605 * Removed the check for 'IsNullMacAddress' when creating a network
606 interface object. The check was not necessary and prevented
607 BMF to work on non-ethernet interfaces such as ppp.
608 * Bug fix: in case there are multiple OLSR interfaces, when an
609 application sends packets to one OLSR interface, BMF did not
610 flood these packets via the other OLSR interfaces. This is
611 fixed. Also, packets sent to an OLSR interface are transmitted
612 on the non-OLSR interfaces.
613
614 23 Oct 2006: Version 1.2
615 * Packets to a local broadcast destination have their destination
616 IP address adapted to the subnet on which they are forwarded.
617 This makes it possible to use broadcast-based services (such as
618 NetBIOS) across different IP subnets.
619 * The code to relate fragments with their main IP packet did not
620 work when the fragment arrived earlier than the main packet.
621 This would cause fragments of BMF-packets to be falsely forwarded.
622 For now, removed the forwarding of IP fragments. (Who's using
623 IP-fragments anyway?)
624 * Packets are forwarded from one non-OLSR interface to the other
625 non-OLSR interfaces.
626 * Various small optimizations and style improvements.
627
628 12 Jul 2006: Version 1.1
629 * Major updates in code forwarding from and to non-OLSR enabled
630 network interfaces.
631 * Debug level 9 gives a better indication of what happens to each
632 handled multicast/broadcast packet. To run the olsr daemon with
633 debug level 9, run "olsrd -d 9"; if you're only interested in
634 BMF debug messages, run "olsrd -d 9 | grep -i bmf".
635 * Can now deal with network interface removal ("ifdown eth1") and
636 addition ("ifup eth1").
637 * CRC-calculation for duplicate detection is done over first 256
638 bytes in packet instead of over full packet length.
639 * CRC calculated only on captured packets, and is subsequently
640 passed on in a special OLSR-BMF encapsulation header.
641 * Deals correctly with fragmented packets
642
643 27 Apr 2006: Version 1.0.1
644 * First release.
