Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: auspex!guy@uunet.uu.net (Guy Harris)
Newsgroups: comp.sys.sun
Subject: Re: 8-bit login trouble
Keywords: Miscellaneous
Message-ID: <606@brchh104.bnr.ca>
Date: 5 Dec 90 02:00:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 27
Approved: Sun-Spots@rice.edu
X-Original-Date: 23 Nov 90 22:56:20 GMT
X-Refs:  Original: v9n371
X-Sun-Spots-Digest: Volume 9, Issue 388, message 2
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu


 >I'm trying to setup a login for 8 databits, no parity. This should
 >(according man gettytab) be possible by using the 'p8' flag in
 >/etc/gettytab.  It doesn't work very well. I get the "login:" prompt fine
 >with 8 bits, no parity, but after entering the userid, the "Password:"
 >prompt appears with 7 bits, even parity. The rest of the session is also 7
 >bits.. Could it be that getty supports 8bits but login does not?

Yup.  More precisely, "getty" was enhanced to have a "p8" flag that turns
on an 8-bit datapath, but "login" wasn't fixed to leave the 8-bit datapath
alone.

"login" was fixed to leave the 8-bit datapath alone in 4.1; for those who
have source (either to the SunOS 4.0[.x] "login", or to the 4.3BSD "login"
from which it's derived and have the 4.3BSD one running under SunOS 4.x),
the fix is to:

1) have "login", instead of clearing the entire "local flags word"
   including the PASS8 bit, leave the state of the PASS8 bit alone, and clear
   all the other bits;

2) have programs other than "getty" that use "login" (e.g., the TELNET and
   "rlogin" daemons) set up the PASS8 bit in the "local flags word"
   appropriately.

For those who have only binaries, well, sorry, but if you have lots of
courage, you can try to patch the binary to do the same....