Hi If you are generating and receiving multicast "on the box" and are not expecting to "forward" multicast on any of your "real lan" interfaces then you could probably disable bmf. Otherwise if you are expecting to do so you will need some sort of multicast router or bmf.
FYI, bmf0 and emane0 are both virtual interfaces, olsrd-bmf reads and writes pkts via bmf0 and emane does the same on eman0. So basically bmf0 is the entry/exit point for local multicast, bmf also reads/writes multicast to/from any configured "non olsr" or lan interfaces like eth0. While emane0 is the entry/exit point for ALL emulation "radio" traffic. So olsrd-bmf sits on top of emane0 and any other "olsr active" interfaces. So local multicast would flow like this: APP ---> bmf0 ---> OLSRD/BMF ---> emane0 --->MAC ---> PHY ---> OTA ---> PHY ---> MAC ---> emane0 ---> OLSRD/BMF ---> bmf0 ----> APP and external multicast would replace bmf0 with eth0. Its the bmf plugin configuration that connects them, emane has no knowledge about olsrd and/or bmf. Regrads Joe On 04/29/2014 06:38 PM, Anders Nilsson Plymoth wrote: > Hi Joseph, > > This really helped. Thanks! > > > Are you running your own generated emane scenario or are you > running the emane tutorial ? > The emane tutorial configures non-emane applications and services > in order to demonstrate emulator usage. > > > Yes, I was going through the tutorial and using that as base for my > setup. > > > > I am assuming you are running olsrd since bmf0 is mentioned. > > > Yes. I wanted to use OLSR for routing between the nodes. > > > > Are you running olsrd over emane (most common) or are you running > it in tandem with emane0 as a network interface and olsrd running > on another interface ? > > Assuming the former: > > 1) is olsrd configured to use emane0 as the olsrd interface ? > 2) are you configuring the bmf0 interface address since the > default is to use the first olsrd interface address with 32 bit > netmask I do believe ? > > > I was using the tutorial as a base with OLSR and 802.11abg. It seems > all OLSR traffic is sent over emane0 (HELLO, TC etc). I am not sure > how olsr is configured is the tutorial, as the routingx.conf files > looks really thin and as far I understand does not explicitly state > which interface to use. > > Also, the issue really seems to be with bmf. I now see that it in fact > relates to the olsr-bmf module, of which I am unfamiliar. Disabling > bmf and olsr fixes my problem, and my application receives packets. > Thank you for pointing this out. > > Could you please help me explaining how olsr is used and configured in > the tutorial? The demo init script loads and configures olsr, but what > is the purpose of the bmf module and why is it needed? How do I make > it work with my application? > > > > As you probably know, In the case where applications do not > specify an interface of interest, the interface would be dictated > by the unicast forwarding table if possible. This is why bmf0 > installs the "catch-all route" assuming that all multicast traffic > will be handled by bmf configured interfaces. > > > Yes, although the application do not actually register the interface > but rather the IP address, which is normally the same thing. My > application register the IP address of the emane0 interfaces, which in > this case seems to be the same as the IP address of the bmf0. (It is > virtual?) Does this mean that traffic going through the bmf0 > interface, will in reality be sent via the emane0 radio interface? > > > If the above configuration is correct packets generated by you > application should be "captured" by bmf0 and then pushed towards > emane0, by default. > > > Without the explicit route for my multicast address to emane0, my > application do receive the packets, but via bmf0. > > > On the upstream packets would be sniffed off of emane0 and pushed > into bmf0 for the kernel to distribute to listening applications. > > > OK, so just to verify, packets are actually received over radio and > emane0? > > > Please note that ip ttl and firewall rules come into play here > often too. > > > OK. I will see to how to disable olsr-bmf and just use plain olsr. > > Thanks! > Anders > > > > > > Joseph Giovatto > > adjacentlink.com <http://adjacentlink.com> > > > > On 04/28/2014 06:29 PM, Anders Nilsson Plymoth wrote: >> Hi, >> >> Is your application sending IGMP join messages out the emane0 >> interface or another interface (e.g. bmf0 where it does seem >> to work)? Have you done any testing of your application on >> systems with multiple interfaces configured? >> >> >> Yes, we have used it on other systems with many interfaces. The >> socket option call to join the group explicitly specifies the IP >> address of the interface to join, which is required for it to >> work on our multihomed hosts. Multihoming is standard as we have >> a wired control interface, and one or two wireless data >> interfaces, much like in the setup here. >> >> Actually, I do see IGMP join messages sent to 224.0.0.22 on bmf0, >> for our multicast group 224.1.0.1. I don't know why they are sent >> on bmf0, or actually how bmf0 is configured actually. >> Changing the routing table so that 224.0.0.0/4 >> <http://224.0.0.0/4> points to emane0 doesn't help, the IGMP join >> is still sent of bmf0. >> But, the packets do arrive on emane0 (tcpdump), but do reach the >> application unless the route for 224.1.0.1 to emane0 is removed. >> This is strange. I freshly installed Ubuntu 13.10 on this host >> specifically for EMANE, and having nothing else installed except >> what were need etc. >> >> Thanks, >> Amders >> >> >> >> >> >> >> -Jeff >> >> > -----Original Message----- >> > From: Anders Nilsson Plymoth [mailto:[email protected] >> <mailto:[email protected]>] >> > Sent: Monday, April 28, 2014 2:01 PM >> > To: Jeff Weston >> > Cc: emane-users >> > Subject: Re: [emane-users] Multicast packets not received >> over radio interface >> > >> > Hi Jeff, >> > >> > >> > Thank you for your reply! >> > >> > >> > >> > >> > When you say " I tried setting rp_filter to 0 on ALL >> interfaces", I'm not sure what you mean. >> net.ipv4.conf.*.rp_filter includes >> > individual interface sysctls as well as "default" and >> "all". >> > >> > >> > >> > >> > Yes, thats what I did. I set >> net.ipv4.conf.default.rp_filter and >> net.ipv4.conf.all.rp_filter to 0 in /etc/sysctl.conf and ran >> sysctl -p. Since this >> > didn't update the settings on all interfaces, like you >> mentioned below a reboot was needed, I manually also set the >> rp_filter entries to 0 >> > for all interfaces in /proc/sys/net/ipv4/conf/xxx/rp_filter. >> > >> > >> > >> > >> > >> > There is also an Ubuntu-specific detail here, at >> least with newer Ubuntu (e.g. 12.04) -- the distro does not >> set this in >> > /etc/sysctl.conf, but in >> /etc/sysctl.d/10-network-security.conf. So if you set it in >> /etc/sysctl.conf, it may get overridden by the >> > other setting. >> > >> > >> > >> > Sorry, I am actually running Ubuntu 13.10 (not 11.10). I >> also changed the setting in >> /etc/sysctl.d/10-network-security.conf and tested with >> > sysctl -p and rebooting. >> > >> > >> > >> > I would set "default" and "all" and reboot so that >> the other interfaces pick up "default". 'sysctl -p' will >> reload the sysctl values, >> > but since the interfaces already exist they will not >> pick up "default" values -- you need to reboot or perhaps >> just restart >> > networking. You can check whether it has taken >> effect by 'sysctl -a 2>/dev/null | grep -F .rp_filter'. You >> want all of the values >> > returned to be 0. >> > >> > >> > >> > >> > Yes, 'sysctl -a 2>/dev/null | grep -F .rp_filter' >> indicates they are all set to zero, but I still have the same >> issue. My application do not >> > receive packets after setting the 224.1.0.1 to emane0, >> although I do receive them on tcpdump ( 'tcpdump -i eman0 -n' >> ). I changed the >> > route to 224.1.0.1/32 <http://224.1.0.1/32> so only the >> address I use is affected, but no difference. Without the >> route, I do receive, but over bmf0 rather than >> > eman0. >> > >> > >> > (otamanager and eventservice are configured to run on >> 224.3.2.8). >> > >> > >> > Do you have any other idea why my application doesn't >> receive multicast over emane0? The application runs fine over >> our non-emulated >> > wireless testbed. >> > >> > >> > Thanks, >> > Anders >> > >> > >> > >> > >> > >> > -Jeff Weston >> > >> > >> > > -----Original Message----- >> > > From: [email protected] >> <mailto:[email protected]> >> [mailto:[email protected] >> <mailto:[email protected]>] On Behalf >> Of Anders Nilsson >> > Plymoth >> > > Sent: Monday, April 28, 2014 12:21 PM >> > > To: [email protected] >> <mailto:[email protected]> >> > > Subject: [emane-users] Multicast packets not >> received over radio interface >> > > >> > > Hi, >> > > >> > > >> > > I am running the latest version of EMANE, from the >> repo, on an Ubuntu 11.10 host. >> > > >> > > My problem is that I can not receive multicast >> packets over the radio interface. Unicast works without issue. >> > > >> > > By default, there is a route setup by EMANE to >> 224.0.0.0/4 <http://224.0.0.0/4> pointing to bmf0, the bridge >> interface. I am using multicast address >> > > 224.1.0.1, >> > > and when using the default setup I am receiving >> packets over bmf0 interface, which is not what I want; >> obviously I want to >> > receive >> > > the >> > > packets over the emane0 radio interface. >> > > >> > > If I add a route to 224.1.0.0/24 >> <http://224.1.0.0/24> to emane0, I can the see packets arrive >> on emane0 using tcpdump, but they are never received >> > by my >> > > application. I found an older posting: >> > > >> http://pf.itd.nrl.navy.mil/pipermail/emane-users/2012-May/000339.html >> > > >> > > where they say I should set rp_filter to 0 in order >> for applications to receive multicast packets. I tried >> setting rp_filter to 0 on >> > > ALL >> > > interfaces, and that didn't help. I am still not >> receiving any packets. >> > > >> > > >> > > Could someone help me find the issue? >> > > >> > > >> > > Thanks, >> > > Anders >> > >> > >> > >> >> >> >> >> _______________________________________________ >> emane-users mailing list >> [email protected] <mailto:[email protected]> >> http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users > > > _______________________________________________ > emane-users mailing list > [email protected] > <mailto:[email protected]> > http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users > >
_______________________________________________ emane-users mailing list [email protected] http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users
