Hi Aris, It seems it's ok after I remove the ssh_set_blocking call. So probably we don't need this patch for 0.4.
Thanks, Vic On Sat, 2010-01-23 at 01:13 +0800, Vic Lee wrote: > Hi Aris, > > It's the ssh_set_blocking() call in session.c. Maybe I shouldn't use it? > If I don't set blocking to false, will there be any impact on > channel_read_nonblocking? > > I also attach a patch which works for me, though I am not very sure if I > am doing the right thing here. > > Thanks, > > Vic > > On Thu, 2010-01-21 at 22:22 +0100, Aris Adamantiadis wrote: > > Hi Vic, > > > > Could you try to get a backtrace at this place ? > > I wonder why ssh_socket_nonblocking_flush is called. I put a breakpoint > > on this function and was not able to trigger it using samplessh. > > Could you also check session->blocking value ? normaly it's set to 1 in > > ssh_new and I could not find any other place where it's changed. > > > > Thanks, > > > > 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 > > > > > > > > > > > >
