Jeff,
Thanks for using the PRF. Based on your platform XML file, I do not
believe any of your traffic is being routed to the emulator.
All of your NEMs:
<nem definition="n4emane_ieee80211abgnem.xml" id="1"
name="tap1.0.221">
<transport definition="n4transvirtual.xml" group="1">
<param name="device" value="veth1.2"/>
</transport>
</nem>
<nem definition="n4emane_ieee80211abgnem.xml" id="2"
name="tap2.0.221">
<transport definition="n4transvirtual.xml" group="1">
<param name="device" value="veth2.2"/>
</transport>
</nem>
<nem definition="n4emane_ieee80211abgnem.xml" id="3"
name="tap3.0.221">
<transport definition="n4transvirtual.xml" group="1">
<param name="device" value="veth3.2"/>
</transport>
</nem>
are using internal transports. This is a new feature in 0.9.2 that
improves performance and simplifies configuration for the preferred
emane configuration: running 1 NEM per emulator instance except when
configuring multi-channel gateways. But you would have the same issue if
you were using external transports. The equivalent might look like this:
<nem definition="n4emane_ieee80211abgnem.xml" id="1"
name="tap1.0.221" transport="external">
<param name='platformendpoint' value='localhost:8101'/>
<param name='transportendpoint' value='localhost:8201'/>
<transport definition="n4transvirtual.xml" group="1">
<param name="device" value="veth1.2"/>
</transport>
</nem>
<nem definition="n4emane_ieee80211abgnem.xml" id="2"
name="tap2.0.221" transport="external">
<param name='platformendpoint' value='localhost:8102'/>
<param name='transportendpoint' value='localhost:8202'/>
<transport definition="n4transvirtual.xml" group="1">
<param name="device" value="veth2.2"/>
</transport>
</nem>
<nem definition="n4emane_ieee80211abgnem.xml" id="3"
name="tap3.0.221" transport="external">
<param name='platformendpoint' value='localhost:8103'/>
<param name='transportendpoint' value='localhost:8203'/>
<transport definition="n4transvirtual.xml" group="1">
<param name="device" value="veth3.2"/>
</transport>
</nem>
Since all your virtual interfaces reside as part of the same network
stack, the kernel will route traffic between them via the loopback and
not deliver traffic to the emulator.
If you are trying to configure a blackbox emulation take a look at using
Raw Transports instead of Virtual Transports:
https://github.com/adjacentlink/emane-tutorial/wiki/Demonstration-7
Additionally, you don't need the 'group' attribute when using internal
transports since you are not using emanegentransportxml and emanetransportd.
You can use emanesh to dump statistic tables to see why packets are
being dropped or in this case, that they were never hitting the emulator:
# emanesh localhost get table '*' all
I suspect that if you watch the transport accept tables as you are
completing traffic you will not see any values increment.
# emanesh localhost get table '*' transport UnicastPacketAcceptTable\
BroadcastPacketAcceptTable
0.9 restored all logs that were conditionally compiled out in 0.8. There
is no need to specify --with-verbose-logging, that is the default. You
can use --without-verbose-logging to compile logs out.
You were not seeing "EOR processing" logs because the emulator was
never seeing your traffic:
--
Steven Galgano
Adjacent Link LLC
www.adjacentlink.com
On 09/17/2014 05:43 PM, Ahrenholz, Jeffrey M wrote:
> [[=== SYSTEM INFORMATION ====]]
>
> HOST OPERATING SYSTEM: Ubuntu 14.04.1, 12.0.4.5
>
> HOST ARCHITECTURE: x86_64
>
> TARGET OPERATING SYSTEM (if different): N/A
>
> TARGET ARCHITECTURE (if different): N/A
>
> COMPILER and COMPILER VERSION (if applicable): gcc 4.8.2-19ubuntu1
>
>
> [[=== VERSION INFORMATION ====]]
>
> EMANE VERSION: 0.9.2
>
> ACE VERSION: libace-6.0.3+dfsg-0
>
> LIBXML2 VERSION: libxml2-2.9.1+dfsg1-3ubuntu4
>
> LIBPCAP_VERSION (if applicable): N/A
>
> WINPCAP_VERSION (if applicable): N/A
>
> EMANE ADD-ON NAMES and VERSIONS (if applicable): N/A
>
>
> [[== INSTALLATION INFORMATION ==]
>
> EMANE INSTALLATION METHOD (MAKE INSTALL, RPM, OTHER)
> (if applicable): debs
>
> [[=== PROBLEM INFORMATION ====]]
>
> TYPE (COMPILATION, INSTALLATION, EXECUTION, OTHER): EXECUTION
>
> BRIEF SUMMARY:
>
> I'm trying to update CORE to support EMANE 0.9.2. When I use RfPipe or 802.11
> models, with 2-ray, freespace, or pathloss propagation models, I'm not able
> to get packets to drop. Maybe my configuration is incorrect?
>
> DETAILED DESCRIPTION:
> REPEAT BY:
>
> I could send you a patch for CORE to repeat if necessary. It simply involves
> placing 3 routers and a WLAN, choosing the EMANE model, and trying to move a
> node out of range (for 2-ray/freespace), or using the emaneevent-pathloss
> tool (for pathloss).
>
> CONFIGURATION:
>
> 3 NEMs using virtual transport on one platform. See attached XML.
>
> ATTACHED FILE DESCRIPTION:
>
> Attached tarball contains these files:
> platform.xml
> n4emane_ieee80211abgmac.xml
> n4emane_ieee80211abgnem.xml
> n4emane_ieee80211abgphy.xml
> n4transvirtual.xml
>
> SAMPLE FIX/WORKAROUND:
>
> Also I recompiled the debs using this line in the debian/rules file:
> override_dh_auto_configure:
> dh_auto_configure -- --with-verbose-logging
>
> I was hoping to get something useful out of emane.log with log level 4. This
> was the only output (using RfPipe model, three nodes, you can see OSPFv3
> hello packets every 2 seconds):
>
> 14:36:04.070752 DEBUG TRANSPORTI 001 VirtualTransport::readDevice src 1, dst
> 65535, dscp 48, length 106
> 14:36:04.070839 DEBUG TRANSPORTI 003 VirtualTransport::processUpstreamPacket
> src 1, dst 65535, dscp 48, length 106
> 14:36:04.070837 DEBUG TRANSPORTI 002 VirtualTransport::processUpstreamPacket
> src 1, dst 65535, dscp 48, length 106
> 14:36:06.036799 DEBUG TRANSPORTI 001 EthernetTransport::lookupArpCache no nem
> found for 33:33:00:00:00:05, using broadcast mac address
> 14:36:06.036913 DEBUG TRANSPORTI 001 VirtualTransport::readDevice src 1, dst
> 65535, dscp 48, length 114
> 14:36:06.037112 DEBUG TRANSPORTI 003 VirtualTransport::processUpstreamPacket
> src 1, dst 65535, dscp 48, length 114
> 14:36:06.037109 DEBUG TRANSPORTI 002 VirtualTransport::processUpstreamPacket
> src 1, dst 65535, dscp 48, length 114
> 14:36:06.081926 DEBUG TRANSPORTI 003 EthernetTransport::lookupArpCache no nem
> found for 33:33:00:00:00:05, using broadcast mac address
> 14:36:06.081989 DEBUG TRANSPORTI 003 VirtualTransport::readDevice src 3, dst
> 65535, dscp 48, length 106
> 14:36:06.082091 DEBUG TRANSPORTI 001 VirtualTransport::processUpstreamPacket
> src 3, dst 65535, dscp 48, length 106
> 14:36:06.082099 DEBUG TRANSPORTI 002 VirtualTransport::processUpstreamPacket
> src 3, dst 65535, dscp 48, length 106
> 14:36:06.089069 DEBUG TRANSPORTI 002 EthernetTransport::lookupArpCache no nem
> found for 33:33:00:00:00:05, using broadcast mac address
>
> When I move nodes (and have CORE generate location events) I can see the
> events in the log:
> 14:38:09.127758 DEBUG EventService packet received len: 65
> 14:38:09.127833 DEBUG PHYI 001 FrameworkPHY::processEvent event id: 100
> 14:38:09.127840 DEBUG PHYI 003 FrameworkPHY::processEvent event id: 100
> 14:38:09.127853 DEBUG PHYI 002 FrameworkPHY::processEvent event id: 100
> 14:38:09.127886 DEBUG PHYI 001 FrameworkPHY::processEvent location event:
> nem: 1 position: lat: 47.575160 lon: -122.119025 alt: 2.000000 orientation:
> none velocity: none
> 14:38:09.127888 DEBUG PHYI 003 FrameworkPHY::processEvent location event:
> nem: 1 position: lat: 47.575160 lon: -122.119025 alt: 2.000000 orientation:
> none velocity: none
> 14:38:09.127899 DEBUG PHYI 002 FrameworkPHY::processEvent location event:
> nem: 1 position: lat: 47.575160 lon: -122.119025 alt: 2.000000 orientation:
> none velocity: none
>
> (As a side note, how can I get this output in the log file?: "MACI %03hu %s
> upstream EOR processing: src %hu, dst %hu, max noise %f, signal in noise %s,
> SINR %f")
>
>
>
>
> _______________________________________________
> 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
