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

ssh.pm recv() stuck on logout #33

Open
LabRat002a opened this issue Jun 20, 2017 · 1 comment
Open

ssh.pm recv() stuck on logout #33

LabRat002a opened this issue Jun 20, 2017 · 1 comment

Comments

@LabRat002a
Copy link

Our software sometimes sends a request-logout-user command whose name also matches the active session: "$client->send_and_recv_rpc('our-name');" But the send_and_recv_rpm call never returns in that case. In older NET::NETCONF versions it caused the script to exit with an error message about losing connection, which is the desired behavior. Looking at the code, I expect it would also get stuck if the session spontaneously died for other reasons, like idle timeout.

Looking in the NET::NETCONF code, I traced this problem to 2 causes. One already appears to be addressed in #31 "adding exception handling for reads and writes". The other though is that poll() never returns when the session dies in this case. Poll() is calling libssh2_poll(), which is a deprecated function. I tried changing it to use blocking reads instead, but those weren't returning from read() even for commands that did work with non-blocking reads before.

@hatramatra
Copy link

I noticed also, that recv() never ends if ]]>]]> string it not the last string. That typically happens if the closing session reply message looks like this:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/14.1X53/junos" message-id='2'>
<ok/>
</rpc-reply>
]]>]]>
<!-- session end at 2018-09-01 19:08:23 UTC -->

In which case the condition terminating the reading loop ...

} until($resp =~ s/]]>]]>$//);

... never matches and it loops infinitely as it will never read anything again. The fix which worked for me was to use the multiline match:

--- ssh.pm.orig	2018-08-31 20:54:53.535774074 +0200
+++ ssh.pm	2018-09-01 22:33:46.234021174 +0200
@@ -126,7 +126,7 @@
         $nbytes = $chan->read($buf, 65536) || 0;
         $self->trace("Read $nbytes bytes from SSH channel: '$buf'");
         $resp .= $buf;
-    } until($resp =~ s/]]>]]>$//);
+    } until($resp =~ s/]]>]]>$//m);
     $self->trace("Received XML response '$resp'");
 
     return $resp;

Is this the right fix?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants