It turned out to be a:
at the front of my chat script. Evidently uucpd doesn't throw away
extraneous <cr> or <lf> characters, so it was taking one of these as
the password. Many thanks to Guy Harris of Auspex for taking the time
to track down the solution to this, and several other people for making
helpful suggestions, such as using "-x 9" to see what was going on.
Now I can stop making those $100/month phone calls to pick up my news,
and start using my dedicated 56Kb circuit instead. What a relief!
The Nooz Must Go Through! :-)
Here's an excerpt of my original note to Sun-managers, followed by the full text of the article that Guy dug up about this:
>I'm using uucp under SunOS 4.1.1 on a 4/380. Normally, I call my >neighbor on the phone, and this works fine. But I recently installed a >dedicated circuit between our two networks, and now I'd like to use the >TCP device to make this connection. It starts to work, then hangs. > >It starts up, and I can watch it send the username, get the password >prompt, send the password, and then my local uucico goes into an >infinite loop on read(7,"",1)=0. (I determined this with "trace -p"; >whatever did we do before "trace -p"?)
We checked to be sure the login shell of the user on the other end was exactly "/usr/lib/uucp/uucico", which uucpd insists on: that was not the problem.
Then this appeared:
>From firstname.lastname@example.org Sat May 1 18:50:46 1993 >Return-Path: <email@example.com> >Received: by attain.ICD.Teradyne.COM (4.1/SMI-4.1/TER-1.35/attain-1.27) > id AA25439; Sat, 1 May 93 18:50:42 PDT >Received: from auspex.com ([220.127.116.11]) by auspex-gw.auspex.com (4.1/SMI-4.1) > id AA04535; Sat, 1 May 93 18:49:25 PDT >Received: by auspex.com (4.1/SMI-4.1) > id AA01438; Sat, 1 May 93 18:49:22 PDT >Date: Sat, 1 May 93 18:49:22 PDT >From: firstname.lastname@example.org (Guy Harris) >Message-Id: <9305020149.AA01438@auspex.com> >To: jxh@ICD.Teradyne.COM, email@example.com >Subject: Re: uucp via TCP >Status: RO > >> When I do "telnet netcomsv 540" from attain, I get a "login:" prompt, >> enter "uattain" <cr>, then I get a "Password: " prompt but then, >> immediately, get "Login incorrect.Connection closed by foreign host." >> without being actually asked for input. The same happens for user >> "nobody". Ditto if I do it from netcom.netcom.com to netcomsv, or from >> certes (an internal Teradyne host) to attain (so the gateway isn't >> it). >> >> Now, *this* is a clue! Any ideas? > >>From "comp.sys.sun.misc"; the subject is misleading - >the discussion, at that point, concerned UUCP over TCP: > > From: firstname.lastname@example.org (Pekka Nikander) > Newsgroups: comp.sys.sun.misc > Subject: Re: Running UUCP over rlogin session > Message-ID: <PNR.93Apr22172642@innopoli.ajk.tele.fi> > Date: 23 Apr 93 00:26:42 GMT > Organization: Telecomm Finland > > In article <1993Apr21.email@example.com> dennett@acadia.Kodak.COM (Charles R. Dennett) writes: > ! ! 2) it prompts you with "login:"; > ! ! > .... > ! ! 6) otherwise, if the account has a password, it prompts you with > ! ! "Password"; > > ! The login shell is /usr/lib/uucp/uucico. The password prompt is presented > ! but right away the connection drops with the Login incorrect message. > ! This is before the password can be entered. > > Your TELNET client is sending BOTH cr AND lf. The uucpd understands > the LF as an empty password. > >I.e., you *can't* TELNET to the UUCP daemon, unless you arrange that >your TELNET client send *only* a CR or *only* an LF at the end of a line >- CR followed by LF won't work. > >The same is true of the UUCP that's attempting to connect to the UUCP >daemon - it must also send *only* a CR or *only* an LF. (That's the way >the UUCP daemon came, out of the box, from Berkeley; we didn't change >that part at Sun.) > >Make sure your "chat script" in the "Systems" or "L.sys" file on the >machine that's trying to make the connection doesn't cause both a CR and >an LF to be sent, and make sure that the "uucico" on that machine >doesn't do so, either. >
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:48 CDT