0
votes

I use PuTTY sessions to talk to an embedded device running QNX 6.4.1 using SSH over TCP/IP.

Today, one of my systems mysteriously won't allow me to have more than one PuTTY session open at a time. If I try to start a second session, I can authenticate with user name and password, but the sign on banner prints out with an extra blank line between each line and messes with my ability to hit enter. I can do nothing that looks remotely valid except Control-C or close the PuTTY window.

  • I suspected the text file that contains the banner had bad line endings, but it does not.

  • I suspected terminal setting issues, but if I have one session open it works. With no changes to settings, just trying to open a second session it does not.

  • I wondered if the .profile was getting mangled, but that doesn't seem to be the case either.

  • Now I'm down to "perhaps ssh is messed up and rebooting would fix it?" But I am hesitant to reboot it because if we lose TCP/IP connection to it, it's several hours worth of work (physical labor) to restore.

Any thoughts about what is going wrong and how I can fix it?

I'm connecting using PuTTY 0.62 from 64-bit Windows 7 to QNX 6.4.1. The openssh/openssl version is modern.

UPDATE

The issue came back a few days later. Using Guntram Blohm's suggestion below, I was able to at least get past the "Press enter once you've read the banner" screen. I then ran stty sane ctrl-j as he recommended. Here is the output of stty:

Bad after I had run stty sane ctrl-j (And hand reformatted it to be readable)

Name:  /dev/ttyp1
Type:  pseudo
Opens: 3
+raw +echo
+osflow
intr=^C  quit=^\ erase=^?  kill=^U   eof=^D start=^Q  stop=^S  susp=^Z
lnext=^V   min=01  time=00   pr1=^[   pr2=5B  left=44 right=43    up=41
down=42   ins=40   del=50  home=48   end=59

I then opened another PuTTY session immediately after this and it worked properly. This is confusing me how it works sometimes and doesn't work others. How can that happen? What is different?

Good

Name:  /dev/ttyp2
Type:  pseudo
Opens: 2
+edit
+osflow
 intr=^C  quit=^\ erase=^?  kill=^U   eof=^D start=^Q  stop=^S  susp=^Z
lnext=^V   min=01  time=00   pr1=^[   pr2=5B  left=44 right=43    up=41
 down=42   ins=40   del=50  home=48   end=59

So right now I have a good PuTTY terminal open, and a bad one. What else can I do to isolate this issue?

1
You might try typing stty sane <ctrl-j> at the command prompt in that terminal window. Your terminal settings (not the putty settings, the settings of your terminal driver on the device!) seem to be messed up; in that case, the enter key might get interpreted as \r instead of \n, but ctrl-j should work.Guntram Blohm
@GuntramBlohm Thanks for the tip. I don't know what changed, but when I got back from the lab, it worked again. I don't like issues that fix themselves without me understanding why. I'll try your suggestion if/when it happens again. Thanks!kmort
@GuntramBlohm The issue is back. Your control-j tip is marvelous. I ran stty sane ctrl-j and now I can actually use my enter key. It doesn't fix everything, but it lets me at least function. I still don't know how things got so messed up, but they obviously did. Is there anything else I can do to diagnose this problem before I reboot the device?kmort

1 Answers

1
votes

It's probably another process that uses the pseudo-terminal, puts it in a special state, then crashes without restoring the state. vi comes to mind, or maybe a file upload/download program. These programs change the terminal mode to read each character indicidually, instead of line by line, and tweak a few other things as well. Normally, logging out/back in SHOULD fix that, but i'm not sure QNX handles it correctly.

One thing you could do to copy the parameters of a working terminal to the messed up one is stty -g on the good one, then paste that output to the command line of the bad one. Like this (on Linux, i don't have a QNX at the moment):

(on the good terminal)

gbl@bermuda$ stty -g
500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

(on the bad one)

gbl@bermuda$ stty 500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

These terminal modes are kept per pseudo tty device, that's why your /dev/ttyp1 can be messed up, while the /dev/ttyp2 that's allocated for the next ssh connection is ok.