Hi Steven,
I finally figured out the issue β the problem was with the
emaneeventservice which is used to push the location/pathloss events to the
EMANE/CORE system.
Short answer:
The event service was misconfigured to push the events to the wrong subnet
Long answer:
The event service works by pushing packets corresponding to
location/pathloss to a multicast IP. All nodes which subscribe to the
multicast IP can read the packets. The nodes which can read these packets
depend on the subnets on which these packets are sent across, since nodes
from different subnets can subscribe to the same multicast IP. In my case,
the event service should have been configured to push the events to the
control interface, because that is what the EMANE nodes are subscribed to.
Unfortunately, that was not to be in my XML. The settings were as follows:
Event service XML:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE eventservice SYSTEM "file:///usr/share/emane/dtd/eventservice.dtd
">
<eventservice>
<param name="eventservicegroup" value="224.1.2.8:45703"/>
<param name="eventservicedevice" value="eth0"/>
<generator definition="eelgenerator.xml"/>
</eventservice>
EMANE node platform XML:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE platform
SYSTEM 'file:///usr/share/emane/dtd/platform.dtd'>
<platform>
<param name="otamanagerchannelenable" value="on"/>
<param name="otamanagergroup" value="224.1.2.8:45702"/>
<param name="otamanagerdevice" value="ctrl0"/>
<param name="eventservicegroup" value="224.1.2.8:45703"/>
<param name="eventservicedevice" value="ctrl0"/>
<param name="controlportendpoint" value="0.0.0.0:47000"/>
<param name="antennaprofilemanifesturi" value=""/>
<nem definition="n1emane_ieee80211abgnem.xml" id="2" name="tap3.0.93">
<transport definition="n1transvirtual.xml">
<param name="device" value="eth0"/>
</transport>
</nem>
</platform>
Notice that the event service XML is configured to push packets to eth0
(192.168.3.x) while the nodes are configured to receive packets from ctrl0
(172.16.0.x). Once I changed the eth0 interface to the virtual control
interface at the host (of the form b.ctrl0net.XX where XX is variable, and
whose IP is 172.16.0.254), the nodes started to receive the events and
everything fell in place.
The other problem is to have the variable control interface name in event
service XML, for which I simply run a shell script which will get the
control interface name (from the 'ip' command) and replace it in the XML
before starting emane event service.
NOTE: As a side information, this can also be achieved by using eth0 but by
configuring the multicast TTL β which determines how βfarβ the multicast
packet should be sent across. I am yet to figure out how to make that work
in linux, if required.
Some really useful links on multicast IPs and multicast TTLs:
www.thegeekstuff.com/2013/05/ip-multicasting
http://ntrg.cs.tcd.ie/undergrad/4ba2/multicast/antony
Thank you very much for your time Steven. Really appreciate your assistance
Vijay
On Thu, Aug 18, 2016 at 11:23 AM, Vijayasarathy Rajagopalan <
[email protected]> wrote:
> Hi All,
>
> I am trying to emulate a simple network of two nodes - a ground node, and
> another mobile node which, from an elevation, moves up from the ground node
> at around 45 degrees for a certain duration, makes a circle with a specific
> radius at that point, and comes back to the same point where it started.
> The idea is to set up opportunistic contact between the two nodes. For the
> purpose of simplicity, I have made a IEEE802.11bg wifi connectivity between
> the two nodes, with the default values given by CORE (txpower of 0 dbm and
> frequency of 2.347 GHz). I use EMANE events to trigger the above mobility.
> For the mobility model, I have used MNM tools to generate an EEL file which
> contains GPS location and pathloss events per second for a duration of
> 10000 seconds.
>
>
> The problem is the following: While the location events are duly
> recognized by CORE, I suspect that the pathloss events are not being
> recognized properly. Going by a previous post on the EMANE users group, I
> have attached the output of the following emane shell commands: 1) emanesh
> localhost get stat '*' all (stats.txt) 2) emanesh localhost get table '*'
> all (tables.txt); 3) emanesh localhost get config '*' all (config.txt).
> From the table output, I see no indication of pathloss events received in
> the mobile node, against the ForwardPathLoss and the ReversePathLoss tables
> (while emaneeventservice executed with debug level info reports sending
> pathloss message).
>
> Also, a visual indicator (I presume) for pathloss at some point in the
> motion should be packet loss. I have empirically determined that
> connectivity between nodes for the above values should stop roughly around
> 1500-2000 metres between them (assuming all default values for IEE802.11bg
> for EMANE in CORE network emulator). I observe that even beyond this point,
> there is no packetloss (as pathloss should have caused), and neither does
> visual adjacency in CORE disappear/turn grey.
>
> Appreciate any assistance that I may get from the forum.
>
> Thanks,
> Vijay
>
>
_______________________________________________
emane-users mailing list
[email protected]
http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users
