bep@quintro.uucp (Bryan Province) (01/18/91)
A while back I posted an article about a problem with getty. Several people
said they were experiencing the same problem. I worked some with the
HP/Apollo support line but I couldn't convince them that they had a problem.
The problem is this.
When the login process first starts up it uses 7 bits, even parity, and 1
stop bit even though I have it setup to use 8,n,1. After you type in your
username at what looks like a garbled login prompt the line gets reset back
to 8,n,1 and the Password: prompt looks fine and so does everything else
after that. After you logout the login prompt goes back to 7,e,1 and the
cycle starts all over again. I have seen the problem only when using the
Procomm terminal emmulator on a PC. I have noticed that other people have
seen the problem with other PC terminal emmulators.
When I explained the problem to the support line the guy said he didn't have
Procomm and had no way of getting a copy. He wasn't very helpful in trying
to recreate the problem and I gave up.
Has anyone else been successful in getting HP/Apollo to acknoledge this
problem? I know that several HP/Apollo people are now reading this net so
maybe you are or aren't aware of this.
BTW, I want to take the opportunity to graciously thank you HP people who are
watching this forum. I especially want to thank those who have responded to
questions posted here. Your comments ( though not officially from HP :-) )
are greatly appreciated.
--
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
Bryan Province -Glenayre Corp., Quincy, IL- quintro!bep@lll-winken.llnl.gov
"I tried putting instant coffee in the microwave,
I almost went back in time." - Steven Wrightweber_w@apollo.HP.COM (Walt Weber) (01/19/91)
In article <1991Jan17.214034.1951@quintro.uucp>, Bryan Province writes: |> |> A while back I posted an article about a problem with getty. Several people |> said they were experiencing the same problem. I worked some with the |> HP/Apollo support line but I couldn't convince them that they had a problem. |> The problem is this. |> |> When the login process first starts up it uses 7 bits, even parity, and 1 |> stop bit even though I have it setup to use 8,n,1. After you type in your |> username at what looks like a garbled login prompt the line gets reset back |> to 8,n,1 and the Password: prompt looks fine and so does everything else |> after that. After you logout the login prompt goes back to 7,e,1 and the |> cycle starts all over again. I have seen the problem only when using the |> Procomm terminal emmulator on a PC. I have noticed that other people have |> seen the problem with other PC terminal emmulators. Bryan - The problem is that getty (bsd4.3 and bsd4.3-tahoe versions) use an INTERNAL routine which ALWAYS generates 7bit even parity when accepting input. The first input (login name) is accepted by getty using it's internal parity routine. Getty only sets the line to the gettytab setting just before it is going to exec() /bin/login. Now, you could make an argument that the behavior is wrong, and I'm going to dodge that issue. We CAN say, however, that the behavior is the way that BSD is designed to operate, and Apollo appears to conform to that behavior model. I say "appears" because this isn't an official response from HP, Apollo Systems Division of HP, the HP response center organization; it's "from Walt". (I'd have gone on more, but my "insert_disclaimer" macro just blew up :-). I know this doesn't do much more than define the issues more clearly. I hope it's been helpful. I HAVE seen users config their PC lines for 7 bit/ignore parity during the login sequence, and then switch over to 8/n/1 for the login session; it generally involves some kind of scripting language on the PC end. |> Bryan Province -Glenayre Corp., Quincy, IL- quintro!bep@lll-winken.llnl.gov ...walt... Walt Weber Hewlett Packard Response Center 508-256-6600x8315 Chelmsford, MA, USA "The power of accurate observation is commonly called cynicism by those who have not got it" -George Bernard Shaw
bergum@CIM-TUNE.HONEYWELL.COM (Dave Bergum) (01/19/91)
I don't know if this is of any help or not. I have recently worked
with the getty and login software on sysV on an ATT3b2. We were having
similar problems where we would setup certain modes in gettydef (?) and
they would be reset during login and password input. Because of this I
wrote my own replacement software so the modes would be handled
correctly...we had to talk to a telex machine through a converter box
and could not get the modes to stay the way we needed them for the
login process. Mt Xinu software does indeed set modes to default
values and then resets them after login to those defined in gettydef.
I imagine the stuff on Apollo is the same. I don't know if you would
consider that a bug or a design feature ;-( I think they are all like
that. If you want it different, you'll probably have to write your
own. Too bad, eh?
A
-----/|\---------------------------------------+
- / | \ Bergum@CIM-VAX.Honeywell.COM |
- /__|__\ Dave Bergum [MN26-3190] |
- j---'---/ 2701 4-th Ave. S., Mpls, MN 55408 |
-~~~~~~~~~~ (612)870-5839 |
-----------------------------------------------+rees@pisa.ifs.umich.edu (Jim Rees) (01/19/91)
In article <4f487956.20b6d@apollo.HP.COM>, weber_w@apollo.HP.COM (Walt Weber) writes:
(I'd have gone on more, but my "insert_disclaimer" macro just blew up :-).
I'll be happy to go on further. If they had "fixed" this, you can be sure
that some whining luser would have filed an APR saying it's not Just Like
Real Unix. I could point to many parts of the system that have been
crippled for this reason. Let's hear it for bug-for-bug compatibility.