kill-session RPC fails during reset when targeting same NETCONF session (netopeer2/sysrepo)

[piyush897]

Hi @michalvasko ,

I am working on a NETCONF-based system using "netopeer2-server + sysrepo", and I have a question regarding the correct handling of client disconnection from server side during a reset operation.

We have implemented a /o-ran-operations:reset RPC in our application.

The expected behavior during reset is:

• Process reset request
• Disconnect NETCONF client
• Perform system reboot

Current Implementation
1. Reset callback
uint32_t clientId = getClientIdentificator(session);

// async execution after RPC response
std::thread([clientId]() {
    std::this_thread::sleep_for(std::chrono::milliseconds(500));
    disconnectClient(s_resetSession, clientId);
}).detach();

applicationPtr->reset();

2. Client identification
static uint32_t getClientIdentificator(sr_session_ctx_t *session)
{
    const uint32_t *data = nullptr;
    sr_session_get_orig_data(session, 0, NULL, (const void **)&data);
    return data ? *data : 0;
}

3. kill-session RPC
sr_rpc_send_tree(s_resetSession, rpc, 0, &reply);

 `s_resetSession` is a separate sysrepo session created via:

sr_session_start(conn, SR_DS_RUNNING, &s_resetSession);

4. Observed Behavior
   Logs:
   Reset triggered by session-id: 1
   ASYNC: Woke up, attempting kill-session for clientId=1
   Processing "/ietf-netconf:kill-session"
   Failed processing of "rpc"
   disconnectClient failed

5. What We Verified
   We tried multiple approaches:

• Using a separate sysrepo session (s_resetSession)
• Executing kill-session asynchronously (separate thread)
• Adding delay after RPC response
• Ensuring RPC response (<ok/>) is already sent
• Verifying different session pointers and connections

6. Despite all this, kill-session consistently fails when targeting the same session that triggered the reset.

7. Key Question
   Why does kill-session:

• Fail when called during/after reset RPC (even asynchronously)

8. Hypothesis
   It appears that:

• netopeer2 associates the kill-session request with the original NETCONF session context
• When session-id == caller session, it is treated as a self-termination attempt
• Which is rejected per NETCONF behavior

What We Want to Clarify

1. Is this behavior expected per NETCONF protocol or specific to netopeer2?

2. Is there a supported way to:

   • Disconnect the initiating session from server after sending RPC response?

3. Does netopeer2 internally prevent killing the same session regardless of execution context?

4. What is the recommended approach for handling client disconnection from server side during reset?

Current Practical Approach
We are currently relying on:

• Reset → system reboot → TCP/SSH disconnect
  But we wanted to confirm if an explicit disconnect via NETCONF server is expected/possible.

[michalvasko]

Just use close-session instead of kill-session to terminate your own NETCONF session.