Netopeer2-cli does not detect connection breakage in the background

[Krisscut]

Hi !

Versions: netopeer2-2.2.13 sysrepo-2.2.150 libnetconf2-3.0.11.devel libyang-2.1.148

I noticed a small issue with netopeer2-cli, it doesn't seems to notify(or noticed itself!) the user that the connection was terminated.

In my case, i'm connecting to netopeer2-server using the CLI, and running two RPC. At this point no error, everything is running just fine.

Then I waited for 3 min without doing anything, and went back to run the first rpc again. I also executed the "status" command before and after running the rpc. We can see that first status reports that we are connected just fine, then when the rpc is sent it fails because it actually detects that session got closed, and then the status is updated.

NOTE: The 3min is because the default idle-timeout for listen connections is 3min, defined here: https://github.com/CESNET/libnetconf2/blob/47ca0fb5f94588d112ec2bf26946948189e1c18d/modules/ietf-netconf-server%402023-12-28.yang#L455

So would it be possible to have netopeer2-cli detects when the connection got dropped and immediately report it in the console / status instead of only detecting it with the next interaction ? This would help the user understand that the problem is not actually with the command it tried to execute.

[michalvasko]

So would it be possible to have netopeer2-cli detects when the connection got dropped and immediately report it in the console / status instead of only detecting it with the next interaction ?

To my knowledge libssh does not provide any API to support this.

[Krisscut]

Aren"t these functions meant to do that ? I'm not so familiar with these but from the API description it seems they could be fitting.

https://api.libssh.org/master/group__libssh__channel.html#gab2720b44cb7f1dfe2b38ffe07c2f45c7 https://api.libssh.org/master/group__libssh__channel.html#gab535264029443d77214c0615a0788b0a

Or maybe this one: (checking for SSH_EOF or SSH_ERROR) https://api.libssh.org/master/group__libssh__channel.html#gab56c7b7959e4c23959f2989468811661

I guess when subscription is enabled the issue would be detected faster since I assume it is running some kind of thread checking for incoming message. But in my initial case no subscription was done.

[michalvasko]

I believe all those functions only check the current flags of the channel, they do not actively check whether the connection is working. I am afraid some kind of keep-alive mechanism would be required, which seems not to be supported.