Path: utzoo!utgpu!tmsoft!spectrix!clewis From: clewis@spectrix.UUCP (Chris Lewis (It's loose again!)) Newsgroups: comp.unix.microport Subject: Re: Microport Sys V/AT continuous receive and send modem hang Message-ID: <687@spectrix.UUCP> Date: 27 Jun 88 18:37:20 GMT References: <2179@sugar.UUCP> Reply-To: clewis@spectrix.UUCP (Chris Lewis (It's loose again!)) Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada Lines: 34 In article <2179@sugar.UUCP> karl@sugar.UUCP (Karl Lehenbauer) writes: |I just had something interesting happen. I have posted before and many |times seen receive and send lights running continuously just after a |hangup and especially if output was being done to the modem. This time, |it ran continuously for minutes. Both received data and send data LEDs |are almost solidly. | ... but my guess |is that the the modem maybe sent the string "DISCONNECTED" or something, |the driver echoed it back (it's full duplex after all) and the modem |echoed it back, ad infinitum. Even more likely: "getty" said "login:", the modem echoed "login:", getty echoed "login:" ad nauseum. Possibly sprinkled with "ERR", "password:", "OK" etc. Generally speaking if you're trying to do bidirectional stuff with a modem, make absolutely certain that the modem is always told to not echo when in "getty" state. Most people simply have the modem told to never echo either by switch setting or by non-volatile option settings. If you attempt to cu out and turn echo on (eg: ATE1 on a hayes), you have to remember to turn it off before letting getty start up. You sometimes have to turn "responses" off too. Microport has some magic about minor numbers which allow both getty and outgoing stuff to open the device simultaneously, but I'm not sure that this has any bearing on how you have things setup. We simply have echo and responses turned off by switch setting and leave it at that. -- Chris Lewis, Spectrix Microsystems Inc, Phone: (416)-474-1955 UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis Moderator of the Ferret Mailing List (ferret-list,ferret-request@spectrix)