Hi Vic,
Thanks for your bug report. It seems indeed that there's something
wrong in here and needs to be resolved. I also need to take care to
avoid such problems in 0.5 tree.
channel_write should either
-wait until packet_write completed with SSH_OK
or
-Be in nonblocking mode and report to the user that the write is
pending. There is nothing in the API do do that yet.
The actual assumption was that it was not yet possible to use libssh in
nonblocking mode (I though packet_flush always was blocking).
I'll get my eyes on this issue.
Regards,
Aris
Vic Lee a écrit :
Hi,
I found another bug in channel_write() which make it fail to tunnel an
xterm over SSH.
According to the description, channel_write() is a blocking write until
all data written or until error. However, in the following call
sequence:
channel_write -> packet_send -> packet_send2 -> packet_write ->
packet_flush (at packet.c:456), it uses a non-blocking call:
rc = packet_flush(session, 0);
which will almost always return SSH_AGAIN if large amount of data are
being flushed, and SSH_AGAIN will eventually returned by packet_send.
However, when channel_write calls packet_send it does not check for
SSH_AGAIN and simply think anything other than SSH_OK is an error.
This bug makes it impossible to tunnel an xterm (it's funny somehow
xterm has large data transmit). I temporarily change the packet_flush to
a blocking call fix the issue. But I think a right patch should be on
channel_write, checking SSH_AGAIN.
Your comments?
Thanks,
Vic
