Italiano English
Edit History Actions

attachment:bmfreadme.txt of ZeroconfServices

Attachment 'bmfreadme.txt'

Download

   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.

New Attachment

File to upload
Rename to
Overwrite existing attachment of same name
In which Country is ninux.org based?

Attached Files

To refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
  • [get | view] (2007-05-14 21:26:12, 25.9 KB) [[attachment:bmfreadme.txt]]