Quite annoying, yes.
Since there are separate messages for client eof and client close, it
seems clear that eof means "I'm done talking," not "we're done talking."
That's close.
I added that eof because sun ssh wasn't sending me exit status until I did.
Now I have to figure out how to keep you both happy without offending
somebody else.
So, the plan is to run the same command with ssh -t and with my stuff,
capture detailed logs for both with dropbear, compare, and then emulate
openssh as much as I can.
Anybody that breaks with openssh behaviors is likely to get fixed pretty
fast. ;-)
Thanks for the support, Matt.
- Tim.
On 3/21/14 7:24 AM, "Matt Johnston" <[email protected]> wrote:
>Hi,
>
>I'm not sure whether it's possible to use EOF like that for a
>session with a PTY terminal.
>
>For a PTY session it will have a single file descriptor
>(returned from openpty() or similar) for both stdin and
>stdout. Dropbear's behaviour on receiving a EOF is to close
>the stdin for the process (assuming no write data is
>pending), then let the process deal with it. For the PTY
>case closing that file descriptor will also close stdout.
>
>For TCP channels Dropbear uses shutdown() to close each
>direction independently, but I don't think that will work
>with a PTY - anyone know?
>
>Have you come across any programs that aren't flushing
>buffers? Does running without a terminal work OK with your
>EOF-sending program? I tried to make a quick change to send
>a eof straight away but can't replicate it.
>
>(As a side-note I hit the same hassle with sudo needing a
>terminal this week - annoying!)
>
>Cheers,
>Matt
>
>
>On Thu, Mar 20, 2014 at 05:48:51PM +0000, Tim Broberg wrote:
>> For reasons which may, or may not be, pathological, I'm working on
>> developing
>> an SSH client. I'm running into problems executing commands in a
>>terminal
>> on
>> dropbear.
>>
>> I'm sending an exec request to a session with a terminal (so I can run
>> sudo commands).
>>
>> I send the channel request, then send eof expecting to get data, exit
>> status, and eof back.
>>
>> Instead, dropbear server sends eof right away, then the running command
>> fails because his terminal has been shut down. (See the last 3 lines of
>> the server log snippet below.)
>>
>> If I don't send eof, it works fine, but then I worry about other
>>processes
>> /
>> Servers not flushing buffers out until they see eof.
>>
>> I would expect dropbear to wait for the outstanding channel request to
>>run
>> to completion before sending eof.
>>
>> Am I making sense, or is there some problem with my use case of
>>requesting
>> exec from a terminal session? If this is considered an invalid use case,
>> what would you suggest as an appropriate usage / workaround?
>>
>> The full log is attached, and an excerpt from receipt of eof to the
>> failure of the command due to terminal non-existence is below.
>>
>> Thanks for any help you're able to provide,
>> - Tim.
>>
>> TRACE (2354): enter recv_msg_channel_eof
>> TRACE (2354): check_close: writefd 6, readfd 6, errfd -1, sent_close 0,
>> recv_close 0
>> TRACE (2354): writebuf size 0 extrabuf size 0
>> TRACE (2354): sesscheckclose, pid is -1
>> TRACE (2354): sesscheckclose, pid is -1
>> TRACE (2354): CLOSE some fd 6
>> TRACE (2354): enter send_msg_channel_eof
>> TRACE (2354): enter encrypt_packet()
>> TRACE (2354): encrypt_packet type is 96
>> TRACE (2354): enter writemac
>> TRACE (2354): leave writemac
>> TRACE (2354): enter enqueue
>> TRACE (2354): leave enqueue
>> TRACE (2354): leave encrypt_packet()
>> TRACE (2354): leave send_msg_channel_eof
>> TRACE (2354): leave recv_msg_channel_eof
>> TRACE (2354): leave process_packet
>> TRACE (2354): check_close: writefd -1, readfd -1, errfd -1, sent_close
>>0,
>> recv_close 0
>> TRACE (2354): writebuf size 0 extrabuf size 0
>> TRACE (2354): sesscheckclose, pid is -1
>> TRACE (2354): sesscheckclose, pid is -1
>> TRACE (2354): CLOSE some fd -1
>> TRACE (2354): enter write_packet
>> TRACE (2354): empty queue dequeing
>> TRACE (2354): leave write_packet
>> TRACE (2354): check_close: writefd -1, readfd -1, errfd -1, sent_close
>>0,
>> recv_close 0
>> TRACE (2354): writebuf size 0 extrabuf size 0
>> TRACE (2354): sesscheckclose, pid is -1
>> TRACE (2354): sesscheckclose, pid is -1
>> TRACE (2354): CLOSE some fd -1
>> TRACE (2356): back to normal sigchld
>> [2356] Mar 19 14:13:12 ioctl(TIOCSCTTY): Input/output error
>> [2356] Mar 19 14:13:12 /dev/pts/1: No such file or directory
>> [2356] Mar 19 14:13:12 open /dev/tty failed - could not set controlling
>> tty: No such device or address
>>
>>
>>
>
>
