dave@andromeda.RUTGERS.EDU (Dave Bloom) (08/11/86)
<>
What we have: A 3B5 running SVR2 with Honey-Danber UUCP, and a
number of hayes compatible modems.
The problem: When we set up a modem to be both a dial-in and dial-out,
the dialing out seems to work fine. However, when one
dials in, it seems to work once or twice, and then not
at all until someone dials out again.
The symptoms: The modem will answer, then immediately drop the line.
Conjecture: Every time another modem rings our modem, our modem sends
a "RING" message to the port. Whenever another modem con-
nects with it, it sends a "CONNECT" message to the port.
Meanwhile uugetty thinks these are login attempts and by
that time has sent a "Login incorrect" message back to
the modem. The modem sees the message, thinks its a
disconnect command, drops carier, and sends a "NO CARRIER"
message back to the port. This continues until the login
times out, but noone is ever able to log back in.
Sidenotes: The uugetty command we're using: uugetty -r -t 60 contty 1200
I have tried writing Dialer scripts, using permutations of
the -h flag for uugetty and removing/adding HUPCL from the
gettydef.
Plea: Anyone with ANY ideas, please contact me via e-mail or the
phone number below.
--
harvard\ pyramid\ Dave Bloom
seismo \ pyrnj \
ut-sally >!topaz >!andromeda!dave Office: (201) 648-5083
allegra / caip /
ihnp4!packard/ yogi/ "You're never alone with a schizophrenic...."randy@chinet.UUCP (randy) (08/13/86)
In article <529@andromeda.RUTGERS.EDU> dave@andromeda.RUTGERS.EDU (Dave Bloom) writes: ><> > >What we have: A 3B5 running SVR2 with Honey-Danber UUCP, and a > number of hayes compatible modems. >The symptoms: The modem will answer, then immediately drop the line. >Conjecture: Every time another modem rings our modem, our modem sends > a "RING" message to the port. Whenever another modem con- > nects with it, it sends a "CONNECT" message to the port. Hayes compatible modems don't like their status commands echoed back to themselves. They hang up. Uugetty echo's the connect and ring strings back to the Hayes, and it gets confused and gives up. To make Hayes compatibles work on my 3b2 with dial in/out and uugetty, I built a black box that uses a couple of one shots that trigger on CD changing. Then set the hayes (and Dialers) for no call progress monitoring. Been working fine for a year. I would be interested in anyone who was able to get a 3b2 to dial in/out on one line with only software patches. I tend to fix software problems with hardware. PS. Has anyone heard the rumors that AT&T now has a way to expand a 3b2/300 to more than 2 hard disks? Any prices? Thanks. -- .. that's the biz, sweetheart... Randy Suess chinet - Public Access UN*X (312) 545 7535 (h) (312) 283 0559 (system) ..!ihnp4!chinet!randy
heiby@cuae2.UUCP (Ron Heiby) (08/14/86)
The last time I checked with our top tier of UNIX system support,
they had investigated the use of the Hayes modems quite extensively
and could come up with no *reliable* method of making them work
bi-directionally. They work fine in an incoming only or outgoing
only environment. You can kludge something into the login prompt
in /etc/gettydefs to change the modem's mode around that makes it
work bi-directionally except for the first incoming call after an
outgoing call. The solution I opted for was the AT&T 2224B modem
with autodialer. It worked bi-directionally at 1200 and 2400 bps
(didn't try the 300 bps, yuck) right out of the box with the factory
default configuration. I suppose it is a bit more expensive than
a Hayes, but probably not more expensive than two Hayes. (I'm not
a salesperson and don't know pricing.)
Re: the hard disk expansion, there is an expansion board that plugs
into one of the I/O expansion slots in the 3B2 (4 in 300/310, 12 in 400)
called the XDC for eXpansion Disk Controller. Each XDC can control
up to two of the same drives that we support for the integral hard
disk controller, i.e. 30Meg and 72Meg. As to price, see comment at
end of the previous paragraph.
--
Ron Heiby {NAC|ihnp4}!cuae2!heiby Moderator: mod.newprod & mod.os.unix
AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
"'Cause there's lots of things in this world that need to BE turned around."dbw@mtuxo.UUCP (d.wood) (08/14/86)
How about making a special /etc/gettydefs line without "ECHO", and connecting that to the line in /etc/inittab? existing gettydefs line: 1200# B1200 HUPCL IGNPAR ISTRIP ICRNL OPOST ECHO ICANON CS7 # \ B1200 SANE IXANY TAB3 #\rlogin: #1200 new gettydefs line: H1200# B1200 HUPCL IGNPAR ISTRIP ICRNL OPOST ICANON CS7 # \ B1200 SANE IXANY TAB3 #\rlogin: #H1200 ^^^^ "ECHO" missing! new inittab line: 001:2:respawn:/etc/ugetty -t 60 tty001 H1200 # Hayes modem, no echo Dave Wood
wescott@sauron.UUCP (08/15/86)
The Hayes modems don't like to get echos from their connect messages. There are several approaches that I could recommend, none of which are completely satisfactory. These suggestions apply to SysV only (in fact, the HDB uugetty claims not to work with BSD). #1. Set up the modems for quiet operation, disabling result codes and echo while waiting for activity. Then modify the dial script to enable result codes and perhaps turn on echo. I have not tried this approach. It may not work for Hayes 1200 modems because this relies upon the cycling of DTR to cause the modem to "reset" back to the non-echo, no-result-code state. The Hayes 2400 baud modems should work OK. #2. Modify uugetty. Add an optional digit sequence to the -r option which tells uugetty how long to wait after receiving its first input before doing anything. This has several problems but does work. uugetty has been changed here to sleep the specified number of seconds and then to flush input and then to wait for a char- acter. This can confuse uucico's that are calling out because a number of characters may not get echoed back to uucico during a dial sequence. #3. Modify uucico and the tty drivers. Another change that I am ex- perimenting with is to permit uucico to issue dial sequences in clocal mode (no DSR/DCD required) and then to wait for carrier after completing the dial sequences. The hacks include adding a flags to the Devices file to indicate when clocal is to be used and when to wait for DSR/DTR to be turned on. Then the drivers need to be modified so that a uugetty on the same line (not using the -r option) will have its open complete when DCD does come up. (This was discussed earlier, but not wrt uugetty). -- -Mike Wescott ncrcae!wescott
romain@pyrnj.uucp (Romain Kang) (08/16/86)
One problem in using modems bidirectionally (which Peter has noted)
is that there is currently no Devices.exit script. Thus, if you
have a modem set for quiet mode but change it to a chatty state
in order to dial efficiently there is no way, for example, to send
an "ATZ" to a Hayes 1200 once you have finished talking.
There are some modems (e.g., the Hayes 2400) that perform a reset once
you close the device and drop DTR. It seems conceivable that you could
leave the modem set up for quiet mode, but then put a dialer
initialization sequence in the Devices file to get chatty mode, and let
the modem reset itself to an acceptable state when finished. (I once
tried this on a BSD system sith 4.3 uucp; restarting the getty was
chancy since the Hayes 2400 took several secondsto ATZ and come back,
I got "getty failed; init sleeping"...)
This matter raises the question of how a one-dimensional dialer script
can cope with some of the fancy devices modems coming out. Do we need
to implement a state machine that can handle initialization, resetting,
speed and protocol changes? For example, many of the 2400 bps modems
will change their interface speeds when they detect a 1200 bps carrier
at the other end. Then there are devices with internal protocols like
MNP (Microcom) or PEP (Telebit). In many of these cases, it seems
incumbent on the host software to adapt to make best use of these
channels or even operate at all.
Peter didn't feel it would be worth the time and effort to graft
in a mechanism for this sort of purpose. I guess he thought it the
best solution is to buy reasonable hardware. My own feeling is that
the people with the resources and knowledge to deal with this problem
also have the resources to bypass such mundane issues as using
bidirectional modems. Those of us with the desire to handle
such things don't have the time (or perhaps the source code...)
--
Romain Kang {allegra,cmcl2,mirror,pyramid,topaz}!pyrnj!romain
Pyramid Technology Corp / 10 Woodbridge Center Dr / Woodbridge, NJ 07095
"Eggheads unite! You have nothing to lose but your yolks!" -Adlai Stevenson