Xref: utzoo comp.protocols.tcp-ip:14777 comp.os.vms:35183
Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!jarthur!thor.claremont.edu!kvc
From: kvc@thor.claremont.edu (Kevin V. Carosso)
Newsgroups: comp.protocols.tcp-ip,comp.os.vms
Subject: Re: UCX and CDCnet problem
Message-ID: <1991Feb6.170053@thor.claremont.edu>
Date: 7 Feb 91 01:02:53 GMT
References: <12316.27ae98c0@ecs.umass.edu>
Sender: news@jarthur.Claremont.EDU
Reply-To: kvc@thor.claremont.edu (Kevin V. Carosso)
Followup-To: comp.protocols.tcp-ip
Organization: Innosoft International, Inc.
Lines: 22

In article <12316.27ae98c0@ecs.umass.edu>, ucc@ecs.umass.edu writes:

>We have an elusive problem, where at times, and not always
>on the same node, when a user tries to access the VAXcluster with a
>telnet process from a CDCnet device, (TDI) the user
>gets the message "USER AUTHERIZATION FAILURE", after typing
>in the password.  However the password is correct and not expired,
>or preexpired.

In the past I've had exactly this problem when the client TELNET sends
line-feeds for end-of-line.  Implementations of TELNET client based on the
old Berkeley 4.2 code have a bug when binary mode is negotiated whereby
they end the line with LF instead of CR.  This causes your VMS username
and password to never validate.  This is not noticed on UNIX servers but
for a few editors that run in raw mode and get confused by such clients.

I've not experienced this problem with UCX, but that was because the
broken Berkeley TELNETs have all been replaced around here long before
UCX ever existed.

	/Kevin Carosso
	 Innosoft