https://bugzilla.mindrot.org/show_bug.cgi?id=2565
--- Comment #4 from Darren Tucker <[email protected]> --- Confirmed that commenting out only the calls to cfsetospeed and cfsetispeed in ttymodes.c prevents the problem. Going back through a complete strace of sshd I see this: 6212: pollsys(0x08047890, 3, 0x00000000, 0x00000000) = 2 6212: fd=4 ev=POLLRDNORM rev=0 6212: fd=6 ev=POLLOUT|POLLRDNORM rev=POLLOUT 6212: fd=9 ev=POLLRDNORM rev=POLLRDNORM 6212: clock_gettime(4, 0x08047954) = 0 6212: read(9, 0x0804391C, 16384) = 0 6212: close(9) = 0 6212: write(6, "\0\0\010 BA0 q zF8 {88F9".., 84) = 84 6212: getpid() = 6212 [6209] 6212: clock_gettime(4, 0x080478B4) = 0 6212: pollsys(0x08047890, 2, 0x00000000, 0x00000000) = 1 6212: fd=4 ev=POLLRDNORM rev=0 6212: fd=6 ev=POLLOUT|POLLRDNORM rev=POLLOUT where fd#9 is our missing FD on the pty master, and this is the first pollsys where fd#9 is included. >From this we can infer from this that sshd does in fact set up the descriptors correctly. pollsys says that fd#9 is readable, and when sshd reads it the read returns zero, indicating end-of-file. sshd then closes the descriptor and removes it from the set it's looking at, hence why we didn't see it in the later calls. If this sounds familiar it's because we've encountered the same thing on AIX (but probably for different reasons, in that case it was passing through zero-byte writes from the pty slave). There's already a workaround hack for it (PTY_ZEROREAD) which seems to help in this case, but I'd like to understand what the problem is (and what other potential side effects are) before we go enabling that on Solaris. Anyone from Oracle care to comment? Why does setting the baud rate on a pty to 57600 cause it to change its read behaviour? -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
