Broke out of main loop

[jfindlay]

I'm using ncclient in this stack: salt/napalm/pyjunos-eznc/ncclient/paramiko to communicate with a Juniper router. I see frequent messages like the following in the debug log coming from ncclient.transport.ssh.SSHSession.run.

Broke out of main loop, error=SessionCloseError('Unexpected session close\nIN_BUFFER: `\n<!-- session end at 2020-10-06 08:31:12 UTC -->\n`',)

Does this mean that something higher up the stack did not close the session when it should have? Can the Juniper router close the session when it thinks it is time to close or is it the responsibility of the user to close the session? The impact seems minimal because the next action taken by ncclient is to clean up the session with a close().

If my reading of the while loop is correct, the only way to exit is by #268 or by raising an exception. Is this correct or is the thread killed from outside? Also, how is it conclusive that the session has ended if there are events but no data?

[einarnn]

I'm using ncclient in this stack: salt/napalm/pyjunos-eznc/ncclient/paramiko to communicate with a Juniper router. I see frequent messages like the following in the debug log coming from ncclient.transport.ssh.SSHSession.run.

Broke out of main loop, error=SessionCloseError('Unexpected session close\nIN_BUFFER: `\n<!-- session end at 2020-10-06 08:31:12 UTC -->\n`',)

Does this mean that something higher up the stack did not close the session when it should have?

No. This error is typically received when the peer of the netconf session terminates the connection, or there is some issue with the netwoirk infrastructure between the peers.

Can the Juniper router close the session when it thinks it is time to close or is it the responsibility of the user to close the session?

Closing a session gracefully is the responsibility of the "user", or client. The router can absolutely decide to close the connection, but that would look non-graceful. It would typically result in a read event and a zero-length read, followed by raising the exception with any left-over data.

The impact seems minimal because the next action taken by ncclient is to clean up the session with a close().

Yes. Basically, any inflight messages may be lost if the connection is torn down non-gracefully.

If my reading of the while loop is correct, the only way to exit is by #268 or by raising an exception. Is this correct or is the thread killed from outside? Also, how is it conclusive that the session has ended if there are events but no data?

If data = chan.recv(BUF_SIZE) returns no data, that will be because there is a socket close, as a socket close causes a read event on a socket with no data. Unless the "closing" flag is set, this is unexpected.

Hopefully this makes sense!

[jfindlay]

Thanks @einarnn that is really helpful., but now I have a more serious error. I can switch to a new issue if requested or another forum if that is more appropriate.

As I mentioned before, I am using is salt/napalm/pyjunos-eznc/ncclient/paramiko to communicate with a Juniper router. Intermittently I am getting a pyjunos-eznc RpcTimeoutError which is a repackaging of TimeoutExpiredError from ncclient.

A NETCONF trace on the router during this transaction shows that the router responded to the RPC within a second, but I am not sure how to positively confirm the response data was received by ncclient (or paramiko). Would increasing the channel buffer size decrease the probability of this happening?

[einarnn]

Try enabling debug logging on the module ncclient.transport.ssh. That should show data as it is received.

[einarnn]

Assuming that this issue is no longer live; closing.