CESNET
RPC requests for patch cannot be made over a TLS connection.
When connecting to Netopeer2 using OpenDaylight, I successfully established callhome connections via SSH PWB and TLS. I customized a Yang model, imported it into Netopeer2, and wrote data into it. Subsequently, I utilized the OpenDaylight Restconf protocol to perform GET RPC calls to retrieve the data. However, when attempting to modify the data using Patch RPC, the SSH PWB connection succeeded, whereas the TLS connection failed.
patch /rests/data/network-topology:network-topology/topology=topology-netconf/node=tlslink/yang-ext:mount/wifi:wifi-config { "wifi:wifi-config": { "ssid": "NewSSID", "subnet-mask": "255.255.255.0", "security-type": "wpa2", "ip-address": "192.168.1.101", "password": "NewPassword111" } }
When netopeer2 restarts, the data previously written by RPC will disappear. What is the reason for this
when attempting to modify the data using Patch RPC, the SSH PWB connection succeeded, whereas the TLS connection failed.
Cannot help you with this, netopeer2 does not support RESTCONF so I guess you need to contact OpenDaylight.
When netopeer2 restarts, the data previously written by RPC will disappear.
Data written by an edit-config RPC into running disappear after netopeer2 restarts? Only netopeer2 is restarted or the whole system?
Cannot help you with this, netopeer2 does not support RESTCONF so I guess you need to contact OpenDaylight.
Setting enable nacm to false will solve the problem
Data written by an
edit-configRPC intorunningdisappear after netopeer2 restarts? Only netopeer2 is restarted or the whole system?
sysrepocfg --import=running_config.xml --datastore=startup As long as the start up is not executed when writing data, it will disappear when restarting Netopeer2
sysrepocfg --import=running_config.xml --datastore=startup As long as the start up is not executed when writing data, it will disappear when restarting Netopeer2
I do not understand. If you successfully write data into startup, they will never disappear. Data in running are overwritten by startup on system restart. This is the expected behavior and you should not see anything else.
The standard does not allow edit-config directly modifying startup. But you can, for example, modify running and then call copy-config to startup.