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 > > > > 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 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]] >> > 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 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]] On Behalf Of Anders Nilsson >> > Plymoth >> > > Sent: Monday, April 28, 2014 12:21 PM >> > > To: [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/4pointing >> > 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 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 > [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 > >
_______________________________________________ emane-users mailing list [email protected] http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users
