Edit EMANE Properties of CoreNode in running simulation

[derkin123]

I am communicating with the core-daemon using c++ generated responses/requests from the given protos. I am able to add CoreNode and EmaneNet nodes after the simulation has started and link them together. I want to be able to add the CoreNodes using the emane_ieee80211abg model and edit certain parameters on their config, like the txpower for example.

When creating the CoreNodes, using a AddNodeRequest, that will link to the EmaneNet, I am editing the Node's emane.NodeEmaneConfig emane_configs field to have the parameters I want. This seems to work partially because when I retrieve this node by using a GetSessionRequest and grab the session's nodes, this node has its NodeEmaneConfig parameters listed as they were set, but this is not reflected in the core-gui when I look at the emane parameters under the node I edited.

Is this the proper way to edit the emane properties of a CoreNode? I've also tried sending SetEmaneModelConfigRequests for the CoreNode but this results in an error about the emane model not existing. I'm guessing this error results because this function is meant for a EmaneNet node that has a model dict of possible model types where the CoreNode won't have this, but I'm not 100% sure.

I would appreciate advice/guidance on how to add a node to a running simulation that has custom emane configuration settings.

[bharnden]

Some improvements related to this are now on develop. Previously emane was not possible at all to add at runtime. A bit ago functionality was added to support the possibility.

For the latest release, as long as you configure the emane config using the model name and the exact interface ID, it can show. It will require you to rejoin the session in the GUI for it to populate properly.

The updates on develop will not require rejoining.

There is also the aspect of the services on a node needing to be restarted, since some service config files that get generated are based upon the links/interfaces present at the time. You may also need to move one/all nodes to achieve emane location events for comms to be updated within EMANE.

[bharnden]

They will reside inside the directory of the MDR nodes or nodes running EMANE, they are the files fed to it when starting the process.

[bharnden]

Is this 2 separate examples combined? The current intent is to not add and create nodes/links and then StartSession, you would build out a Session protobuf object and then start the session with that, containing everything needed.

It may be related to you combining two different things at once to try and start the scenario. Since Start session would clear out everything before hand.

[derkin123]

Sorry I was not putting much thought into the order of the code chunks above. My current workflow is to create a session then start that session then add nodes then add links. The code above supports adding nodes before starting the session but my current use case is to add nodes and links after starting the session

[bharnden]

1. create or join session
2. build out the session object returned by this, how you like
3. then StartSession, which would clear and reset anything prior data and use the session data provided at this point

You may also be playing with what works and trying to configure the emane node properties in two places, but you could start with just one, to avoid the duality. There are layers to how the configs could work.

• configuration to the emane net node would apply to all nodes connected to it
• configuration to a node without interface id, would apply to all emane model usages on that node
• configuration to a node with interface id, would apply to that specific interface only

at least that should be the case.

[derkin123]

So of the config options you provided:

1. configuration to the emane net node would apply to all nodes connected to it

So basically if I have an emane net node and I give it a NodeEmaneConfig, then whenever I link a CoreNode to the EmaneNetNode the CoreNode should automatically get the same NodeEmaneConfig assigned to it?

2. configuration to a node without interface id, would apply to all emane model usages on that node

In this case if I assigned a NodeEmaneConfig to a MDR CoreNode but provided no interface ID, then all emane connections on the CoreNode would use the NodeEmaneConfig provided

3. configuration to a node with interface id, would apply to that specific interface only

In this last case I believe you are saying I'm able to assign a NodeEmaneConfig for each interface a MDR CoreNode is apart, so if a CoreNode had 3 emane links, then each link could have its own NodeEmaneConfig based off of the specific interface id provided

To me it sounds like you are right that I'm trying to assign this in multiple places and that may be an issue. I will try method 1 as its the simplest (assuming I understand you correctly) and see if through that I can get the core-gui to populate the correct config

[derkin123]

Okay so I have some updates:

I tested the first method you offered and that seems to work somewhat. My CoreNodes linked to an EmaneNet with an edited config also inherit the config changes (I see this change reflected in their phy.xml files), I still haven't been able to get the config change to populate in the gui but thats not very important.

The problem is that emane doesn't seem to be reacting to these changes even after resetting all services on the nodes and moving the nodes like you mentioned. There is no connection being made between two emane nodes when I add them after starting the session. These nodes do connect if I add them both before starting the session under the same conditions so I know its not a problem of how close they are/the power between them.

[bharnden]

Without being able to inspect anything, its hard to say. You would have to identify if the desired services (processes) are running on the nodes as you create them, using the right configurations, possibly even inspecting the emane instances using emanesh to see what is being taken in.

That's about the best advice I can give at this point.

[bharnden]

As a quick and dirty test case, albeit using the python based client as an example.

• Create a session with just the EMANE net ID=1, using 80211
• run the following script

from core.api.grpc.client import CoreGrpcClient
from core.api.grpc.wrappers import ConfigOption, Interface, Link, Node, Position
from core.emane.models.ieee80211abg import EmaneIeee80211abgModel

client = CoreGrpcClient()
client.connect()

session_id = 1
emane_net_id = 1

# add nodes
node2 = Node(
    id=2,
    name="Node2",
    model="mdr",
    emane_model_configs={
        (EmaneIeee80211abgModel.name, 0): {
            "txpower": ConfigOption(name="txpower", value="1.0")
        }
    },
    position=Position(220, 200),
)
client.add_node(session_id=session_id, node=node2)
node3 = Node(
    id=3,
    name="Node3",
    model="mdr",
    emane_model_configs={
        (EmaneIeee80211abgModel.name, 0): {
            "txpower": ConfigOption(name="txpower", value="1.0")
        }
    },
    position=Position(200, 200),
)
client.add_node(session_id=session_id, node=node3)

# add links
iface1 = Interface(id=0, ip4="10.0.0.2", ip4_mask=32)
iface2 = Interface(id=1)
link = Link(node1_id=node2.id, node2_id=emane_net_id, iface1=iface1, iface2=iface2)
client.add_link(session_id, link)
# add link
iface1 = Interface(id=0, ip4="10.0.0.3", ip4_mask=32)
iface2 = Interface(id=1)
link = Link(node1_id=node3.id, node2_id=emane_net_id, iface1=iface1, iface2=iface2)
client.add_link(session_id, link)

• can't ping
• go to Node2 and restart OSPF MDR, then Zebra services, then the same for Node3
• move Node2, then Node3
• now I can ping

[bharnden]

Here is an updated example where I went ahead and scripted the above:

from core.api.grpc.client import CoreGrpcClient
from core.api.grpc.wrappers import ConfigOption, Interface, Link, Node, Position, \
    ServiceAction
from core.emane.models.ieee80211abg import EmaneIeee80211abgModel

client = CoreGrpcClient()
client.connect()

session_id = 1
emane_net_id = 1
position = Position(200, 200)
emane_config = {
    (EmaneIeee80211abgModel.name, 0): {
        "txpower": ConfigOption(name="txpower", value="1.0")
    }
}

# add nodes
node2 = Node(
    id=2,
    name="Node2",
    model="mdr",
    emane_model_configs=emane_config,
    position=position,
)
client.add_node(session_id=session_id, node=node2)
node3 = Node(
    id=3,
    name="Node3",
    model="mdr",
    emane_model_configs=emane_config,
    position=position,
)
client.add_node(session_id=session_id, node=node3)

# add links
iface1 = Interface(id=0, ip4="10.0.0.2", ip4_mask=32)
iface2 = Interface(id=1)
link = Link(node1_id=node2.id, node2_id=emane_net_id, iface1=iface1, iface2=iface2)
client.add_link(session_id, link)
iface1 = Interface(id=0, ip4="10.0.0.3", ip4_mask=32)
iface2 = Interface(id=1)
link = Link(node1_id=node3.id, node2_id=emane_net_id, iface1=iface1, iface2=iface2)
client.add_link(session_id, link)

# restart node services
client.config_service_action(session_id, node2.id, "OSPFv3MDR", ServiceAction.RESTART)
client.config_service_action(session_id, node2.id, "zebra", ServiceAction.RESTART)
client.config_service_action(session_id, node3.id, "OSPFv3MDR", ServiceAction.RESTART)
client.config_service_action(session_id, node3.id, "zebra", ServiceAction.RESTART)

# move nodes
position = Position(x=position.x + 1, y=position.y + 1)
client.move_node(session_id, node2.id, position=position)
client.move_node(session_id, node3.id, position=position)

[derkin123]

It does sound the like issue is on my side then, I really appreciate the demo. I went to try and run this with the following:

/opt/core/venv/bin/python3.9 test.py

but it threw back error:

Traceback (most recent call last):
  File "/home/user/Documents/test.py", line 26, in <module>
    client.add_node(session_id=session_id, node=node2)
  File "/home/user/Documents/afsim/core/daemon/core/api/grpc/client.py", line 426, in add_node
    response = self.stub.AddNode(request)
  File "/opt/core/venv/lib/python3.9/site-packages/grpc/_channel.py", line 946, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/opt/core/venv/lib/python3.9/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking
    raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.NOT_FOUND
	details = "session 1 not found"
	debug_error_string = "UNKNOWN:Error received from peer ipv4:127.0.0.1:50051 {grpc_message:"session 1 not found", grpc_status:5, created_time:"2022-12-12T14:09:18.29460941-05:00"}"

[bharnden]

Ass seen in the error, session 1 does not exist.

As I noted, I created a simple session in the GUI with an EMANE NET node, the session ID in this case is 1 and the EMANE NET ID is 1.

So the session id = 1, does not exist and it is complaining.

[derkin123]

Sorry I missed some of your original instructions which caused my confusion with the error.

I've been working on looking into this more, I want to try and use the emanesh command like you mentioned earlier but when trying to use emanesh localhost on a simple simulation I setup and run from the gui I get the error:
unable to connect to localhost:47000

I get this when running from a regular terminal or the one spawned from double clicking a CoreNode

[bharnden]

Due to the possibility of running multiple EMANE instances on a single node, they currently use a crude mechanism for isolating the ports used to avoid conflicts. You would have to specify the port being used, since it is not the default.

You can use ss -lnp to see which port the EMANE process is listening on.

[derkin123]

Update: Incorporating everything you've given me to now I am able to ping between two core nodes linked to an emane net after replicating this using the c++ message set. Thank you very much for all of your patient help!

One note is that there is no visual link made in the gui between the two core nodes, like in the python scripts you sent. I don't know if this is on purpose or something being worked on but I would definitely suggest adding this to smooth the experience.

[bharnden]

In theory the linking should work, but it only applies to a couple of the EMANE models currently and depends upon scraping data from emanesh and if it meets certain thresholds, then a link is added.

Possibly this is either not being started properly, due to how the gRPC sets things up in this case, or the threshold isnt being met. It is probably the former.