Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call-Home Failure with ncclient #447

Open
sjd-xlnx opened this issue Nov 17, 2023 · 1 comment
Open

Call-Home Failure with ncclient #447

sjd-xlnx opened this issue Nov 17, 2023 · 1 comment
Labels
is:enhancement Request for adding new feature or enahncing functionality.

Comments

@sjd-xlnx
Copy link

Hello,

I'm using netopeer2-server configured for call-home. The client is ncclient running on Windows PC. I'm having issues sometimes - about 25% of the time - the connection fails on the client side. The error message is [ERROR]: ncclient.transport.ssh> Exception (client): Error reading SSH protocol banner[WinError 10054] An existing connection was forcibly closed by the remote host.

It seems that the Client accepts the socket, but maybe a bit "too late" and the server releases it (I see a RST in the TCP message)?

I know that the netopeer2-server repeatedly tries 3 times each client, and also cycles through the clients defined in ietf-netconf-server. I see that in code there is #define NC_CH_ENDPT_BACKOFF_WAIT @CALL_HOME_BACKOFF_WAIT@ (which is set to 2 seconds), and NC_CH_CONNECT_TIMEOUT which is set to 500ms. But there are also TCP retries in-play.

Anyway, I wondered whether this cycle was too "aggressive" and we should wait longer. (Although, even with a longer timeout - there's still the chance we could connect the socket right at the end). Are the above values for call-home retries from a NETCONF standard or proprietary? I couldn't find any standard values for this.

By the way, I don't have any issue with netopeer2-cli as the client, or if I use ncclient on Linux. The problem seems to be specific to Windows socket handling.

I'm going to ask on ncclient GitHub too but thought you might have some opinion or advice on the issue.

Thanks.

@michalvasko
Copy link
Member

Anyway, I wondered whether this cycle was too "aggressive" and we should wait longer. (Although, even with a longer timeout - there's still the chance we could connect the socket right at the end). Are the above values for call-home retries from a NETCONF standard or proprietary? I couldn't find any standard values for this.

They are proprietary, no standardized (from ietf-netconf-server) timeout is a fixed value. You are free to experiment with different values and if you verify that a specific timeout fixes this problem, I will have nothing against merging the change.

@michalvasko michalvasko added the is:enhancement Request for adding new feature or enahncing functionality. label Nov 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
is:enhancement Request for adding new feature or enahncing functionality.
Projects
None yet
Development

No branches or pull requests

2 participants