Xref: utzoo comp.unix.xenix:4443 comp.mail.uucp:2622
Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!cornell!uw-beaver!uw-june!uw-entropy!thebes!jwc
From: jwc@Thalatta.COM (Bill Campbell Guest account)
Newsgroups: comp.unix.xenix,comp.mail.uucp
Subject: Re: Problem with uucp login with SCO XENIX 2.3.1
Message-ID: <210@thebes.Thalatta.COM>
Date: 12 Jan 89 16:19:16 GMT
References: <252@electro.UUCP> <1465@cps3xx.UUCP>
Reply-To: jwc@Thalatta.COM (Bill Campbell Guest account)
Organization: Thalatta Corporation, Bellevue WA
Lines: 30

In article <1465@cps3xx.UUCP> las@frith.UUCP (Larry A. Shields {runs Lunapark}) writes:
>Yes it seems to ignore parity changes.  What will work, at least
>with a ordinary login, is to follow the login name with a ctrl-j.
>After that all is ok.
>
I have seen this happen because of a problem in /etc/gettydefs.
The gettydefs entry consists of five parts separated by the '#'
characters.  The first is an identifier referenced in /etc/ttys
on Xenix systems or in /etc/inittab on sysV, the second sequence
is the baud rate... used for login password, the third the baud
rate... for use after login, the fourth is the login prompt, and
the last is the next gettydefs entry to use (cycles baud rates...).

The following two entries cycle between 1200 and 2400 baud.

2 # B1200 HUPCL OPOST CR1 NL1 #
	B1200 CS8 SANE HUPCL TAB3 IXANY # \r\n@!Login: # 3

3 # B2400 HUPCL OPOST CR1 NL1 #
	B2400 CS8 SANE HUPCL TAB3 IXANY # \r\n@!Login: # 2

I have messed this up by copying an existing entry to create an
entry for a new baud rate, and forgetting to change the baud rate
on the second entry so that it changes after you finish the login :-(

Another common error is to screw up the last entry which tells
getty which entry to use next so that the baud rates don't cycle
properly.

Bill Campbell.