How to kill the netconf session from sysrepo application using session ID

[NaveenSivakmr]

Hi @michalvasko,

I am using the below packages

libnetconf2-2.1.28 libyang-2.1.30 netopeer2-2.1.49 sysrepo-2.2.36

I have an application using sysrepo API's. My requirementis like, I need to close a particular netconf client from that sysrepo application in some certain cases. I have the netconf session ID. Using this ID , is there any API support to close a netconf session from sysrepo application.

Earlier we were using the different versions of netopeer packages

libnetconf2-1.1.43 libyang-1.0.255 netopeer2-1.1.70 sysrepo-1.4.122

While using these versions it was possible to kill a netopeerclient session using sr_rpc_send function from our application . But after updating netopeer2 and supported package versions, we are unable to kill the netopeer client like we did before. While going through the netopeer2 source code we came to understanding that in the latest versions there is check to identify the source of orginating RPC and netconf RPCs are ignored based on this check if they are not send in a NETCONF session. We tried commenting out the this check in the np2srv_rpc_kill_cb in netconf.c file .But then we got the errors as below

ERR] Callback event "rpc" with ID 1 processing timed out. [WRN] Event "rpc" with ID 1 priority 0 failed (Timeout expired). [WRN] Connection with CID 1 is dead. [WRN] Recovering RPC/action "/ietf-netconf:kill-session" subscription of CID 1. [ERR] User callback failed.

I believe the errors are from sysrepo. Can you kindly suggest us a way to implement our requirement as it required for us to terminate a session if it's inactive.(Inactive is decided if a session fails to send RPC to reset the counter monitoring different netopeer client sessions.

Kindly help on this

Thanks for your time in advance

[michalvasko]

Generally, this is intentionally not possible because you should not be able to affect NETCONF sessions by any non-NETCONF mechanisms. What you can always do is create a temporary NETCONF session and then use kill-session. That will make sure all the requirements of this RPC (such as passing a NACM check) are met.

[NaveenSivakmr]

Is it possible to create a temporary netconf session within our application. If yes can you please tell us the best way to do so?

[michalvasko]

I just meant you will create it, kill the session, and terminate it. There is no special way, just connect to the locally running netopeer2-server as if you were connecting to a remote NETCONF server.

[NaveenSivakmr]

I belive the best way to create a session is using the nc_connect_unix() api since the nc_connect_ssh() will require authentication even if we are connecting to the localhost. The question that i have now is it just enough to send normal path as an arguement to the nc_connect_unix() or is socket that the netopeer server is already binded to?

[michalvasko]

Yes, you can connect via a UNIX socket if you want. To connect, you first need to set up netopeer2-server to create the socket and then you can connect to it. Using parameter -U, look at netopeer2-server -h for more details.

[NaveenSivakmr]

In sysrepo application we have created a temporary netconf_client_session using nc_connect_unix() api.We used nc_rpc_kill() api to kill the netconf_client_session and nc_send_rpc() api used to send nc_rpc_kill.

Code snippet

temp_session = nc_connect_unix(socket_path, NULL);                          
    if (temp_session == NULL) {                                                 
        PRINT(ERR, program_invocation_short_name, "Failed to create NETCONF session%s","\n");
    }                                                                           
    rpc = nc_rpc_kill(kill_sid);                                                
    if (rpc == NULL) {                                                          
        PRINT(ERR, program_invocation_short_name, "Failed to create kill session RPC%s", "\n");
    }                                                                           
    ret = nc_send_rpc(temp_session, rpc, 0, &mid);                               
    if (ret != NC_MSG_RPC) {                                                    
        PRINT(ERR, program_invocation_short_name, "Failed to send the RPC%s","\n");
    }                                                                           
    if (ret == NC_MSG_RPC) {                                                    
        PRINT(ERR, program_invocation_short_name, " to send the RPC%s","\n");   
    }                                                                           
    nc_session_set_status(temp_session, NC_STATUS_INVALID);                     
    nc_session_free(temp_session, NULL);

netopeer-client logs

> 
notification (2000-11-04T00:08:14.833625180+00:00)
netconf-session-start xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications"
 username root /username
  session-id 3 /session-id
/netconf-session-start

> 
notification (2000-11-04T00:08:15.503681660+00:00)
netconf-session-end xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications"
  username root /username
  session-id 3 /session-id
  termination-reason dropped /termination-reason 
/netconf-session-end

> status
Current NETCONF session:
  ID          : 2
  Host        : 192.168.4.46
  Port        : 830
  Transport   : SSH
  Capabilities:
    urn:ietf:params:netconf:base:1.0
    urn:ietf:params:netconf:base:1.1
    urn:ietf:params:netconf:capability:writable-running:1.0
    urn:ietf:params:netconf:capability:candidate:1.0
    urn:ietf:params:netconf:capability:confirmed-commit:1.1
    urn:ietf:params:netconf:capability:rollback-on-error:1.0
    urn:ietf:params:netconf:capability:validate:1.1
    urn:ietf:params:netconf:capability:startup:1.0
    urn:ietf:params:netconf:capability:xpath:1.0
    urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&also-supported=report-all,report-all-tagged,trim,explicit
    urn:ietf:params:netconf:capability:notification:1.0
    urn:ietf:params:netconf:capability:interleave:1.0
    urn:ietf:params:xml:ns:yang:ietf-yang-metadata?module=ietf-yang-metadata&revision=2016-08-05
    urn:ietf:params:xml:ns:yang:1?module=yang&revision=2022-06-16
    urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2013-07-15
    urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&revision=2013-07-15
    urn:ietf:params:netconf:capability:yang-library:1.1?revision=2019-01-04&content-id=1
    urn:ietf:params:xml:ns:yang:ietf-netconf-acm?module=ietf-netconf-acm&revision=2018-02-14
    urn:sysrepo:plugind?module=sysrepo-plugind&revision=2022-08-26
    urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2013-09-29&features=writable-running,candidate,confirmed-commit,rollback-on-error,validate,startup,url,xpath
    urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?module=ietf-netconf-with-defaults&revision=2011-06-01
    urn:ietf:params:xml:ns:yang:ietf-netconf-notifications?module=ietf-netconf-notifications&revision=2012-02-06
    urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&revision=2010-10-04
    urn:ietf:params:xml:ns:netmod:notification?module=nc-notifications&revision=2008-07-14
    urn:ietf:params:xml:ns:netconf:notification:1.0?module=notifications&revision=2008-07-14
    urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name?module=ietf-x509-cert-to-name&revision=2014-12-10
    urn:ietf:params:xml:ns:yang:iana-crypt-hash?module=iana-crypt-hash&revision=2014-08-06
    urn:notification_history?module=notification_history
    urn:ietf:params:xml:ns:yang:iana-if-type?module=iana-if-type&revision=2017-01-19
>

we want the session 2 to be killed but it is not getting killed.

we have tested the same for older version the intended session was killed successfully by the intermediate session.

Kindly help on this

Thanks for your time in advance

[michalvasko]

Call nc_recv_reply() after you send the RPC, the server probably returned some error.

[navneetkaurPS]

HI Michal I was able to kill-session from sysrepo application as mentioned in this thread. and then also cluent could resubscribe. However, I have two observations : -

1. netopeer2 CLI would not lose the context of the session if session is killed. Unless I perform the get operation I am unable to connect back. Even status shows valid netconf session.

LOGS of CLI: -

nc ERROR: SSH channel unexpected EOF.

listen --login ps_admin cmd_listen: Already connected to ::ffff:192.168.3.193. status Current NETCONF session: ID : 1 Host : ::ffff:192.168.3.193 Port : 36656 Transport : SSH Capabilities: urn:ietf:params:netconf:base:1.0 urn:ietf:params:netconf:base:1.1 urn:ietf:params:netconf:capability:writable-running:1.0 urn:ietf:params:netconf:capability:candidate:1.0 urn:ietf:params:netconf:capability:confirmed-commit:1.1 urn:ietf:params:netconf:capability:rollback-on-error:1.0 urn:ietf:params:netconf:capability:validate:1.1 urn:ietf:params:netconf:capability:startup:1.0 urn:ietf:params:netconf:capability:xpath:1.0 urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&also-supported=report-all,report-all-tagged,trim,explicit urn:ietf:params:netconf:capability:notification:1.0 urn:ietf:params:netconf:capability:interleave:1.0 urn:ietf:params:xml:ns:yang:ietf-yang-metadata?module=ietf-yang-metadata&revision=2016-08-05 urn:ietf:params:xml:ns:yang:1?module=yang&revision=2022-06-16 urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2013-07-15 urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&revision=2013-07-15 urn:ietf:params:netconf:capability:yang-library:1.1?revision=2019-01-04&content-id=97 urn:ietf:params:xml:ns:yang:ietf-netconf-acm?module=ietf-netconf-acm&revision=2018-02-14 urn:sysrepo:plugind?module=sysrepo-plugind&revision=2022-08-26 urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2013-09-29&features=writable-running,candidate,confirmed-commit,rollback-on-error,validate,startup,url,xpath urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?module=ietf-netconf-with-defaults&revision=2011-06-01 urn:ietf:params:xml:ns:yang:ietf-netconf-notifications?module=ietf-netconf-notifications&revision=2012-02-06 urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&revision=2010-10-04 urn:ietf:params:xml:ns:netmod:notification?module=nc-notifications&revision=2008-07-14 urn:ietf:params:xml:ns:netconf:notification:1.0?module=notifications&revision=2008-07-14 urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name?module=ietf-x509-cert-to-name&revision=2014-12-10 urn:ietf:params:xml:ns:yang:iana-crypt-hash?module=iana-crypt-hash&revision=2014-08-06 urn:ietf:params:xml:ns:yang:iana-if-type?module=iana-if-type&revision=2017-01-19 urn:ietf:params:xml:ns:yang:ietf-system?module=ietf-system&revision=2014-08-06&features=authentication get nc ERROR: Invalid session to send RPCs. cli_send_recv: Failed to send the RPC.

status Client is not connected to any NETCONF server.

listen --login psadmin Waiting 60s for an SSH Call Home connection on port 4334...

2. After closing the server application observed below logs. I hope we not see any issue of sysrepo data corruption after starting server again. What is your view on below logs.

LOGS :

libyang[1]: String "iana-hardware:power-supply" not freed from the dictionary, refcount 1 libyang[1]: String "255" not freed from the dictionary, refcount 2 libyang[1]: String "iana-if-type:l2vlan" not freed from the dictionary, refcount 4 libyang[1]: String "ps_eth2_lbm" not freed from the dictionary, refcount 1 libyang[1]: String "iana-hardware:sensor" not freed from the dictionary, refcount 1 libyang[1]: String "iana-hardware:port" not freed from the dictionary, refcount 1

[michalvasko]

1. That is expected. For the client to pick up that it's connection has been terminated there would have to be some continuous communication with the server. Since there is not, it is learned on the next occasion such as trying to send an RPC.
2. The logs mean there is a memory leak. Depending on what exactly you are doing, it may be your fault or a bug in our library.

[gr00nd]

• • [ ] https://github.com/CESNET/netopeer2/issues/1394#issuecomment-1534201565