Client does not propagate EPIPE write error to server.

[Bill Rugolsky Jr.]

Hi,

I'm experiencing the bug reported in:

http://bugzilla.mindrot.org/show_bug.cgi?id=85
Bugzilla Bug 85
ssh -2 localhost od /bin/ls | true ignore SIGPIPE

Perhaps a slightly more realistic example:

   rugolsky at mercury: ssh -vvv -x -n -2 localhost cat /dev/zero | dd count=1
   ...
   debug1: fd 4 setting O_NONBLOCK
   debug1: fd 5 setting O_NONBLOCK
   debug1: channel 0: new [client-session]
   debug3: ssh_session2_open: channel_new: 0
   debug1: send channel open 0
   debug1: Entering interactive session.
   debug2: callback start
   debug1: ssh_session2_setup: id 0
   debug1: Sending command: cat /dev/zero
   debug1: channel request 0: exec
   debug2: callback done
   debug1: channel 0: open confirm rwindow 0 rmax 32768
   debug2: channel 0: rcvd adjust 131072
   debug1: channel 0: read<=0 rfd 4 len 0
   debug1: channel 0: read failed
   debug1: channel 0: close_read
   debug1: channel 0: input open -> drain
   debug1: channel 0: ibuf empty
   debug1: channel 0: send eof
   debug1: channel 0: input drain -> closed
   1+0 records in
   1+0 records out
   debug1: channel 0: write failed
   debug1: channel 0: close_write
   debug1: channel 0: output open -> closed

   and hangs ...

It seems that with v2, EOF on input descriptors are propagated to the
peer as EOF, but there is no corresponding protocol mechanism in the
v2 protocol for indicating that an output file descriptor is closed?
Is this correct?  If so, it seems horribly broken.

The v1 code sets quit_pending=1, and exits the select loop.  I have a
hack that does something equally ugly for v2 by creating a channel state
notifier callback, and only registering it for the session_ident in
the clientloop setup.  Any better ideas?

Please CC me, as I'm not subscribed.

Regards,

	Bill Rugolsky