kcantrel@digi.UUCP (Keith Cantrell) (07/21/89)
I am having a weird problem with remote machines logging into my Apollo DN3500
running BSD4.3. If the remote machine is using anything else but HoneyDanBer
uucp to login, they will not get past the "Password:" prompt. The problem
seems to be that after the remote machine sees "login:" prompt they send their
account name, next they see "Password:" and then they send their password but
nothing happens. And if I look at the output from "ps -ax" command I see that
getty has passed execution to "login -p username" but it is not getting any
CPU time. It seems as though the "login" program is not seeing the password
being sent by the remote machine. The weird part is that if the user at the
remote host uses tip (or some kind of communication program) and does the
login sequence by hand, it all seems to work. Now I have noticed that if I
try in login to this Apollo by hand and am talking to it at 7 data bits and no
parity, I will get the same results, but the remote machine that is trying to
call us swears that his is using 8 data bits, no parity, and 1 stop bit.
Has anybody else seen this problem??? And more importantly, does anybody have
a solution??
Thank you for any help,
Keith
-----------------------------------------------------------------------
Keith Cantrell Phones: hm: 214-492-1088
Apollo Computer wk: 214-519-2399 @ DSC
A Subsidiary of Hewlett-Packard
USMAIL: EMAIL:
2100 Sonata Ln cantrell@attctc.DALLAS.TX.US
Carrollton TX 75007 or
...!uunet!digi!kcantrel
-----------------------------------------------------------------------davew@gvgpsa.GVG.TEK.COM (David C. White) (07/21/89)
In article <187@digi.UUCP> kcantrel@digi.UUCP (Keith Cantrell) writes: >I am having a weird problem with remote machines logging into my Apollo DN3500 >running BSD4.3. If the remote machine is using anything else but HoneyDanBer >uucp to login, they will not get past the "Password:" prompt. The problem >seems to be that after the remote machine sees "login:" prompt they send their >account name, next they see "Password:" and then they send their password but >nothing happens. And if I look at the output from "ps -ax" command I see that >getty has passed execution to "login -p username" but it is not getting any >CPU time. It seems as though the "login" program is not seeing the password >being sent by the remote machine. The weird part is that if the user at the >remote host uses tip (or some kind of communication program) and does the >login sequence by hand, it all seems to work. Now I have noticed that if I >try in login to this Apollo by hand and am talking to it at 7 data bits and no >parity, I will get the same results, but the remote machine that is trying to >call us swears that his is using 8 data bits, no parity, and 1 stop bit. > >Has anybody else seen this problem??? And more importantly, does anybody have >a solution?? I have encountered this problem calling into SYS5 type systems from an Ultrix system. There were really two problems. The first was the parity which was easily fixed by the following sequence before expecting the login: prompt - "" P_ZERO "" \d\d The second problem involved the called system apparently not seeing the password even though my system saw and responded to both the 'login' and 'password' prompts. I'm not sure exactly where the password got lost but the system I was calling never seemed to see it even though I sent it. I could get past it by 'echo password > /dev/ttyd2' and I would get the login prompt again. I could then use the 'echo' command and send the login and password manually and the connection would start up normally. It appeared that the receiving system was not seeing all of the password since it would give me a bad login message and start over again. The solution that fixed this problem was to put a couple of delays after sending the response to the login prompt as follows: ogin:-\r-ogin:-\r-ogin: response\d\d ssword:--ssword:--ssword: xxxxx This seemed to correct the problem. If anybody knows why this works I would be very interested in hearing about it. -- David White Grass Valley Group, Inc. VOICE: +1 916.478.3052 P.O. Box 1114 Grass Valley, CA 95945 FAX: +1 916.478.3778 Internet: davew@gvgpsa.gvg.tek.com UUCP: ...!tektronix!gvgpsa!davew
lcz@dptudg.sat.datapoint.com (Lee Ziegenhals) (07/22/89)
kcantrel@digi.UUCP (Keith Cantrell) writes: >I am having a weird problem with remote machines logging into my Apollo DN3500 >running BSD4.3... > ...the remote machine that is trying to >call us swears that his is using 8 data bits, no parity, and 1 stop bit. I have had this problem several times when calling *out* from my 4.3 system, and it was a parity problem every time. I solved the problem by "sending" a P_ZERO from my L.sys entry for those systems to force the 8th bit to zero. If the remote system administration swears that they are using the correct parity, etc., then that may not be the problem. However, I would double- check; that's what it sound like to me! -Lee
levin@magnus.SR.COM (Michael M Levin) (07/24/89)
In article <187@digi.UUCP> kcantrel@digi.UUCP (Keith Cantrell) writes: >I am having a weird problem with remote machines logging into my Apollo DN3500 >running BSD4.3. If the remote machine is using anything else but HoneyDanBer >uucp to login, they will not get past the "Password:" prompt. The problem >..... Both the problem and the solution to it are NOT unique to Apollo, although it does appear to be related to non-HDB systems calling into a BSD environment, but none of that matters. If you simply have the calling party add a \n to the end of the password in their L.sys file, that will fix the problem. It would appear that without it being there, it doesn't do a NEWLINE at all, and therefore just hangs. In other words, if the chat script is doing something like: ..... in:--in: foo word: bar just change it to be ..... in:--in: foo word: bar\n And ALL WILL START WORKING miraculously. Or else I'm wrong. Please drop me a note via email and let me know if it cures the problem for you, or if I'm off-base. Good Luck, Mike Levin -- _ _ | | ___ ___ |_| ___ Michael Levin SilentRadio Headquarters- Los Angeles | |/ ._\| | || || \ 20732 Lassen Street, Chatsworth CA 91311 U.S.A. |_|\___/ \_/ |_||_|_| INTERNET:levin@SR.COM or {att|csun|srhqla}!magnus!levin