I noticed that when logging into a Linux machine with current that there is a message in the system log: sshd[21992]: Setting tty modes failed: Invalid argument After some debugging it came down to the realization that perhaps (thanks djm@) the modes being sent from OpenBSD are not valid on Linux. I'm not sure how to resolve this, or if this is a major problem, but it appears that since the mode settings failed, perhaps something ssh needed might not be set, or might be set wrong. I added a log message: /* Set the new modes for the terminal. */ if (tcsetattr(fd, TCSANOW, &tio) == -1) { log("Setting tty modes failed: %.100s", strerror(errno)); log("failed..: %d, %d, %d, %d, %d", fd, tio.c_iflag, tio.c_oflag, tio.c_cflag, tio.c_lflag); } And notice that the system logged the following the next time through: Setting tty modes failed: Invalid argument failed..: 10, 1280, 5, 447, 51771 and tried again and only the fd changed: Setting tty modes failed: Invalid argument failed..: 8, 1280, 5, 447, 51771 Hopefully this information is useful.
what kernel and glibc version? try with "stty -parenb" on client side.
Client is OpenBSD, server is Linux. Using 'stty -parenb' on OpenBSD this does not log the problem on the Linux server. todd@cvis1:~> rpm -qa | egrep "glibc-2|^k_" k_deflt-2.4.10-12 glibc-2.2.4-64 todd@cvis1:~>
can a glibc/linux person look at sysdeps/unix/sysv/linux/tcsetattr.c and debug this? this code is interesting: if (retval == 0 && cmd == TCSETS) { /* The Linux kernel has a bug which silently ignore the invalid c_cflag on pty. We have to check it here. */
/usr/src/linux/drivers/char/pty.c:345 reads static void pty_set_termios(struct tty_struct *tty, struct termios *old_termios) { tty->termios->c_cflag &= ~(CSIZE | PARENB); tty->termios->c_cflag |= (CS8 | CREAD); } This gets called when someone does tcsetattr() on a pty. I think I can see a reason for clearing CSIZE and setting CS8|CREAD, but why clear PARENB? And in the glibc code quoted by Kevin this behaviour is referred to as if it should return some error contrary to the current 'silently ignore' approach.. What do kernel gurus on/from LKML say?
a linux person needs to dig into this one
no linux person cares to investigate so we close this. re-open if you have an answer.
Mass change of RESOLVED bugs to CLOSED