Screen full of yyyyy's with telnet connection.

[Doug_81]

I need some help with this one.
Some background:
2 alphas in a cluster.

Node1 running V7.1-1H2 and
Node2 running V7.3
Both machines are running TCP/IP V5.1-15

Node1 patches installed:
ALPSYS20, ALPF11X06, ALPDISM01, ALPINIT01, ALPMOUN07, ALPMTAA01, ALPBACK05, ALPSYSI01, ALPPTD02, ALPRMS04, ALPMANA02, ALPSCSI05.

Node2 patches installed:
VMS73_PCSI V2.0, VMS73_UPDATE V3.0, VMS73_SYS V7.0, VMS73_DRIVER V7.0, VMS73_LAN V6.0, VMS73_SYSLOA V4.0, VMS73_FIBRE_SCSI V7.0, VMS73_RPC V4.0, VMS73_F11X V3.0, VMS73_XFC V4.0.

The problem:
Node1 halted. Cause unknown. Sorry but it was 5:00am and I wasn't quick enough to think about forcing a crash dump at the time. I just rebooted it.

This causes Node2 to generate a constant stream of ÿÿÿÿÿ characters showing on the screen of any new telnet connection. Decnet connections function ok and all users who are already connected are ok.

Someone said that they saw this happen when someone started banging on their keyboard before getting the username prompt, but I think this is just a coincidence.

A reboot is the only solution. These patches were installed 4 days ago and both systems were rebooted at that time, so setting up a scheduled reboot won't work either, unless it is setup to reboot on a daily basis. Thinking that it is TCP/IP related, we tried restarting TCP/IP. This did not clear the problem.

Anyone ever seen this before?
Any assistance would be greatly appreciated.

Th

[Uwe Zessin]

TCP/IP V5.1 rings a bell - it could be a negotiation problem. See if you can get an update for this version.

[Doug_81]

My first impulse when I read your comment was to dismiss it because all the other Alpha systems I support are running ucx V4.1 or V4.2 and this being newer must be better...

However, the other side of this is that no other system is running ucx V5.1 and no other system is having this problem.

I will initiate a ucx upgrade as soon as I determine which version is compatable with VMS V7.1-1H2 & V7.3

It'll take a while to implement this change on these systems. We have gone for 3 weeks without seeing the problem so it may be a while before we can declare this resolved, after the upgrade.

Thanks,
Doug

[John Gillings]

Doug,
A very odd symptom!

Did you get any LOGIN or LOGFAILURE audit alarms? Any other audits or ACCOUNTNG information?

I you see it again, please perform a TCPTRACE between the systems. You'll also need to log a case with your local customer support centre. They will probably also want to see a transcript of the login, including some of the junk characters.

Though, one thing to check... is this happening on a terminal (a "real" one, like a VT220) with an attached printer? I remember some kind of issue like this with OPA0/terminal/printer - it was a feedback loop associated with the printer.

[Antoniov.]

Doug,
do you meet problem from client using windows xp/2k and pathwork emulator?
Sometimes my customers have same problem within this configuration but I can't yest solve (sigh) :-(

Antonio Vigliotti

[Wim Van den Wyngaert]

ECO AF 11-SEP-2001 Alpha and VAX

Images:

TCPIP$INETACP.EXE V5.1-15AF

Problem:

Incoming telnet sessions getting long string of control
characters and no username prompt. Telnet unusable even
after shutting down/restarting TCPIP; only reboot clears.
TNA0 template device characteristics were being corrupted.

Reference:

PTR 70-5-1793 / CFS.86044 / Req Id: GB_G01835 / UCX Note 8699

[Martin P.J. Zinser]

Hi Doug,

5.1 is the latest version compatible with VMS 7.1, make sure you get the latest ECO though.

Greetings, Martin

[Doug_81]

Thank you all for all your input.
I've upgraded ucx on both nodes to the latest version which is supported on the vms version running on that node:
i.e.
OpenVMS V7.1-1H2 - UCX Version V5.1 - ECO 5
OpenVMS V7.3 - UCX Version V5.4

The strange characters on a telnet connection haven't shown up since....it's been long enough but the system has been crashing during this time, so the results aren't conclusive.

The crashing problem appears to be related to a suspect FDDI card which we replaced last Friday. Could also be a cause of the telnet problem. Personally, I think it's a combination of the two.

Time will tell.
Thanks again,
Doug