kherron@s.ms.uky.edu (Kenneth Herron) (02/02/91)
One of our remote sites is having problems with uugetty. This site has a 2400 baud MNP modem attached to tty00; it's configured to talk to the computer at 9600 baud. They run uugetty on the port, also configured for 9600 baud, to allow us to log in each night for uucp. Last week the system administrator accidently did an rm -r * in /usr and didn't have a proper backup, so she was forced to recover program files by hand from the foundation disks. Ever since then, any attempt to dial in to the modem results in this behavior: 1) Before dial-in, uugetty is observed to be running 2) Dial in; modem answers phone and I get a 2400 baud connection 3) Connection lasts ~2 seconds, just long enough to hit a few carriage returns if I want to (makes no difference either way) 4) Remote modem (theirs) hangs up 5) Ps reveals a new uugetty (different process number). In short, it appears that uugetty dies as soon as it detects the modem's connection; the modem probably hangs up because it detects DTR being dropped. We've checked permission bits and ownership on uugetty, /usr/spool/locks, /bin/login, and /etc/gettydefs. Everything looks correct; gettydefs hasn't been modified since the system was installed. The modem is configured through a uucico script; all the administrator has to do is issue "cu reset" and stand back. This works fine, and as I said the modem will make a connection with mine. Unfortunately, the site is in Wyoming and I'm not, so I can't get any closer to the machine than to lead the sysadmin through certain checks over the phone. Does anyone have *any* suggestions? -- Kenneth Herron kherron@ms.uky.edu University of Kentucky (606) 257-2975 Department of Mathematics "Never trust gimmicky gadgets" -- the Doctor