Number of retries

Hi,

Our application defines per session the additional attributes: number of retries and the period between each retry before tearing it up the session. It means that if the connection is disconnected we will use the same session for the number of retries provisioned. If number of retries exceeds this value the session is teared. A new session will be established on the next connection.
The question is: What shall be the API between our application to inform NETCONF server on that and use this for the handshake with NETCONF Client ? do we have such API? Is there another way to configure that?

thanks
Inbal

Hi Inbal,
Not sure I completely understand what you’re asking but I thing you just want to know how to tell ConfD how to tear down the existing session. It’s simple, send the NETCONF-message (force termination).

For example:

<rpc message-id="0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <kill-session>
    <session-id>123</session-id>
  </kill-session>
</rpc>

Let me clarify the question. Configuration session is initiated by Client so its closure/termination (i.e. / )shall be done by the client. This is clear.
My concern is how client is informed on SSH parameters such as: number of sessions, number of retries before tearing existing session, t.o. between each retry .
I assume it is part of SSH capabilities . How we initiate this information? In case we modify the parameters how we inform Client ?
Please elaborate on that

The built-in SSH-server is configured in confd.conf:

/confdConfig/ssh - container element
This section defines settings which affect the behavior of the builtin SSH implementation.

/confdConfig/ssh/idleConnectionTimeout (xs:duration) [PT10M]
The maximum time that an authenticated connection to the SSH server is allowed to exist without open channels. If the timeout is reached, the SSH server closes the connection. Default is PT10M, i.e. 10 minutes. If the value is 0, there is no timeout.

/confdConfig/ssh/algorithms - container element
This section defines custom lists of algorithms to be usable with the built-in SSH implementation.

For each type of algorithm, an empty value means that all supported algorithms should be usable, and a non-empty value (a comma-separated list of algorithm names) means that the intersection of the supported algorithms and the configured algorithms should be usable.

for more information see the man-page confd.conf(5).

This information is normally not accessible for clients but it’s possible to change that by storing ConfDs config in CDB. For more information, see section 27.4.2. Storing ConfD configuration parameters in CDB in the User Guide.