Possible Bug With GRPC WLAN Add Node

[aurora-lander]

I've been doing testing with adding MDR and WLAN nodes to a session after it has been started and found that the WLAN nodes do not behave properly in version 9.0.3 when they are added after the start of the session.

When a WLAN node is added before session startup, the mobility manager's startup function will call self.set_model() which will call the lines:

self.set_model_config(node.id, model_class.name, config)
config = self.get_model_config(node.id, model_class.name)
node.setmodel(model_class, config)

however, when the WLAN node is added after session start then only the following seems to be called:

self.set_model_config(node.id, model_class.name, config)

This is called in session's add_node function (triggered by the GRPC Server's AddNode). This means that IP routes do not seem to be properly added and the WLAN config can not be edited in the core-gui, If you try to apply WLAN config change in the core-gui like this then it will throw an error:

grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.UNKNOWN
	details = "Exception calling application: no model set to update for node(wlan1)"
	debug_error_string = "UNKNOWN:Error received from peer  {created_time:"2024-01-09T10:12:47.471394577-05:00", grpc_status:2, grpc_message:"Exception calling application: no model set to update for node(wlan1)"}"

If you change session's add_node when it checks for a WLAN to read:

# setup default wlan
if isinstance(node, WlanNode):
    self.mobility.set_model_config(node.id, BasicRangeModel.name)
    #The following 2 lines were added
    config  = self.mobility.get_model_config(node.id, BasicRangeModel.name)
    node.setmodel(BasicRangeModel, config)

then ip routing will properly be added and the wlan config can be changed in the gui.

Here is a simple grpc python script to test this before and after making this change.

from core.api.grpc.client import CoreGrpcClient
from core.api.grpc.wrappers import ConfigOption, Interface, Link, Node, NodeType, Position, ServiceAction
from core.location.mobility import BasicRangeModel

core = CoreGrpcClient()
core.connect()

session = core.create_session()
core.start_session(session)

position1 = Position(500, 200)
position2 = Position(500, 400)
positionWLAN = Position(100, 100)

#Create MDR Nodes
n1 = Node(id=1, name="n1", model="mdr", position=position1)
n2 = Node(id=2, name="n2", model="mdr", position=position2)

#Create WLAN Node
wlan1 = Node(id=3, name="wlan1", type=NodeType.WIRELESS_LAN, position = positionWLAN)
wlan1.set_wlan(
    {
        "range": "280",
        "bandwidth": "55000000",
        "delay": "6000",
        "jitter": "5",
        "error": "5",
    }
)

#Add Nodes
core.add_node(session_id=session.id, node=n1)
core.add_node(session_id=session.id, node=n2)
core.add_node(session_id=session.id, node=wlan1)

#N1 to wlan1
iface1 = Interface(id=0, ip4="10.0.0.1", ip4_mask=32)
iface2 = Interface(id=1)
link = Link(node1_id=n1.id, node2_id=wlan1.id, iface1=iface1, iface2=iface2)
core.add_link(session_id=session.id, link=link)

#N2 to wlan1
iface1 = Interface(id=0, ip4="10.0.0.2", ip4_mask=32)
iface2 = Interface(id=1)
link = Link(node1_id=n2.id, node2_id=wlan1.id, iface1=iface1, iface2=iface2)
core.add_link(session_id=session.id, link=link)

# restart node services to ensure ip routing
core.config_service_action(session.id, n1.id, "OSPFv3MDR", ServiceAction.RESTART)
core.config_service_action(session.id, n1.id, "zebra", ServiceAction.RESTART)
core.config_service_action(session.id, n2.id, "OSPFv3MDR", ServiceAction.RESTART)
core.config_service_action(session.id, n2.id, "zebra", ServiceAction.RESTART)

Please let me know if this is actually a bug and not just a script issue on my end.

[bharnden]

This would look to be exactly as you stated. Truth is, even though there has been support to try and help handle things dynamically, after start. There are a lot of things that do not really work out that way. In particular functionality related to services and the need to restart them, as you have in this script. But some of the basic setup should at least be, being done. Dynamically adding nodes after startup is also not used very much, so these things will often not be seen, for the most part.

This may be one spot that could use a little cleanup as well, thanks for pointing this out.

[bharnden]

This has been fixed on develop, along with many other changes.