Mail Archives: cygwin/2004/11/22/05:29:34
Hi Bob and Pierre
thanks for your analysis so far.
Bob Byrnes wrote on Friday, November 19, 2004 5:49 PM:
> I spent a little time looking at these straces and scp -v
> output. I still don't understand what's going on, but it
> seems to be unrelated to the recent pipe changes. I say that
> because those changes only affected select for writes on
> pipes, and the problem seems to be on the read side. It looks
> like scp and ssh are sending only single bytes across the
> pipe when the failure occurs, so the pipe is almost empty,
> and (correctly) always selects writable anyway. Something is
> making the pipe disappear, causing PeekNamedPipe to fail for
> the ssh process in the select for read on pipes code (which
> has not been changed).
>
> Either something is going catastrophically wrong with the
> pipe at a very low level, or the scp process is closing it in
> a way that ssh does not expect. So far, I can't tell which
> is happening, but I did note one significant difference in
> the scp -v output: only the "good" invocation has ...
>
> debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
>
> An examination of the ssh sources to see what this means
> might be enlightening, but I don't have time to do that right now.
This debug output is generated calling function "client_input_channel_req" in clientloop.c. This means, that the function is not called in the "bad" case. This method is only referenced in the same file in function "client_init_dispatch_20" in the call "dispatch_set(SSH2_MSG_CHANNEL_REQUEST, &client_input_channel_req);". This constant is only used in serverloop.c also to initialize a dispatcher function and in channels.c in the function "channel_request_start" calling "packet_start(SSH2_MSG_CHANNEL_REQUEST);".
I have to admin, that this does still not really help yet, since it does not give any hint, why no packet with "exit-status" was received at all in the bad case.
Looking into function "dispatch_run" of dispatcher.c I can only guess, that for some reason the call to "packet_read_poll_seqnr" returns "SSH_MSG_NONE".
As Pierre already stated, the trace just has this difference of 120 vs. 64 read bytes in line 4538 and the following call for the debug output. :(
- Jörg
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -