Re: channel_write will fail if large amount of data are being written (0.4 branch)

[Vic Lee <llyzs@xxxxxxx>]

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
> > > 
> > > 
> > > 
> > 
>