Hi, I have a state machine which does the following:
libssh2_channel_open() libssh2_channel_exec() libssh2_channel_send_eof() libssh2_channel_wait_eof() libssh2_channel_close() libssh2_channel_read() libssh2_channel_wait_closed() libssh2_channel_free() In the case thet libssh2_channel_wait_closed() returns LIBSSH2_ERROR_INVAL, the code goes back to the READ state and schedules more reads until WAIT_CLOSED returns 0. This will cause the wait_closed() operation to finally return 0 (rather then -34 or -37). The reason for the enter back into the read state is that libssh2_channel_wait_closed() checks for eof, and even though the code has already checked and passed the EOF state, further packets appear to be sent on the channel. This causes the internal code to mask the EOF state which can only be corrected by reading packets. This seems like some kind of odd race condition to me, but fwiw I hope others find this state machine helpful if implementing nonblocking ssh connecting software of their own: https://github.com/pacemaker-cloud/pacemaker-cloud/blob/master/src/trans_ssh.c Regards -steve _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel