Stty settings before login

Hello.

I'm experiencing a frustrating issue.

I'm using an old, unsupported terminal client (QVT) with AIX 6.1 using ssh2. I've come up with some stty settings that allow full usage of the system but to do so I've had to set "igncr". While this works fine once the user is logged in there are issues when creating a password.

When the user sets a new password of 7 characters and then hits enter a character appears to be added to the end as part of the <enter> (don't know which character - it's invisible because it's a password). When the user then tries to log in with the client's password popup it then doesn't match the original password.

If, when entering the new password, it is committed with ctrl-j instead of <enter> we have no problem so I'm assuming that if the stty settings within the users' .profiles were to be applied before the login prompt the problem would be solved, but I can see no way of doing this. The other alternative is the rather inelegant solution of mapping the enter key to "^j" within the terminal client - I would rather avoid this.

Can any provide any way of changing the stty default settings before the new password prompts?

Many thanks.

The default stty settings for unix are to treat Carriage-Return (aka Enter) as Line-Feed (aka Newline):

-inlcr -igncr icrnl

What you you get for "stty -a" before modifying the settings in .profile?

1 Like

Thanks for replying.

The default settings are:

 
$ stty -a
speed 0 baud; 24 rows; 132 columns;
eucw 1:1:0:0, scrw 1:1:0:0:
intr = ^@; quit = ^@; erase = ^@; kill = ^@; eof = ^@; eol = ^@
eol2 = ^@; start = ^@; stop = ^@; susp = ^@; dsusp = ^Y; reprint = ^@
discard = ^O; werase = ^W; lnext = ^@
-parenb -parodd cs5 -cstopb -hupcl cread -clocal -parext
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -iuclc
-ixon -ixany -ixoff -imaxbel
isig icanon -xcase echo echoe echok -echonl -noflsh
-tostop echoctl -echoprt -echoke -flusho -pending -iexten
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3
$

Hitting the return key with these settings gives me "^M" and I'm assuming that this is the character getting added onto the end of the passwords:

 
$
ksh: ^M:  not found.
$
ksh: ^M:  not found.
$

If I then do an stty sane I get a sort of double-enter each time:

 
$ stty sane
$
$ $
$ $

Stty igncr sorts me out nicely:

 
$ stty igncr
$
$
$

I have the QVT terminal client's Newline setting as "LF" (not "CRLF" or "CR").

usually the client can be set. Try to find a setup.
If not.
when are you logging something ask you about TERM?
what do you ask?
when you are loggined what your $TERM

echo $TERM
1 Like

My $TERM is currently "vt220". I can change it to "vt100" and "vt52" on QVT but, as far as I can tell, all three of them react the same to the return key (certainly after login, I haven't checked the password problem with vt100 or vt52).

I assume that this is a "telnet" client not a serial terminal.
The issue seems to be that the terminal emulator is identifying itself as a terminal type which is not in the termcap database. Also, the "enter" key appears to be generating carriage-return and line-feed like an old teletype.
I wonder what value you use for $TERM .

Yes. This seems to be the case even though I don't have the client set to "CRLF".

Perhaps there is something that can be done with the terminfo files in /usr/share/lib/terminfo to persuade AIX to ignore the <CR>s that I can't find a way to stop sending.

Judging from the "stty" values I don't think that AIX is even recognising that this is is is a VDU. The settings are more like a wide-carriage printer/terminal.

Have you considered getting a compatible terminal emulator?
Whether anything free on the Windows distribution will help will depend on the Windows version and whether you need a secure version.

Sometimes posible change CR, try. sometimes it's call "send CR"
Sometimes ENTER and ENTER near numeric is not the same.

Sometimes you can change name for your terminal to another name for me can be QVT

  1. If can create your name:
    - create new terminal QVT in terminfo (or termcap) by copy vt100 and modificate one (I not remember) of "lf", "cr" or "nel".
    compile terminfo

  2. if can't create your name:
    - change one terminal in terminfo (or termcap) can for vt100 by change one of "lf", "cr" or "nel" and have hope nobody wants login as vt100.

I think this is exactly what I needed. I'll have a play and get back...

---------- Post updated at 02:33 PM ---------- Previous update was at 08:55 AM ----------

I've found some documentation on the termcap file and I think that I can sort out my problem that way but the termcap file isn't compiling with the "tic" command. It just gives me the following and hangs without actually updating any of the terminfo files:

# tic -v7
Working in /usr/share/lib/terminfo
Hash table complete
264 collisions out of 531 entries

Any suggestions?

Edit: Ignore that for a moment...I may have been a bit dumb. It seems I may need to specify where the termcap file is.

I may be wrong but I believe that you need to know how the terminal emulator identifies itself when sent a "what are you" enquiry. This is because your original problem is before login.

This interesting termcap file may help or confuse. It does mention assorted obsolete Qume terminals including a both QVT VDUs and amazingly a Qume daisy wheel printer terminal.

http://www.cygwin.com/ml/cygwin/1998-07/msg00364/termcap

It seems to me that terminfo is more often used than termcap.
Lately it's true for all OS. AIX and application on it always prefer terminfo.

ONLY ONE THING MUST DO:
QVT/Term->DefaultSettings->Display->Newline can use CRLF/LF/CR
It's all.

Yes, I've tried all three of those settings. It's currently on "LF", but that doesn't stop it from sending a "CR" character as well!

We do have a termcap file so I've assumed that's what I should be working from, but I notice that the information in there doesn't match the compiled data in /usr/share/lib/terminfo/*. Is there another source file somewhere?

The most obvious solution is, as suggested, use a better terminal emulator, but the customer is refusing that one.