From: jpr@jpradley.jpr.com (Jean-Pierre Radley)
Subject: Re: Worldblazer not autobauding correctly at 38400
Date: Thu, 24 Dec 1992 23:18:53 GMT
Organization: Unix in NYC

In article <BzIvEF.E9@wsrcc.com> wolfgang@wsrcc.com (Wolfgang S. Rupprecht) writes:
>brad@clarinet.com (Brad Templeton) writes:
>>Sorry for making you type such a long message, but I of course have the
>>modem set in &D3 mode, and have always set my modems that way for years.
>>I can't imagine setting a modem any other way and feeling safe.
>>And yes, DTR is definitely dropping, for a full second, before the new
>>getty takes over, and then, as far as I know, nobody is talking to the
>>modem before the call comes in.
>
>On a TB+ I noticed reset problems with exactly the same setup.  I
>wonder how much of the TB code the WB inherited.
>
>Two things that I found helped a lot:
>
>1) configure the kernel to keep DTR low for much more than 1 second.
>   The TB just didn't reset reliably even at 3 seconds.  I finally
>   picked 7 seconds as a good compromised between resetting and dying
>   of boredom on a tip(1) redial.
>
>2) *Never* let anyone use the manual disconnect switch on the modem.
>   This thing causes the DTR reset to be totally ignored.
>
>3) Don't let anyone that doesn't have a trailblazer call in. ;-) My
>   biggest problems were the modem being stuck in PEP mode w.
>   uucp-spoofing on after a uucp call out.  The next call, if it was a
>   plain-jane 2400 baud modem couldn't connect.
>

How and where does one reconfigure an SCO kernel to change the DTR
drop-time?

Brad's remark about "nobody is talking to the modem before the next call
comes in" make me observe that getty itself talks to the modem, using the
-h flag to a dialer binary, or a hangup chat script.


Here's a message from biz.sco.general, AKA the SCO mailing list:

>Subject: non-answering modem solution
>Message-Id: <1.dond@sco.com>
>Date: 	Tue, 5 May 1992 18:26:42 -0400
>Organization: The Santa Cruz Operation, Inc.

Here's an easy and little-known solution to a common modem problem.
It took me a long time to solve this one.  Hope it comes in handy
and saves you some of the frustration that this cost me...

After I call out on my modem, it no longer answers the phone.

KEYWORDS: uucp honeydanber devices ttys xenix unix auto answer reinitialize -hflag dialer uuchat not called acu

RELEASE:  SCO XENIX Operating System Release 2.3.0 through 2.3.4
	  SCO UNIX System V/386 Release 3.2 Operating System Version 4.0 and
	  earlier
	  SCO Open Desktop Release 2.0 and earlier

PROBLEM:  My modem isn't being reinitialized for dial-in.  Disabling
	  and re-enabling the port doesn't help.   The modem must be
	  turned off and on before it will answer the phone again.

CAUSE:    Whenever getty (or uugetty) is run, it checks the file
	  /usr/lib/uucp/Devices to see if the tty port it is running
	  on is a modem port.  If it finds the tty device in the Devices
	  file, then getty checks to see if a binary dialer or Dialers 
	  file entry is being used.  If one of these is found, then getty
	  attempts to hang up the modem line and initialize the modem for
	  the next caller.  If a binary dialer is specified on the Devices 
	  file line, then getty calls that dialer with the "-h" flag.  If 
	  a Dialers file entry is specified instead, then getty calls uuchat,
	  passing it the "&" line from the Dialers file entry.

	  getty uses the first entry which it finds in the Devices file.
	  The tty device name is "regularized" (i.e. tty1a and tty1A are
	  considered equivalent).  This means that if an entry such as:

	  Direct tty1a - 2400 direct

	  appears before the ACU entry for the same tty port, such as:

	  ACU tty1A - 2400 hayes2400 \D

	  then getty will decide that no binary dialer or Dialers file
	  entry is being used - and the modem won't be initialized for
	  dial-in.

	  It is worth mentioning here that the device names in both
	  /usr/lib/uucp/Devices and /etc/inittab should not contain
	  the "/dev/" prefix.  For example, "tty1A" should be used;
	  not "/dev/tty1A".  If the tty device appears as "tty1A" in
	  /etc/inittab, and as "/dev/tty1A" in the Devices file, then
	  getty will not find it, and will treat the tty device as
	  a terminal rather than as a modem.

SOLUTION: Make sure that the "ACU" entry for the modem control port
	  in /usr/lib/uucp/Devices contains the desired binary dialer
	  name or Dialers file entry name and appears before any other
	  entries for this port, including any "Direct" entries for the
	  port's non-modem control counterpart.  This "ACU" entry ("ACU"
	  is the typical label, it could have another label such as
	  "RESET") should also specify the correct speed for 
	  reinitializing the modem.

-
Don Draper		Support Engineer
dond@sco.COM	 Modem Technical Feature Specialist
uunet!sco!dond	 The Santa Cruz Operation, Inc.
-- 
Jean-Pierre Radley   Unix in NYC   jpr@jpr.com   jpradley!jpr   CIS: 72160.1341
Newsgroups: comp.dcom.modems