mhw@fithp.uucp (Marc Weinstein) (03/12/91)
I just switched over to a 3b1 from my old UNIX PC, and in the process I
installed the 3.51 foundation set and the 3.51m upgrade (FIX DISK 2.0).
For some reason, my external modem is now exhibitting a strange behavior
that wasn't there before.
With the uugetty running on the tty (tty002), when I try to place an
outgoing call, the modem (a Hayes) sends an OK\r Result Code, and the uugetty
sees this and sends return back to the modem, which echoes it back...The
send and receive lights on the modem end up turning on constantly, and if
I do a direct connect to the modem via cu, I see a continual stream of 'OK's
followed by two carriage returns.
Now, this didn't used to happen before, and if I kill the uugetty (remove it
from the inittab) the problem goes away. The question is: Why isn't the
uugetty being put to sleep by UUCP and why is it playing this game of
tag with the modem? I noticed in the FIX DISK that a number of potential
culprits were updated: setgetty, getty, login, init.
I'm using the suggested setup for Hayes 2400 Smartmodems which was posted
to the net about six months ago (CLOCAL is disabled, etc). It worked fine
before, but now I'm getting this strange echo problem.
Any ideas out there?
--
Marc Weinstein
{simon,royko,tellab5}!linac!fithp!mhw Elmhurst, IL
-or- {internet host}!linac.fnal.gov!fithp!mhwdnichols@ceilidh.beartrack.com (DoN Nichols) (03/13/91)
In article <1991Mar12.054212.554@fithp.uucp> mhw@fithp.uucp (Marc Weinstein) writes: >I just switched over to a 3b1 from my old UNIX PC, and in the process I >installed the 3.51 foundation set and the 3.51m upgrade (FIX DISK 2.0). >For some reason, my external modem is now exhibitting a strange behavior >that wasn't there before. > >With the uugetty running on the tty (tty002), when I try to place an [ ... ] Did you install the fixdisk on top of an already installed HDB uucp? If not, where did the uugetty come from? When I've rebuilt, I've installed 3.51, the development system, FIXDISK2.0+IN, and then HDBuucp. I don't know it the standard uucp and cu know about uugetty. Good Luck DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
cjp@beartrk.beartrack.com (CJ Pilzer) (03/14/91)
References: <1991Mar12.054212.554@fithp.uucp> <1991Mar13.014602.23303@ceilidh.beartrack.com> I have had the same problem with a Hayes Smartmodem 2400 which is connected to the tty000 port on my 7300. I am running 3.51m, but had the same trouble with 3.50 and 3.51. I am not using HDB, but uugetty seems to run just as it should with the Smartmodem internal strap set to dumb so that it echos nothing. If the strap is so set I can not use any chat scripts. If I change the internal strap, even if the modem is configured ATQ1E0, after the first incomimg call the RD and SD leds seem to be full on. I think that they are blinking very fast due to echo and response from the computer to the modem and back. What I think whqt starts this is the RING response on the call in. The dumb strap stops this. I think the sequence is : m RING c Welcome to the AT&T UNIX pc c Please login: m Please login: c sends error message m echos error message c sends error message m echos error message ..... If the port is disabled the loop stops, (of course, the modem will still answer callins as long as S0>0 ), but the computer won't run /bin/login. I haven't been able to solve this. -- cj cjp@ursaco.beartrack.com uunet!beartrk!ursaco!cjp
floyd@ims.alaska.edu (Floyd Davidson) (03/14/91)
In article <460@beartrk.beartrack.com> cjp@beartrk.beartrack.com (CJ Pilzer) writes: > > >References: <1991Mar12.054212.554@fithp.uucp> <1991Mar13.014602.23303@ceilidh.beartrack.com> > >I have had the same problem with a Hayes Smartmodem 2400 which is connected >to the tty000 port on my 7300. I am running 3.51m, but had the same trouble >with 3.50 and 3.51. > >I am not using HDB, but uugetty seems to run just as it should with the >Smartmodem internal strap set to dumb so that it echos nothing. If the >strap is so set I can not use any chat scripts. If I change the internal >strap, even if the modem is configured ATQ1E0, after the first incomimg call >the RD and SD leds seem to be full on. I think that they are blinking very >fast due to echo and response from the computer to the modem and back. The modem needs to be optioned to not echo commands and to not send response messages. The modem also must be configured to reset and go to the command mode whenever DTR is dropped. And you need to write that configuration to the eeprom or nvram or whatever it has. I'm writing this without any modem books at hand, so... Floyd -- Floyd L. Davidson | floyd@ims.alaska.edu | Alascom, Inc. pays me Salcha, AK 99714 | Univ. of Alaska | but not for opinions.