Funky keystroke responses.

[mightyscotchpine]

Hello. I am dialing in over a modem to a fully patched openserver 5.0.4 system in order to register the enterprise license (had to re-register b/c machine name changed). When I go into scoadmin something funny starts happening: no keystroke gets a response until I hit enter. Then all keystrokes are executed, one after the other.
Example: I hit [left arrow], [left arrow], [left arrow] and get nothing. If I then hit [enter], the cursor moves left three times and does the [enter]. Also, when I vi a file, it only displays 8 lines at a time.
I got the same dialing in from another wkstation, so it's not my terminal emulator. I had the client try it from the console, and it works fine. So it must be my tty, right? I switched from ansi emulation to wy60 on my port and my emulator, but no difference. The port I'm on (tty1a) is running 9600 baud w/ no flow control. I had the client disable/enable my tty, and even tried rebooting the server. No change. Has anyone had this problem before?

 

[edfair]

What is the system expecting for an attachment?
If I recall the default for the modem port is dialup, but you can specify it. File is /etc/ttytype.

Ed Fair
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[mightyscotchpine]

Yes. I've got tty1a set to ansi emulation. I'm not sure what you mean by attachment.

 

[edfair]

But you are attaching to tty1A aren't you? And 1A enabled with 1a disabled? And /etc/ttytype/tty1A as ansi?

Ed Fair
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[apeasecpc]

It sounds to me like a problem with the ttytype of your modem port in /etc/ttytype. I recommend you set both the modem and non-modem ports to the correct terminal type.

A quick and dirty way to temporarily and immediately configure the terminal type for your current login is:

TERM=[termtype] sh

For example:

TERM=ansi sh
TERM=vt320 sh

 

[mightyscotchpine]

ed: Sorry about the confusion. I am attaching to tty1a, and tty1A is disabled. Our company requires us to set up all our sites like that. My /etc/ttytype has ...
[/code]ansi tty1a
dialup tty1A

apeasecpc: I changed my emulation by doing

TERM=vt100 export TERM

.  When that didn't work, I edited my /etc/ttype file, logged out and back in.

I am going to reset the modem settings on the host end and see if that helps.

 

[edfair]

OK, I understand. At least your dilemma. Don't understand the corporate policy cause that's not the way the system was designed. But that shouldn't be the cause anyway.

Before you go into scoadmin, try env. It should show what the system thinks you are, just in case something in .profile trumps ttytype.

I've never paid attention to scoadmin's handling of the arrow keys other than up and down. I'll at least look into the 5.0.5 version so I know what they are supposed to do.

Ed Fair
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[apeasecpc]

A normal dialup configuration should connect you to port tty1A, NOT tty1a. The difference between the two is that tty1a does not carry RTS, CTS, DSR, or DTR, but modems work better with those signals supported. Normally you would use tty1a only for hard wired terminals cabled directly to the server port over a 4 wire serial cable, because the cabling does not have enough wires to carry all of your serial signals. Like Edfair said though, that probably isn't related to your problem.

Your TERM=vt100 export TERM would have done the same thing as my suggested TERM=vt100 sh, so the problem probably isn't the terminal type you are assigning. It is possible that there is a bug in your /etc/termcap file. You could try replacing it with a good copy from your master CD (be sure to back the old one up first).

It is also possible that the problem is due to the terminal package you are using on the terminal end. You should try dialing up using different terminal software.

 

[edfair]

After looking at the 5.0.5 and thinking a while:

I agree that it looks like the terminal emulation package, but since 2 workstations do it....

Was the dial in from the other workstation using the same software package for terminal emulation?

I would assume that env returns ANSI. And the console should be SCOANSI and linked in terminfo to ansi.

Only suggestion at this point would be to monitor what is leaving your emulator while you are keying the arrow keys. The one I have transmits immediately.

Ed Fair
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[MaxKnight]

We had miscellaneous modem terminal problems too, we ended
up blaming /etc/getty and found an old version from before
our upgrade to 5.0.4, copied it to /etc/getty.old and
changed the tty to use it in inittab (plus the files that
make up inittab when you make the kernel that it mentions
when you do enable/disable). That solved everything for us.

 

[mightyscotchpine]

Well, I tried replacing /etc/termcap, but it didn't change a thing. But I just found something else of possible interest.
I found this in /tmp/tclerror.656.log:

Uncaught error in Tcl program: scoadmin:                                       
(vTcl interp) Failed reading Receive Msg length - Invalid argument             
Error code = NONE                                                              
(vTcl interp) Failed reading Receive Msg length - Invalid argument             
    while executing                                                            
"VtInfo -charm"                                                                
    invoked from within

...
The rest is the details of the code that called VtInfo -charm. I can post it if anyone wants it. I get the same problem with another menu program, ssdiag. But I don't see any tcl error log generated b/c of that.
I don't know tcl beyond the basic idea, but scoadmin IS using it, and an error IS being generated. You cannot run VtInfo from the shell as far as I can tell, so I'm not sure what bogus result it is returning.