Steven, The setup you described worked. The demo bash script is incredibly well made/modifiable but for the purposes of setting up simple distributed testing this was the better approach. I simply: -ran "emane platformfoo.xml -l 0 -d" on both machines -ran "emaneevent-dump" on the second machine -ran "emaneevent-pathloss 2 -I eth0" on the first machine Upon execution of the pathloss event on machine 1, machine 2 dumped the event.
Now that that is working, I have a question. How does the tutorial make the LXCs instantly? I tinkered around with LXCs myself but for container creation, the process needs to download the minimal Ubuntu OS. I used "lxc-create -n container_name -I ubuntu". Granted, further container creations copied the previously downloaded minimal OS, so subsequent creations were very quick, but the first LXC creation still took several minutes. Thank you. Very respectfully, Derek Lake -----Original Message----- From: Steven Galgano [mailto:[email protected]] Sent: Saturday, February 07, 2015 9:29 PM To: Lake, Derek [USA] Cc: [email protected] Subject: [External] Re: [emane-users] Distributed EMANE - cont'd Derek, I think it would be beneficial to simplify your setup. You don't need containers to run emane, since you have two linux machines just run emane directly on both. You can take platform1.xml from demo 0 and change the values: <param name="otamanagerdevice" value="eth1"/> <param name="eventservicedevice" value="eth1"/> to reflect the interface on your node that you will be routing your over-the-air and event multicast messages over. It is important that you can route traffic over that interface and hit your other node(s). You can use the same interface for both values. Copy platform1.xml to platform2.xml. Make changes to the same two parameters, where appropriate and update the nem element: <nem id="2" definition="bypassnem.xml"> <transport definition="transvirtual.xml"> <param name="address" value="10.100.0.2"/> <param name="mask" value="255.255.255.0"/> </transport> </nem> You don't need a routing protocol for this demonstration or the event service and event daemon instances. Once you have established connectivity across the 10.100.0.0/24 network you can add in additional pieces until you get the deployment you are looking for. -- Steven Galgano Adjacent Link LLC www.adjacentlink.com On 02/05/2015 10:38 AM, Lake, Derek [USA] wrote: > Firstly, here is my first post on this topic a few weeks ago (Jan 2015): > > http://pf.itd.nrl.navy.mil/pipermail/emane-users/2015-January/000656.html > > > > I am seeking to get very basic, barebones communication going between > two nodes on separate networks. > > As a follow up, the topics I believe may pertain to this question are: > > Demo 0 from the tutorial - using this as a sample to modify for my scenario > > OLSRD - specifically, routing1.conf and routing2.conf > > Platform xml files - platform1.xml and platform2.xml > > Bash scripts: democtl-host - test flow, notably the LXC container > creation / configuration > > OTA manager channel - 224.1.2.8:45702 > > Event service - 224.1.2.8:45703, and eventdaemon1.xml, eventdaemon2.xml > > Linux utility iptables > > (Optional) VMWare workstation > > (Highly preferable) Linux containers (LXCs) > > > > Just for context, I'm pretty new to all of these concepts. > > > > My planned approach is that I'd have two LXCs, one on host A, network A, > and another on host B, network B. > > Each host would, in my planned scenario, have a public IP with a port > which, using iptables, would forward all packets received to the LXC. > > For example, if LXC A was communicating with LXC B, the way I see this > working is that the packet would be forwarded as such: LXC A -> Host A, > Network A -> Host B, Network B:port B -> LXC B. > > Reverse communication would be the exact opposite. I'm having a bit of > trouble seeing where the OTA manager channel comes into my specific > scenario. > > > > Considering the OTA manager channel, I am consistently seeing an IP of > 224.1.2.8:45702, and for event service, 224.1.2.8:45703. > > If I were to have a common manager channel for both Network A and > Network B, would I just leave this as it is? I'm a little confused how > this is handled in a distributed approach. Can I just set this IP to one > of the host's public IP? > > > > Considering the LXCs, I have seen that the democtl-host bridges the NEM > LXCs using iptables. > > I don't really want more than one NEM on a host just to start, so is > this necessary? > > Would I just bridge LXC A to the host A NIC so it can reach the remote > host B? > > For the purposes of my scenario, I don't think I strictly even need the > LXC containers, if it's simple I'd like to just use the hosts NICs > themselves. > > If I were to change the democtl-host to not use LXCs, would this affect > the rest of the scenario to make it fail unless I make changes elsewhere? > > > > I want to just specify a remote IP instead of an LXC container IP, but I > know it's not that easy. > > I'm having troubles finding out which files need to be changed. Also, > from routing1.conf and routing2.conf, I see a reference to emane0 and > emane1. > > Since each host would only have 1 NEM, do I need to modify this to just > have emane0 on one and emane1 on the other? Or am I understanding this > incorrectly? > > > > I am pretty confident that for this scenario I'm describing, I'll need > emane to be running on each host / LXC (depending on if I use LXCs or not). > > I'm having trouble figuring out how all the configuration files (from > demo 0) would need to change to reflect this. > > > > I'm using at the moment, host A is running Windows with Ubuntu 14.04 in > VMWare Workstation, while host B is running Ubuntu as the main OS (no VM > involved). > > The VM is bridged to the NIC with its own public static IP. > > Host A and host B both have static IPs as well. > > If I can't get this going with a VM though, I could have Ubuntu as the > main OS on host A. > > I would like to use VMs but only if they don't overcomplicate the situation. > > > > I've searched the mailing list archives quite a bit to see a similar > scenario, the closest I seem to have found was this: > > http://emane-users.pf.itd.nrl.navy.narkive.com/B6OsXtHa/emane-prf-understanding-raw-transports > > This post is not my exact scenario, but I think it's in the general > ballpark. > > It's pretty old though (July 2010). > > > > Very respectfully, > > Derek Lake > > > > > > _______________________________________________ > 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
