fkk@stasys.sta.sub.org (Frank Kaefer) (09/24/90)
Dear Readers,
I have a really severe problem with UUCP (HDB). I think this could be a
real bug of HDB UUCP and I urgently seek some advice.
Description:
If someone dials in my computer (Interactive Unix 2.2, TB2500 modem
connected with 19200 baud) with 1200 or 2400 baud, the whole thing
thing hangs after the login and the uucico has been started. After
about 1 min 45 sec. the connection is cancelled. This happens on nearly
80% of the incomung uucp-calls. Some of the callers get thousands of
"imsg> imsg> imsg>..." in their logfiles (debuglevel 9). Exactly the
SAME problem occured some time ago using a Sun Sparcstation 1+ with
SUN-OS 4.1 dialing into a SCO Xenix (80286) system and into a
Interactive System both using TB2000 modems and fixed speed at 19200
baud. So first I thought it might be a bug of SUN-OS 4.1, but now it
also happens on Interactive.
Last night the line wasn't cancelled and the uucico was doind nothing
for nearly 7 hours. This costed me quite a lot because it was a long
distance call.
Here is some uucico -x9 output:
-------
uucico: mchFind called (stasys)
uucico: list (rmail) num = 1
uucico: list (/usr/spool/uucppublic) num = 1
uucico: list (/usr/spool/uucppublic) num = 1
uucico: list (/) num = 1
uucico: list (/bin/rmail) list (/usr/bin/rnews) num = 2
uucico: _Request (FALSE), _Switch (TRUE), _CallBack (FALSE), _MyName (), _Commands /bin/rmail
uucico: _Commands /usr/bin/rnews
uucico: chdir(/usr/spool/uucp/stasys)
uucico: conn(stasys)
uucico: Device Type ACU wanted
uucico: mlock ttyF02 succeeded
uucico: filelock: ok
uucico: fixline(6, 2400)
uucico: processdev: calling setdevcfg(uucico, ACU)
uucico: gdial(Smartlink) called
uucico: expect: ("")
uucico: got it
uucico: sendthem (ATZ^M)
uucico: expect: (OK)
uucico: ATZ^M^M^JOKgot it
uucico: sendthem (ATS0=1M1^M)
uucico: expect: (OK)
uucico: ^M^JATS0=1M1^M^M^JOKgot it
uucico: sendthem (ATDP########^M)
uucico: expect: (CONNECT)
uucico: ^M^JATDP#########^M^M^JCONNECTgot it
uucico: sendthem (DELAY
uucico: ^M)
uucico: getto ret 6
uucico: expect: (ogin:)
uucico: 2400^M^J^M^M^JStasys Starnberg^M^M^Jlogin:got it
uucico: sendthem (uufips^M)
uucico: expect: (sword:)
uucico: ^M^M^M^JStasys Starnberg^M^M^Jlogin: uufips^M^M^JPassword:got it
uucico: sendthem (xxxxxx^M)
uucico: imsg >^M^JUNIX System V/386 Release 3.2^M^Jstasys^M^JCopyright (C) 1984, 1986, 1987, 1988 AT&T^M^JCopyright (C) 1987, 1988 MiLOGIN FAILED - failed
uucico: exit code 101
uucico: Conversation Complete: Status FAILED
uucico: TM_cnt: 0
-------
I had a look at the sources of HDB on SUN-OS 4.1 but I can only
guess. I think it might have something to do with negotiation of the
protocol to use (imsg.c), but I'm not sure.
So if you have any hints, PLEASE mail me or post them.
Mail to: fkk@Germany.sun.com please.
Thanks a lot in advance,
Frank
--
-------------------------------------------------------------------
| Frank Kaefer | fkk@stasys.sta.sub.org | Starnberg, West Germany |
| (Compuserve: 72427,2101) | Internet: fkk@Germany.SUN.COM |
-------------------------------------------------------------------wolfgang@wsrcc (Wolfgang S. Rupprecht) (09/24/90)
fkk@stasys.sta.sub.org (Frank Kaefer) writes: >I have a really severe problem with UUCP (HDB). I think this could be a >real bug of HDB UUCP and I urgently seek some advice. [...] >Here is some uucico -x9 output: uucico: ^M^M^M^JStasys Starnberg^M^M^Jlogin: uufips^M^M^JPassword:got it uucico: sendthem (xxxxxx^M) >uucico: imsg >^M^JUNIX System V/386 Release 3.2^M^Jstasys^M^JCopyright (C) 1984, 1986, 1987, 1988 AT&T^M^JCopyright (C) 1987, 1988 MiLOGIN FAILED - failed ******************^^^^********************* >uucico: exit code 101 I would be very wary of sending all that crap to uucico. Put a ".hushlogin" in uucico's home directory (I think this is user name "nuucp" on System V). Incidently be careful with the string "AT&T". If in command mode the modem will start its self test (&T == test). Never have getty (as part of its pre-login banner) send such a string to a modem that is waiting for an incoming call. -wolfgang -- Wolfgang Rupprecht uunet!{nancy,usaos,media!ka3ovk}!wsrcc!wolfgang Snail Mail Address: Box 6524, Alexandria, VA 22306-0524
kdq@demott.COM (Kevin D. Quitt) (09/24/90)
In article <1135@stasys.sta.sub.org> fkk@stasys.sta.sub.org (Frank Kaefer) writes: > >Dear Readers, > >I have a really severe problem with UUCP (HDB). I think this could be a >real bug of HDB UUCP and I urgently seek some advice. > >Description: > >If someone dials in my computer (Interactive Unix 2.2, TB2500 modem >connected with 19200 baud) with 1200 or 2400 baud, the whole thing >thing hangs after the login and the uucico has been started. Just a shot in the dark, but make sure your modem is answering PEP last, or the slower modems can be confused by the PEP tones. I have seen partial connections that crap out. Set s92=1 to get this mode. -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
lisbon@vpnet.chi.il.us (Gerry Swetsky) (09/26/90)
kdq@demott.COM [Kevin D. Quitt] suggests: > Just a shot in the dark, but make sure your modem is answering PEP > last, or the slower modems can be confused by the PEP tones. I have seen > partial connections that crap out. Set s92=1 to get this mode. At vpnet we've been answering PEP tones first for several years now and have like zero problems with slow modems calling in. They merely have to add \d's to their string in Systems. I think the problem lies elsewhere. -- ============================================================================ | Help stamp out stupid .signature files! Gerry Swetsky | | vpnet offers callers free access to selected Usenet conferences | | Home (708)833-8122 vpnet (708)833-8126 lisbon@vpnet.chi.il.us | ============================================================================
sean@utoday.UUCP (Sean Fulton) (09/26/90)
In article <1990Sep24.134639.360@wsrcc> wolfgang@wsrcc (Wolfgang S. Rupprecht) writes: >fkk@stasys.sta.sub.org (Frank Kaefer) writes: >>I have a really severe problem with UUCP (HDB). I think this could be a >>real bug of HDB UUCP and I urgently seek some advice. [...] >>Here is some uucico -x9 output: >uucico: ^M^M^M^JStasys Starnberg^M^M^Jlogin: uufips^M^M^JPassword:got it >uucico: sendthem (xxxxxx^M) >>uucico: imsg >^M^JUNIX System V/386 Release 3.2^M^Jstasys^M^JCopyright (C) 1984, 1986, 1987, 1988 AT&T^M^JCopyright (C) 1987, 1988 MiLOGIN FAILED - failed > ******************^^^^********************* >>uucico: exit code 101 Check /etc/passwd to make sure stasys has a valid account, a valid directory, and a valid shell (/usr/lib/uucp/uucico). The login itself was actually completed, it was the waiting for Shere= that died. I say this because we had the exact same problem here a while back, and it was something really obvious but took hours to figure out. Try replacing uucico with /bin/sh and login. -- Sean Fulton sean@utoday.com UNIX Today! (516) 562-5430 /* The opinions expressed above are not those of my employer */
les@chinet.chi.il.us (Leslie Mikesell) (09/27/90)
In article <1812@utoday.UUCP> sean@utoday.UUCP (Sean Fulton) writes: >In article <1990Sep24.134639.360@wsrcc> wolfgang@wsrcc (Wolfgang S. Rupprecht) writes: >>fkk@stasys.sta.sub.org (Frank Kaefer) writes: >>>I have a really severe problem with UUCP (HDB). I think this could be a >>>real bug of HDB UUCP and I urgently seek some advice. [...] >>>uucico: exit code 101 > >Check /etc/passwd to make sure stasys has a valid account, a valid >directory, and a valid shell (/usr/lib/uucp/uucico). The login itself >was actually completed, it was the waiting for Shere= that died. Another thing to check is the /usr/lib/uucp/Permissions file on the remote machine. I don't know if there is any indication of a problem in the -x9 debug output, but I have seen uucico fail silently due to a syntax error in the Permissions file. Les Mikesell les@chinet.chi.il.us
woods@eci386.uucp (Greg A. Woods) (09/28/90)
In article <1812@utoday.UUCP> sean@utoday.UUCP (Sean Fulton) writes: > In article <1990Sep24.134639.360@wsrcc> wolfgang@wsrcc (Wolfgang S. Rupprecht) writes: > >fkk@stasys.sta.sub.org (Frank Kaefer) writes: > >>Here is some uucico -x9 output: > >>uucico: imsg >^M^JUNIX System V/386 Release 3.2^M^Jstasys^M^JCopyright (C) 1984, 1986, 1987, 1988 AT&T^M^JCopyright (C) 1987, 1988 MiLOGIN FAILED - failed > > ******************^^^^********************* > >>uucico: exit code 101 > > Check /etc/passwd to make sure stasys has a valid account, a valid > directory, and a valid shell (/usr/lib/uucp/uucico). The login itself > was actually completed, it was the waiting for Shere= that died. > > I say this because we had the exact same problem here a while back, > and it was something really obvious but took hours to figure out. Try > replacing uucico with /bin/sh and login. In other words, *ALWAYS* run /etc/pwck after you edit the password file. It does a good job of validating this very essential database. In fact, if there is any chance of another user running passwd (or chsh, should you have it) you should be using some sort of protective wrapper around the editor, such as vipw, which could easily run pwck for you. Also, you need not change uucico with sh. Just type '<CTRL-P>Shere=nobody<LF>' and the cico will quietly go away (unless your machine knows another named "nobody" :-) ). -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA
scott@phlpa.UUCP (Scott Scheingold) (04/10/91)
I am very sorry if this message shows up more than once, problems with my news poster. I have a question regarding prioritys. When I priority is set for a user and this user executes a file that sets the user id to the owner of a file. Who gets the priorty the user executing the file or the owner of the file. An example of this would be as follows. -rwsr-sr-x 2 news news 90612 Apr 03 11:17 rnews Now this program is started by uucp but it is set to use news UID but when this program is run a ps -ef shows that uucp is running the program. If a priority of say 30 was put on this so it would not take as much cpu time who would get the setting. uucp or news. I am running SCO UNIX SYS V/386 Rel. 3.2.2 Thanks for the help. Scott Scheingold UUCP ...!lgnp1!phlpa!scott INTERNET scott@lgnp1!phlpa