[Bug 2565] High baud rate gets sent, solaris closes pty

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2565

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #2 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to Damien Miller from comment #1)
> does setting ospeed actually do anything on a PTY? AFAIK it doesn't
> on OS X, BSD or Linux.
> 
> If the terminal is being closed as a result of a failed
> cfsetispeed() call then that indicates a kernel or (possibly) libc
> problem - ssh doesn't exit when that fails, it just logs an error
> and continues.

I can reproduce this with an OpenBSD client and Solaris 11 server.  The
cfsetispeed succeeds but it looks like the data from the pty slave
never makes it back to the master.

truss'ing (with -v pollsys) sshd then hitting enter ends with
(lwp_sigmask calls elided):
21585:  write(2, " [ d t u c k e r @ s o l".., 19)      = 19
21583:   pollsys(0x08047890, 2, 0x00000000, 0x00000000) (sleeping...)
21583:           fd=4  ev=POLLRDNORM rev=0
21583:           fd=6  ev=POLLRDNORM rev=0x814 
21583:  pollsys(0x08047000, 2, 0x00000000, 0x00000000) (sleeping...)
21585:  read(0, 0x080473AC, 1)          (sleeping...)

The pids are:
 dtucker 21585 21583   0 11:40:29 pts/2       0:00 -bash
    root 21580 21579   0 11:40:27 pts/1       0:00 sshd -d -p 2022 -R
 dtucker 21583 21580   0 11:40:29 pts/1       0:00 sshd -d -p 2022 -R

so we've got the shell writing the prompt to stderr then waiting for
input on stdin, which are the pty.  Looks reasonable.

The sshd post-auth privsep slave is blocked in poll (which is how
select is implemented on Solaris).

sshd's descriptors are:

$ sudo lsof -p 21583 
COMMAND  PID USER   FD   TYPE             DEVICE SIZE/OFF      NODE
NAME
[...]
sshd   21583 root    0u  VCHR              221,1          443220255
/dev/pts/1
sshd   21583 root    1u  VCHR              221,1          443220255
/dev/pts/1
sshd   21583 root    2u  VCHR              221,1          443220255
/dev/pts/1
sshd   21583 root    3r  DOOR                         0t0        46
/system/volatile/name_service_door (door to nscd[426])
(FA:->0xffffff00cf178700)
sshd   21583 root    4u  FIFO 0xffffff00dadd16c0      0t0    184434
(fifofs) PIPE->0xffffff00dadd1750
sshd   21583 root    5u  FIFO 0xffffff00dadd1750      0t0    184434
(fifofs) PIPE->0xffffff00dadd16c0
sshd   21583 root    6u  IPv4 0xffffff00ce59a100   0t5578       TCP
sol11.dtucker.net:2022->client.dtucker.net:31563 (ESTABLISHED)
sshd   21583 root    7u  VCHR              238,2           81265120
/devices/pseudo/clone at 0:ptm->ptm
sshd   21583 root   10u  VCHR              238,2           81265120
/devices/pseudo/clone at 0:ptm->ptm

So, sshd is waiting to read from the TCP connection or a pipe, but not
the pty master.  That seems odd.

For the record, sshd is blocking is in wait_until_can_do_something():

$ sudo gdb -q --args `pwd`/sshd -de -p 2022 -o
useprivilegeseparation=no -r
(gdb) set follow-fork child
(gdb) run
[...]
debug1: Setting controlling tty using TIOCSCTTY.
^C
Program received signal SIGINT, Interrupt.
0xfec78ec5 in __pollsys () from /lib/libc.so.1
(gdb) bt
#0  0xfec78ec5 in __pollsys () from /lib/libc.so.1
#1  0xfec664c6 in _pollsys () from /lib/libc.so.1
#2  0xfec233b8 in pselect () from /lib/libc.so.1
#3  0xfec236b9 in select () from /lib/libc.so.1
#4  0x08074bbb in wait_until_can_do_something (readsetp=0x80479f8, 
    writesetp=0x80479f4, maxfdp=0x80479f0, nallocp=0x80479ec,
max_time_ms=0)
    at ../../serverloop.c:370
#5  0x08075ce7 in server_loop2 (authctxt=0x814be78) at
../../serverloop.c:863
#6  0x08081a3b in do_authenticated2 (authctxt=0x814be78)
    at ../../session.c:2758
#7  0x0807be6c in do_authenticated (authctxt=0x814be78) at
../../session.c:271
#8  0x0806be26 in main (ac=7, av=0x81451a8) at ../../sshd.c:2324

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.