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