libssh2_channel_exec may return -1 when using non-blocking sockets

[awaeag]

When using non-blocking sockets, libssh2_channel_exec may return -1, and the channel becomes dead.
I fixed the issue by modifying the function _libssh2_packet_requirev in packet.c in libssh2 sources:
line 1393:
old code:

        if(strchr((char *) packet_types, ret)) {
            /* Be lazy, let packet_ask pull it out of the brigade */
            int ret = _libssh2_packet_askv(session, packet_types, data,
                                        data_len, match_ofs, match_buf,
                                        match_len);
            state->start = 0;
            return ret;
        }
    }

new code:

        if(strchr((char *) packet_types, ret)) {
            /* Be lazy, let packet_ask pull it out of the brigade */
            if (_libssh2_packet_askv(session, packet_types, data,
                                        data_len, match_ofs, match_buf,
                                        match_len)) {
                return LIBSSH2_ERROR_EAGAIN;
            }
            else {
                state->start = 0;
                return 0;
            }
        }
    }

I'm no libssh2 developer, so maybe I do not have the whole picture. But this fixed my problem.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rmsh1216]

The _libssh2_packet_askv is used to check whether there are expected messages among the messages receive from the peer.
Before that, the local has successfully receive messages from the peer by calling _libssh2_transport_read. If the local does not receive messages from the peer due to some unkown reasons, the local will try again.
When the expected message is not received, this means that the peer do not send message according to the SSH protocol (please see rfc4250 to rfc4254). In this case, an error should be reported instead of trying to receive the message from the peer again.
In your case, restarting a new ssh connection may be a better alternative.

[awaeag]

Thanks for this answer. But since this is quite old, I do not really remember all the researches I did at the time I opened the issue.
About your answer: I doubt this. What I understand here is the a message has been partially read, which is perfectly possible and does not break the ssh protocol as long as the rest of the message follows.
The problem may as well come from the _libssh2_transport_read you're talking about, that should only "accept" messages when they are completed.
I was just hoping a libssh2 developer would review this code, modify it or completely changes it, but at least fix the problem.