adjacentlink / emane Goto Github PK

The bool configuration parameter is registered with a minimum value of 1 (true). The patch below is a possible fix.

diff --git a/src/libemane/frameworkphy.cc b/src/libemane/frameworkphy.cc
index b8591d2..3f7fe22 100644
--- a/src/libemane/frameworkphy.cc
+++ b/src/libemane/frameworkphy.cc
@@ -177,8 +177,7 @@ void EMANE::FrameworkPHY::initialize(Registrar & registrar)
                                         " propagation associated with a received packet will be clamped"
                                         " to their respective maximums defined by noisemaxsegmentoffset,"
                                         " noisemaxsegmentduration and noisemaxmessagepropagation. When"
-                                        " disabled, any packet with an above max value will be dropped.",
-                                        1);
+                                        " disabled, any packet with an above max value will be dropped.");


   configRegistrar.registerNumeric<std::uint64_t>("noisemaxsegmentoffset",

Reported on mailing list by Leonid Veytser:

EMANE 0.9.1 will crash if a log message that is generated is larger than the size of the char buff[1024] array used in LogService. Attached is a simple patch that checks for buffer overflow and concatenates the messages to the size of the buffer.

Maybe a better thing to do is to rework the LogService to use std::stringstream to build the log string instead of char array?

diff --git a/src/libemane/logservice.cc b/src/libemane/logservice.cc
index 20d7387..568905e 100644
--- a/src/libemane/logservice.cc
+++ b/src/libemane/logservice.cc
@@ -353,6 +353,10 @@ void EMANE::LogService::vlog_i(LogLevel level, const char *fmt, va_list ap)

   len += vsnprintf(buff + len, sizeof(buff) - len, fmt, ap);

+  // Make sure we are not overflowing the buffer. If we are - concatenate it.
+  if ( len > sizeof(buff) )
+    len = sizeof(buff);
+
   if(bDecoupleLogging_ == false)
     {
       writeLogString(buff, level);  

Under high traffic load and certain data rate configurations, when down stream traffic arrives it is possible for the packet queue to be empty but the previous packet end-of-transmission (EOT) time to still be in the future. Failure to check for that condition leads to immediate transmission of the newly arrived packet instead of waiting for EOT.

Found during regression testing and re-verified with iperf.

I am on step 3 of the installation instructions for Ubuntu 16.04 and am getting an error regarding my protoc version. Below is the portion where the error is thrown. I checked antennaprofileevent.pb.h and it said protoc version 3, but that is what I have. You can see that I check the protoc version at the end. Any suggestions?

make[3]: Entering directory '/home/kyle/Documents/gmuGRA/EMANE/emane/src/libemane'
/bin/bash ../../libtool --tag=CXX --mode=compile g++ -std=c++11 -DPACKAGE_NAME="emane" -DPACKAGE_TARNAME="emane" -DPACKAGE_VERSION="1.0.1" -DPACKAGE_STRING="emane\ 1.0.1" -DPACKAGE_BUGREPORT="emane\ at\ adjacent\ link\ dot\ com" -DPACKAGE_URL="" -DPACKAGE="emane" -DVERSION="1.0.1" -DHAVE_CXX11=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -D__BYTE_ORDER=__LITTLE_ENDIAN -D__LITTLE_ENDIAN=1234 -D__BIG_ENDIAN=4321 -I. -I../../include -I/usr/include/libxml2 -pthread -I/usr/include/uuid -DVERBOSE_LOGGING -g -O3 -Wall -Wextra -MT libemane_la-antennaprofileevent.lo -MD -MP -MF .deps/libemane_la-antennaprofileevent.Tpo -c -o libemane_la-antennaprofileevent.lo test -f 'antennaprofileevent.cc' || echo './'antennaprofileevent.cc
libtool: compile: g++ -std=c++11 -DPACKAGE_NAME="emane" -DPACKAGE_TARNAME="emane" -DPACKAGE_VERSION="1.0.1" "-DPACKAGE_STRING="emane 1.0.1"" "-DPACKAGE_BUGREPORT="emane at adjacent link dot com"" -DPACKAGE_URL="" -DPACKAGE="emane" -DVERSION="1.0.1" -DHAVE_CXX11=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -D__BYTE_ORDER=__LITTLE_ENDIAN -D__LITTLE_ENDIAN=1234 -D__BIG_ENDIAN=4321 -I. -I../../include -I/usr/include/libxml2 -pthread -I/usr/include/uuid -DVERBOSE_LOGGING -g -O3 -Wall -Wextra -MT libemane_la-antennaprofileevent.lo -MD -MP -MF .deps/libemane_la-antennaprofileevent.Tpo -c antennaprofileevent.cc -fPIC -DPIC -o .libs/libemane_la-antennaprofileevent.o
In file included from antennaprofileevent.cc:35:0:
antennaprofileevent.pb.h:12:2: error: #error This file was generated by a newer version of protoc which is
#error This file was generated by a newer version of protoc which is
^
antennaprofileevent.pb.h:13:2: error: #error incompatible with your Protocol Buffer headers. Please update
#error incompatible with your Protocol Buffer headers. Please update
^
antennaprofileevent.pb.h:14:2: error: #error your headers.
#error your headers.
^
antennaprofileevent.pb.h:22:35: fatal error: google/protobuf/arena.h: No such file or directory
compilation terminated.
Makefile:1094: recipe for target 'libemane_la-antennaprofileevent.lo' failed
make[3]: *** [libemane_la-antennaprofileevent.lo] Error 1
make[3]: Leaving directory '/home/kyle/Documents/gmuGRA/EMANE/emane/src/libemane'
Makefile:2240: recipe for target 'install' failed
make[2]: *** [install] Error 2
make[2]: Leaving directory '/home/kyle/Documents/gmuGRA/EMANE/emane/src/libemane'
Makefile:397: recipe for target 'install-recursive' failed
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory '/home/kyle/Documents/gmuGRA/EMANE/emane/src'
Makefile:444: recipe for target 'install-recursive' failed
make: *** [install-recursive] Error 1
(python2) kyle@kyle-ThinkPad-T450s:~/Documents/gmuGRA/EMANE/emane$ protoc --version
libprotoc 3.0.0

When running ./autogen.sh I get the following...

I am using Ubuntu 18.04

user@ubuntu:~/Downloads/emane$ ./autogen.sh
./autogen.sh: line 82: autoreconf: command not found

EMANE::NEMQueuedLayer::processWorkQueue should probably continue when epoll_wait() returns an error due to being interrupted by a signal handler.

The attached patch is a possible fix.
nemqueuedlayer.cc.patch.txt

Errors like the following occur when building the develop branch on Ubuntu 16.04.1 i686 using g++ version 5.4.0:

eventstatisticpublisher.cc:115:49: error: call of overloaded 'Any(<brace-enclosed initializer list>)' is ambiguous
                                           Any{0L},
                                                 ^
In file included from ../../include/emane/statistic.h:37:0,
                 from ../../include/emane/statisticnumeric.h:37,
                 from eventstatisticpublisher.h:37,
                 from eventstatisticpublisher.cc:33:
../../include/emane/any.h:142:5: note: candidate: EMANE::Any::Any(const EMANE::Any&)
     Any(const Any & rhs);
     ^
../../include/emane/any.h:137:14: note: candidate: EMANE::Any::Any(const bool&)
     explicit Any(const bool & bValue);
              ^
../../include/emane/any.h:132:14: note: candidate: EMANE::Any::Any(const string&)
     explicit Any(const std::string & sValue);
              ^
../../include/emane/any.h:127:14: note: candidate: EMANE::Any::Any(const char*)
     explicit Any(const char * pzValue);
              ^
../../include/emane/any.h:117:14: note: candidate: EMANE::Any::Any(double)
     explicit Any(double dValue);
              ^
../../include/emane/any.h:112:14: note: candidate: EMANE::Any::Any(float)
     explicit Any(float fValue);
              ^
../../include/emane/any.h:107:14: note: candidate: EMANE::Any::Any(uint8_t)
     explicit Any(std::uint8_t u8Value);
              ^
../../include/emane/any.h:102:14: note: candidate: EMANE::Any::Any(int8_t)
     explicit Any(std::int8_t i8Value);
              ^
../../include/emane/any.h:97:14: note: candidate: EMANE::Any::Any(uint16_t)
     explicit Any(std::uint16_t u16Value);
              ^
../../include/emane/any.h:92:14: note: candidate: EMANE::Any::Any(int16_t)
     explicit Any(std::int16_t i16Value);
              ^
../../include/emane/any.h:87:14: note: candidate: EMANE::Any::Any(uint32_t)
     explicit Any(std::uint32_t u32Value);
              ^
../../include/emane/any.h:82:14: note: candidate: EMANE::Any::Any(int32_t)
     explicit Any(std::int32_t i32Value);
              ^
../../include/emane/any.h:77:14: note: candidate: EMANE::Any::Any(uint64_t)
     explicit Any(std::uint64_t u64Value);
              ^
../../include/emane/any.h:72:14: note: candidate: EMANE::Any::Any(int64_t)
     explicit Any(std::int64_t i64Value);
              ^

The attached patch is a possible fix.
emane-any-ambiguous.patch.txt

Reported via email by Adrian Granados:

I think I found the problem and it has to do with how EMANE handles frames with “unknown protocol” types.

If you see the method “parseFrame” in src/transports/common/ethernettransport.cc, EMANE is assuming that the destination NEM for a frame that contains an “unknown protocol” type is NEM_BROADCAST_MAC_ADDRESS. I don’t believe EMANE should make such assumption.

In my particular scenario, the proprietary protocol I’m testing has an ether type 0x2800 (unknown for EMANE), but the source and destination MAC addresses are interpreted as normal and can be unicast or broadcast. Because EMANE assumes broadcast, it processes all frames with unicast and broadcast MAC destinations using the multicast rate. In my scenario, multicastrate=2 and unicastrate=8, which results in nodes A and B seeing each other using broadcast but not using unicast frames. This is why “ping” works (nodes CANNOT ping each other) but the “unknown protocol” doesn’t (nodes CAN communicate with each other).

My suggestion is to change:

   // unknown protocol
     default:
       LOGGER_VERBOSE_LOGGING(pPlatformService_->logService(),
                              DEBUG_LEVEL,
                              "TRANSPORTI %03d EthernetTransport::%s allow unknown protocol %02X",
                              id_,
                              __func__,
                              u16ethProtocol);

       // use broadcast mac addr
       rNemDestination = NEM_BROADCAST_MAC_ADDRESS;

       // set dscp to 0
       rDspc = 0;

to:

    // unknown protocol
    default:
        LOGGER_VERBOSE_LOGGING(pPlatformService_->logService(),
                              DEBUG_LEVEL,
                              "TRANSPORTI %03d EthernetTransport::%s allow unknown protocol %02X",
                              id_,
                              __func__,
                              u16ethProtocol);

       // broadcast always mode
        if(bBroadcastMode_)
           {
             rNemDestination = NEM_BROADCAST_MAC_ADDRESS;
           }
        // use ether dst
        else
          {
            rNemDestination = Utils::ethaddr4_to_id(&pEthHeader->dst);
          }

        // set dscp to 0
        rDspc = 0;

After making the change above, the emulation works as expected.

Modify the timer service to allow scheduling a callable in addition to the existing functionality that allows scheduling calls to processTimedEvent .

The current roll rotation equation is incorrect. It assumes roll is counter clockwise instead of clockwise along the z-axis in the up direction.

Is publishing a new LocationEvent the only way to update a node's gps coordinates? I noticed that specifying an azimuth, elevation, and magnitude does not update the latitude and longitude.

For example (using tutorial vm) if i do,

event = LocationEvent()
event.append(1,latitude=40.021235,longitude=-74.317441,altitude=3.0,azimuth=90.0,elevation=0.0,magnitude=20.0)
service.publish(1,event)

and then look at the pseudoterminalfile (/dev/pts/0)

then i get:

$GPGGA,172631,4001.2740,N,07419.0464,W,2,08,1.1,3.0,M,-34.0,M,,7B
$GPRMC,172631,A,4001.2740,N,07419.0464,W,000.0,000.0,200319,000.0,W76
$GPGSA,A,3,01,02,03,04,05,06,07,08,,,,,1.8,1.1,1.331
$GPGSV,2,1,08,01,41,104,41,03,09,084,51,05,70,030,39,07,35,185,2575
$GPGSV,2,2,08,05,10,297,25,07,53,311,21,09,02,029,29,11,48,064,327B
$GPVTG,90.0,T,90.0,M,38.9,N,72.0,K49
$GPGGA,172632,4001.2740,N,07419.0464,W,2,08,1.1,3.0,M,-34.0,M,,78
$GPRMC,172632,A,4001.2740,N,07419.0464,W,000.0,000.0,200319,000.0,W75
$GPGSA,A,3,01,02,03,04,05,06,07,08,,,,,1.8,1.1,1.331
$GPGSV,2,1,08,01,41,104,41,03,09,084,51,05,70,030,39,07,35,185,2575
$GPGSV,2,2,08,05,10,297,25,07,53,311,21,09,02,029,29,11,48,064,327B
$GPVTG,90.0,T,90.0,M,38.9,N,72.0,K49

thanks,
Ed

The reset logic in getQueueMetrics() around line 155 of queuemetricmanager.cc does not seem to reset the stat. This caused the runnig average to be incorrect. This is in EMANE code /src/libemane/ queuemetricmanager.cc. I replaced the lines

       iter.second.u32NumDiscards_ = 0;
       iter.second.delayMicroseconds_ = EMANE::Microseconds::zero();

with

      QueueData & rData = getQueueData_i(iter.first);
      rData.u32NumSamples_ = 0;
      rData.u32NumDiscards_ = 0;
      rData.delayMicroseconds_ = EMANE::Microseconds::zero();

This quick workaround seems to do the trick.

Cleanup unneeded google::protobuf exception blocks and google::protobuf::RepeatedPtrField usage. Once removed, emane builds with the version of protocol buffers available via EPEL for EL6.

Initial investigation shows better utilization by storing packet segment components in a std::deque.

There is a bug in the way flow control token grant exchanges occur. When a radio model sends a token count to a transport it waits for an acknowledgment from the transport with the same number of tokens it granted. When the acknowledgment is received it checks against the current token count and not the last grant token count. Under heavy load when the available tokens changes prior to the acknowledgment the radio model will restart the grant exchange. This causes packets sent by the transport to be discarded until a matching grant acknowledgment is received.

The following patch is a possible fix:

--- a/src/libemane/inetaddr.cc
+++ b/src/libemane/inetaddr.cc
@@ -410,3 +410,8 @@ std::string EMANE::INETAddr::str(bool bWithPort) const
 {
   return pImpl_->str(bWithPort);
 }
+
+std::uint16_t EMANE::INETAddr::getPort() const
+{
+  return pImpl_->getPort();
+}

When propagationmode is set to freespace, does EMANE take into account the curvature of the earth?

For example, if I place two NEMs quite far from each other in terms of latitude and longitude, but give them very powerful radios, will the curvature of the earth prevent them from linking? Or is the simulation purely 2-D?

Thanks!

When I install EMANE, I see that libemane.so is installed and appears to have symbols matching the source code. However, the libemane headers are not installed (eventservice.h, multicastsocket.h, for example). Why is this? I want to write C++ code using libemane classes but am not sure how to do this without the headers.

We have a project that uses EMANE to emulate some customized networks. Currently, we encounter several problems during the debugging and any of your suggestions or comments would be greatly appreciated. The EMANE source code is checked out from Github and the OS is Ubuntu 16.04.

First, we could not build and compile using the IDE - CLion 2018.2, and the error is Linking CXX executable emane. The build information and CMakeLists are attached and any comments are very appreciated. The build and install are successful when using the terminal and following commands:

make deb WITHOUT_PYTHON3=1
cd .debbuild
sudo dpkg -i *.deb

Another thing that we have noticed is that the message we tried to print out is shown in the terminal after typing "make deb WITHOUT_PYTHON3=1". And nothing is shown when we were running the provided two nodes communication example (Tutorial 0). The file we changed is: "emane/src/libemane/nembuilder.cc" and we just add a line of "cout" code.

Our current approach is first editing the source code, then package and install the deb file, and running the provided tutorial. A single modification requires lots of time and efforts, Do you have any suggestions to make the whole process easier? Thank you very much for the help.

emane_build_error.txt

CMakeLists.txt

Reported via email by Leonid Veytser:

There appears to be a minor bug in the LocationEventInfoTable. As displayed below an event was sent with orientation of yaw of 90 and pitch and roll of zero, however the LocationEventInfoTable via emanesh displays roll as 90 and pitch and yaw as 0.

16:51:39.025239 DEBUG PHYI 001 Link16::PHYLayer::processEvent location event: nem: 1 position: lat: 12.437223 lon: -100.130000 alt: 7607.489000 orientation: pitch: 0.000000 roll: 0.000000 yaw: 90.000000 velocity: none nem: 2 position: lat: 13.796145 lon: -99.207276 alt: 9135.519000 orientation: pitch: 0.000000 roll: 0.000000 yaw: 90.000000 velocity: none nem: 3 position: lat: 12.451756 lon: -99.190534 alt: 9135.519000 orientation: pitch: 0.000000 roll: 0.000000 yaw: 90.000000 velocity: none nem: 4 position: lat: 11.128367 lon: -99.186763 alt: 9135.522000 orientation: pitch: 0.000000 roll: 0.000000 yaw: 90.000000 velocity: none nem: 5 position: lat: 13.774445 lon: -96.428611 alt: 15.000000 orientation: none velocity: none nem: 6 position: lat: 12.428334 lon: -96.428056 alt: 15.000000 orientation: none velocity: none nem: 7 position: lat: 11.082501 lon: -96.427778 alt: 15.000000 orientation: none velocity: none

nem 1   phy LocationEventInfoTable
| NEM | Latitude  | Longitude  | Altitude | Pitch | Roll | Yaw | Azimuth | Elevation | Magnitude |
| 1   | 12.437223 | -100.13    | 7607.489 | 0.0   | 90.0 | 0.0 | 0.0     | 0.0       | 0.0       |
| 2   | 13.796145 | -99.207276 | 9135.519 | 0.0   | 90.0 | 0.0 | 0.0     | 0.0       | 0.0       |
| 3   | 12.451756 | -99.190534 | 9135.519 | 0.0   | 90.0 | 0.0 | 0.0     | 0.0       | 0.0       |
| 4   | 11.128367 | -99.186763 | 9135.522 | 0.0   | 90.0 | 0.0 | 0.0     | 0.0       | 0.0       |
| 5   | 13.774445 | -96.428611 | 15.0     | 0.0   | 0.0  | 0.0 | 0.0     | 0.0       | 0.0       |
| 6   | 12.428334 | -96.428056 | 15.0     | 0.0   | 0.0  | 0.0 | 0.0     | 0.0       | 0.0       |
| 7   | 11.082501 | -96.427778 | 15.0     | 0.0   | 0.0  | 0.0 | 0.0     | 0.0       | 0.0       |

Hi, I've got two questions regarding the order of the Euler angles to represent free body orientation and the NEU coordinate system to describe the location of the Antenna's aperture in the platform's coordinate system.

Is the order in which Euler angles are applied to the platform's orientation pitch, roll, then yaw?

and,

Is the placement of the antenna's aperture NEU location within the platform's coordinate system in meters? Also does this assume that the platform has a heading of zero degrees?

Rename and reorganize emanesh python module components into more logical sub-modules:

• emanesh.events -> emane.events
• emanesh.ota -> emane.ota
• emanesh -> emane.shell

Hello, I am a new user to EMANE, I recently got the framework to run on my virtual machine of Ubuntu 16.04 LTS. Ran into a few issues but managed to get the software running and went through the demonstrations. The problem is that after I start a demonstration:
$ sudo ./demo-start
and then try to open another terminal window I am presented with the error correlating to the following image where I am not able to open another window. In order to be able to open I need to restart the virtual machine again to be able to open a terminal again. Does anyone have an idea as to why this occurs? Thanks!

I'm trying to send a Location Event from a Java program using the protobufs package.
I've created and sent a multicast LocationEvent message to a 0.9.1 Emane container. I can see the message arriving at the container using tcpdump, but it doesn't do anything.

It looks like we might have to encapsulate the LocationEvent into an Event message.
Is this correct?
And do you by any chance have a sample Java program that constructs and sends a Location Event?

Thanks.
Larry Bressler

The dAltitudeRadians_ member variable of EMANE::Position is unused (and uninitialized) and can probably be removed.

Removing it would avoid some uninitialized warnings.

The attached patch is a possible fix.
position.h.patch.txt

Replace distutils bdist_rpm and bdist_deb (stdeb) package building rules with an install rule and top level rpm/deb package support for emane python components.

In trying to run the tutorial 0 level 0 I get the following responses:

root@cedardrome:/home/m/emane-tutorial/0# ls
bypassmac.xml eventservice.xml NO-node-gpsd
bypassnem.xml gpsdlocationagent1.xml NO-node-routing
bypassphy.xml gpsdlocationagent2.xml persist
demo-start Makefile platform1.xml
demo-stop NO-host-emaneeventservice platform2.xml
eelgenerator.xml NO-node-emane routing1.conf
eventdaemon1.xml NO-node-emaneeventd routing2.conf
eventdaemon2.xml NO-node-emanetransportd transvirtual.xml

root@cedardrome:/home/m/emane-tutorial/0# ./demo-start
Creating bridge: emanenode0
kernel.sched_rt_runtime_us = -1
Starting lxc instance: node-1
Starting lxc instance: node-2
root@cedardrome:/home/m/emane-tutorial/0#

The demo-start script terminates immedaitely.

The log file for node 1 is

lxc-execute 1450896658.716 ERROR    lxc_sync - sync.c:__sync_wake:62 - sync wake failure : Broken pipe
lxc-execute 1450896658.716 ERROR    lxc_start - start.c:__lxc_start:1121 - failed to spawn 'node-1'

The log file for node 2 is the same, excepting that it notes node-2 not node-1

Reported via email by David Ward:

Fixed a bug in the 802.11 model which prevented RTS/CTS from ever being used. The old version tried to access a variable which had been moved, causing it to always return 0.

Developed by: Chris Pollard

diff --git a/src/models/mac/ieee80211abg/maclayer.cc b/src/models/mac/ieee80211abg/maclayer.cc
index bf5a18f..d743a29 100644
--- a/src/models/mac/ieee80211abg/maclayer.cc
+++ b/src/models/mac/ieee80211abg/maclayer.cc
@@ -1161,6 +1161,7 @@ EMANE::Models::IEEE80211ABG::MACLayer::processDownstreamPacket(DownstreamPacket
   std::uint8_t u8Retries{isBroadcast(pktInfo.getDestination()) ?
       std::uint8_t{} : macConfig_.getRetryLimit(u8Category)};

+  // this moves pkt, making it invalid, use entry.pkt_ from now on
   DownstreamQueueEntry entry{pkt, 
       timeNow, 
       macConfig_.getTxOpMicroseconds(u8Category), 
@@ -1168,7 +1169,7 @@ EMANE::Models::IEEE80211ABG::MACLayer::processDownstreamPacket(DownstreamPacket
       u8Retries};

   // check rts cts enable
-  if((macConfig_.getRtsThreshold() != 0) &&(macConfig_.getRtsThreshold() <= pkt.length()))
+  if((macConfig_.getRtsThreshold() != 0) &&(macConfig_.getRtsThreshold() <= entry.pkt_.length()))
     {
       // set rts cts flag
       entry.bRtsCtsEnable_ = true;

Hi,

My use case requires the ability to update the frequency a NEM communicates on throughout emulation of the network. I see that on the PHY layer, frequency is marked as Parameter not running state modifiable, which makes sense.

The EMANE User Manual from 0.8.1 states that "The Tx Control API provides the MAC Layer with the ability to override default PHY Layer configuration for transmit power, message duration, transmit frequency and antenna pointing as required." (Page 69) This Control API is mentioned throughout the manual, but I don't see anything about how to use it. I've checked all occurrences in the document of 'Control API' to no avail. Maybe I am missing something?

The closest I've found is the transmissioncontrolmap parameter for the RF Pipe MAC Layer, which says is "Defines the data rate, frequency, and power level to be used by the PHY Layer for all transmissions to a specified node." (Page 88). However, this appears to be a deprecated parameter - it is not present in the newest release.

I realize that the User Manual is from 0.8.1 and is not up to date, and have done a fairly exhaustive search of the 'newer documentation' linked on the EMANE Home Page (which is the GitHub hosted Wiki) but can't seem to find anything about the Control API or the transmissioncontrolmap parameter.

Has this feature been deprecated? Is frequency of a NEM completely static for the runtime of the emulation now?

Any help is greatly appreciated!!

Reported by @cSchubes.

When I try to build the develop branch it is failing with

In file included from nembuilder.cc:35:0:
../../include/emane/application/nembuilder.h:255:44: fatal error: emane/application/nembuilder.inl: No such file or directory
compilation terminated

Reported via email by Thomas Goff:

diff --git a/src/emanesh/emanesh/emaneshell.py b/src/emanesh/emanesh/emaneshell.py
index 79f3bd9..59d51c4 100644
--- a/src/emanesh/emanesh/emaneshell.py
+++ b/src/emanesh/emanesh/emaneshell.py
@@ -674,7 +674,7 @@ class EMANEShell(cmd.Cmd):
                <nem>         ::=  [1-9] | [1-9][0-9]+
                <expressions> ::=  <expression> | <expression> <expressions>
                <expression>  ::= <name>'='<values>
-               <name>        ::= [A-Za-z0-9]+
+               <name>        ::= [.A-Za-z0-9]+
                <values>      ::= <value> | <value>','<values>
                <value>       ::= value-string

@@ -751,7 +751,7 @@ class EMANEShell(cmd.Cmd):
             updates = []
             if len(args) > index:
                 for expression in args[index:]:
-                    m = re.match('^([0-9A-Za-z]+)=(.+)', expression)
+                    m = re.match('^([.0-9A-Za-z]+)=(.+)', expression)

                     def toBool(val):
                         val = val.lower()

Modify UpstreamPacket and DownstreamPacket to use a reference counted shared data store for packet data.

From emane-users mailing list: [emane-users] Feedback on the "Comm Effect Model" wiki docs:

errors from the XML parser are currently being suppressed:

--- filterreader.cc, line 295

if(!(pDoc = xmlCtxtReadFile(pContext,
pzFilename,
0,
XML_PARSE_DTDVALID|XML_PARSE_NOERROR)))

I would kindly suggest removing that flag ;-)

Reported-by: Jonathan Kirchhoff

The TDMA model does not cancel its transmit timer on stop. This leads to a race condition during emulator shutdown where it is potentially possible for a callback to execute and try to use objects that have already been destroyed.

diff --git a/src/models/mac/tdma/basemodelimpl.cc b/src/models/mac/tdma/basemodelimpl.cc
index 1e065bd..0511dfa 100644
--- a/src/models/mac/tdma/basemodelimpl.cc
+++ b/src/models/mac/tdma/basemodelimpl.cc
@@ -397,6 +397,12 @@ EMANE::Models::TDMA::BaseModel::Implementation::stop()
                           id_,
                           __func__);
 
+  if(transmitTimedEventId_)
+    {
+      pPlatformService_->timerService().cancelTimedEvent(transmitTimedEventId_);
+      transmitTimedEventId_ = 0;
+    }
+
   // check flow control enabled
   if(bFlowControlEnable_)
     {

This issue only affects shutdown.

Add a check to TDMA model upstream processing to drop a packet that spans more than one slot.

The SpectrumMonitor time sync threshold is only applied to time in the past, not time in the future. The below patch adds the required logic:

diff --git a/src/libemane/spectrummonitor.cc b/src/libemane/spectrummonitor.cc
index 27f5d2b..ffd445e 100644
--- a/src/libemane/spectrummonitor.cc
+++ b/src/libemane/spectrummonitor.cc
@@ -133,7 +133,7 @@ EMANE::SpectrumMonitor::update(const TimePoint & now,
   // validate txTime in case of time sync issues
   auto validTxTime = txTime;

-  if(txTime > now || now - txTime > timeSyncThreshold_)
+  if(txTime > now + timeSyncThreshold_ || now - txTime > timeSyncThreshold_)
     {
       validTxTime = now;
     }

Reported-by: Leonid Veytser

Buffer overflow occurs during a memcpy when creating an EMANE::INETAddr from an IPv6 address due to using an incorrect sockaddr type:

diff --git a/src/libemane/inetaddr.cc b/src/libemane/inetaddr.cc
index 890e4c6..daba64d 100644
--- a/src/libemane/inetaddr.cc
+++ b/src/libemane/inetaddr.cc
@@ -80,7 +80,7 @@ public:
   }

   Implementation(const sockaddr_in6 & sockaddr):
-    pSockAddr_{reinterpret_cast<struct sockaddr*>(new sockaddr_in)},
+    pSockAddr_{reinterpret_cast<struct sockaddr*>(new sockaddr_in6)},
     length_{sizeof(sockaddr_in6)},
     iFamily_{AF_INET6},
     u16Port_{}

From emane-users mailing list: [emane-users] Feedback on the "Comm Effect Model" wiki docs:

Another thing that confused me was the explanation of the “filterfile” parameter, which says: “Defines the absolute URI of the…”, although a relative path such as “myfilter.xml” is fine as well.

Reported-by: Jonathan Kirchhoff

ControlPortService is not closing sockets properly on a client connection close.

Note: ControlPortSession::process() returns a non-zero value to indicate the session should be closed.

diff --git a/src/libemane/controlportservice.cc b/src/libemane/controlportservice.cc
index 927381c..b0eff8f 100644
--- a/src/libemane/controlportservice.cc
+++ b/src/libemane/controlportservice.cc
@@ -156,6 +156,7 @@ void EMANE::ControlPort::Service::process()
               // process the session data
               if(iter->second->process(iter->first))
                 {
+                  ::close(iter->first);
                   sessionMap.erase(iter++);
                 }
               else
@@ -173,6 +174,5 @@ void EMANE::ControlPort::Service::process()
   for(const auto & entry : sessionMap)
     {
       ::close(entry.first);
-      //delete entry.second;
     }
 }

The emanesh.ControlPortClient does not close its backend socket on stop(). Setting the backend socket linger to 0 prevents connections waiting in TIME_WAIT. This is useful when large numbers of short lived ControlPortClient connections are established with repeated calls to emanesh.

diff --git a/src/emanesh/emanesh/controlportclient.py b/src/emanesh/emanesh/controlportclient.py
index 352043b..0aa00a8 100644
--- a/src/emanesh/emanesh/controlportclient.py
+++ b/src/emanesh/emanesh/controlportclient.py
@@ -150,6 +150,11 @@ class ControlPortClient:
         except:
             raise ControlPortException("unable to connect to %s:%d" % (hostname,port),True)

+        # set socket linger to 0
+        self._sock.setsockopt(socket.SOL_SOCKET,
+                              socket.SO_LINGER,
+                              struct.pack('ii', 1,0))
+
         self._eventMap = {}
         self._responseMap = {}
         self._sequence = 0
@@ -164,6 +169,7 @@ class ControlPortClient:
     def stop(self):
         os.write(self._write,"\n")
         self._thread.join()
+        self._sock.close()

     def getManifest(self):
         request = remotecontrolportapi_pb2.Request()

We are transitioning from an NRL CORE-based environment -- where each node has its own local emane process -- to our own docker-based environment. In this environment, we were hoping to allow for the single-process EMANE approach showcased in demo 2. We used such a configuration a few years ago -- it was nice because it allowed for higher throughput link calculations (could use a GPU to better "batch" computation).

The only issue I see with this approach is (at least it seems) its not possible to dynamically create or destroy NEMs after the EMANE process initializes. Does this functionality exist? If not, would it be difficult to add?

Commit b88fa0a added support for sending and receiving OTA messages larger than 65535 bytes, but the length processing of downstream and upstream packets did not change.

The attached patch allows sending and receiving downstream and upstream packets that are larger than 65535 bytes.
emane-downstream-upstream-packet-length.patch.txt

Modifications introduced in ec89ef5 leads to INSTALL being overwritten when run.

[me@host emane]$ head INSTALL 
Build
=====

 # ./autogen.sh && ./configure && make

For information on configuration options see:

 # ./configure --help

Install
[me@host emane]$ ./autogen.sh -c
[me@host emane]$ ./autogen.sh
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:53: installing './compile'
configure.ac:53: installing './config.guess'
configure.ac:53: installing './config.sub'
configure.ac:41: installing './install-sh'
configure.ac:41: installing './missing'
src/agents/gpsdlocation/Makefile.am: installing './depcomp'
[me@host emane]$ head INSTALL
Installation Instructions
*************************

Copyright (C) 1994-1996, 1999-2002, 2004-2013 Free Software Foundation,
Inc.

   Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.  This file is offered as-is,
without warranty of any kind.

In src/emanesh/emanesh/events/eventservice.py, EventService.nextEvent() does not currently break when EventService.breakloop() is called. This is different than how EventService.loop() behaves and makes it difficult to gracefully interrupt a call to nextEvent().

One option could be something like the following patch (based on the develop branch), which also removes the unused 'running' variable:

--- a/src/emanesh/emanesh/events/eventservice.py
+++ b/src/emanesh/emanesh/events/eventservice.py
@@ -238,7 +238,6 @@ class EventService:
                     data,_ = self._socket.recvfrom(65535)

                     if not len(data):
-                        running = False
                         break

                     (length,) = struct.unpack_from("!H",data)
@@ -257,11 +256,13 @@ class EventService:
                                 event.sequenceNumber,
                                 tuple(events))

+                elif fd is self._readFd:
+                    break
+
                 elif fd is self._socketOTA:
                     data,_ = self._socketOTA.recvfrom(65535)

                     if not len(data):
-                        running = False
                         break

                     (headerLength,) = struct.unpack_from("!H",data)
@@ -283,6 +284,7 @@ class EventService:
                             otaHeader.sequenceNumber,
                             tuple(events))

+            return (None, None, tuple(events))

     def subscribe(self,eventId,callback):
         self._lock.acquire()

Some makeException statements missing corresponding throw in:

• src/libemane/controlportservice.cc
• src/libemane/datagramsocket.cc
• src/libemane/gainmanager.cc
• src/libemane/multicastsocket.cc

When providing radio transmit frequency or frequency of interest parameter values for a certain range of values (e..g 0.8G, 0.9G), EMANE does not accept the configuration. If the leading zero is omitted (e.g., using ".9G" instead of "0.9G"), EMANE accepts the configuration and works properly.

Reported via email by Brian Adamson.

Rules missing to uninstall files installed via distutils.core.setup.

Reported on mailing list by Hasnain Lakhani:

Our tests started failing on Friday. We use EMANE 0.7.4.

Debugging showed that EMANE uses external parameters entities in the XML
files; specifically the DTD links (I believe). We were getting errors on
files that worked perfectly fine previously. The errors would be of the
following form:

validity error : No declaration for element param
validity error : No declaration for attribute name of element param
validity error : No declaration for attribute value of element param

libxml2 had a security update on Thursday:

libxml2 (2.7.8.dfsg-5.1ubuntu4.7) precise-security; urgency=medium

• SECURITY UPDATE: resource exhaustion via external parameter entities
  • parser.c: do not fetch external parameter entities.
  • https://git.gnome.org/browse/libxml2/commit/?id=9cd1c3cfbd32655d60572c0a413e017260c854df
  • CVE-2014-0191
    -- Marc Deslauriers Thu, 08 May 2014 14:30:38 -0400

After downgrading libxml down to 2.7.8.dfsg-5.1ubuntu4.6 we noticed that
emanegentransportxml works fine again.

This behaviour should be fixed so that it works again with the latest
libxml2. I'll be happy to provide further information if needed

Additional capability to have emulator level statistics and statistic tables with statistics to track the number of sent and received OTA and Event channel messages.

Reported via email by Leonid Veytser:

There appears to be a bug in setting a boolean runtime modifiable configuration to value of False. Here's a small example of trying to set "enablepromiscuousmode" to False in RFPipe via emanesh:

[emanesh (localhost:47000)] ## get config 1 mac enablepromiscuousmode
nem 1 mac enablepromiscuousmode = False
[emanesh (localhost:47000)] ## set config 1 mac enablepromiscuousmode=True
nem 1 mac configuration updated
[emanesh (localhost:47000)] ## get config 1 mac enablepromiscuousmode
nem 1 mac enablepromiscuousmode = True
[emanesh (localhost:47000)] ## set config 1 mac enablepromiscuousmode=False
nem 1 mac configuration updated
[emanesh (localhost:47000)] ## get config 1 mac enablepromiscuousmode
nem 1 mac enablepromiscuousmode = True

As you can see, setting the value to True appears to be working but setting it back to False doesn't.

Add arbitrary file descriptor processing support to the NEM layer functor queue thread procedure.