Andrew@cup.portal.com (andrew scott lagodzinski) (01/07/90)
I have had many replies to my original call for help with my UUCP
connection problems. I am still having problems, but I now have more
information on the problem. First I am running the stock UUCP that came
with version 3.51 of the UNIXPC OS. I am using a Micom dial series modem,
it claims to be Hayes AT compatible and I have had no problems with it in
over a year of use on my Amiga, and recently with my UNIXPC.
Some people have suggested that I set 'DCD' to be high always from
the modem. I have never before seen a reference to 'DCD', but I am assuming
that this and carrier detect are one and the same. At first I tried setting
this with a hardware switch, but this caused problems because the UNIXPC
thought that someone was tring to LOGIN on tty000. This was bad and brought
the system to it's knees.
As I was typing this note I thought about the Fixdisk to bring the
system up to 3.51a. I remember having some problems with the installation
of this package on my system. I just double checked my system and come to
find out that the copy I recieved of the Fixdisk was not complete. It is
missing the uucico replacement that is supposed to fix the following...
../fixdisk/uucp/Info ...
The uucp (/usr/lib/uucp/uucico) has fixes for the following:
-uucico hangs at call completion
-uucico turns modem speaker on
-time stamps incorrect in LOGFILE
The problem I have been experencing may or may not be fixed by the
newer version of uucico. If this is the problem I am truly sorry to have
wasted so much of everyone's time on this.
What I am experencing is that uucico, not the modem, is hanging up the
line. I feel this is the case because uucico makes two attempts to dail out
and on the second attempt I get a connection with the modem, but uucico seems
to have timed out. It then appears (I have no way of checking) that the UNIXPC
tries to LOGIN because there is a carrier detect on tty000. This of course
fails because Ohio-State is trying to LOG my machine in.
I have tried setting the wait for carrier detect time from 30 seconds
to 60 seconds. I have tried setting the carrier detect high in the dial
command in the modemcap entry...
#sccs "@(#)uucp:modemcap 1.3"
# Hayes smartmodem 1200
# Name=hayes
ha|hayes|hayes 1200:tr=\r:wp=\r:wk=K:wt=T:\
:ta=AT\r:tb=AT&C0DT:\ <--added the '&C0' here
:es=\r:\
:d1#1:d5#5:\
:pl=trwpd1tad1wpwpwkwptbphtrwpwpwttr:
This doesn't seem to change the behavior of uucico. I am truly stumped as
to how to get uucico to hang around long enough to see the carried detect from
the modem. HELP!!
Andrew Lagodzinski andrew@cup.portal.com or ..!sun!cup.portal.com!andrew
413 Pinehurst Ave. "RHYTHMATISM" is the study of patterns
Los Gatos, Ca 95032 that weave the fabric of lifethad@cup.portal.com (Thad P Floryan) (01/09/90)
Andrew@cup.portal.com (andrew scott lagodzinski) in <25695@cup.portal.com>
reports the additional (and necessary) information about his uucp problem.
First, Ohio State is NOT the best system to use for debugging one's uucp
problems; it's long-distance, and IT has a problem with its answering modems.
Several years ago I corresponded with Bob Sutterfield (and Karl Kleinpaste),
the chief gurus of (now) {cheops | saqarra | tut}.cis.ohio-state.edu about
the problem. Bob has since left, and Karl now runs the show. At osu-cis,
another group controls the incoming Micom switch (per Bob's info).
The osu-cis "problem" is that the modems on the Micom switch are set to answer
after 2 or 3 rings and NOT on the first ring as is customary at other sites.
This means you're going to wait through 20-30 seconds of ringing before osu-cis
answers the phone; this time delay is what kills most uucp attempts.
For a Hayes-compatible modem at YOUR site, you can program S-register 0 to
wait a bit longer before reporting "NO ANSWER", and you've got to hold-off
uucico's timing out.
For example:
ATS0=2 will set YOUR modem to answer on 2 rings when someone calls
you, and will set YOUR modem to wait for 4 (yes, four, as in
register value + 2) rings before aborting a call attempt.
And, since Andy said he's using version 2 uucp, below is the modemcap entry
for my Ark modem that works into every system I called, including Ohio State.
I *did* say I like to write COMPLETE scripts! :-)
This modemcap entry has TOTAL control of the modem and its call progress,
aborting QUICKLY if there are, in fact, problems; receipt of a "CONNECT" is
the only defaulting non-abort way out of it.
BTW, that "abort" capability is something that's sorely LACKING with HDB uucp.
The points I want to emphasize in this script are the TIME DELAYS (d1, d5,
d9; for 1, 5 and 9 seconds respectively) that were necessary to get into Ohio
State, which I consider the most troublesome of all sites I've ever called.
THIS script won't, of course, work for a Hayes(-compatible), but one CAN
adopt the same strategies in one's own "/usr/lib/uucp/modemcap" file:
# ARK 24K, normal mode (not Hayes) with MNP
#
# S0=2 to answer after 2nd ring and to wait for up to 4 rings on callout.
# Modem internally configured to always tone (DTMF) dial.
#
# Name=ark
#
ark|ARK:\
:ab=BUSY:ac=NO CARRIER:ad=NO DIALTONE:an=NO ANSWER:\
:cb=BUSY:cc=NO CARRIER:cd=NO DIALTONE:cn=NO ANSWER:cr=ringback:\
:d1#1:d5#5:d9#9:\
:eh=\r:\
:m5#5:\
:n6#6:n8#8:nf#15:no#24:nt#33:nu#42:\
:ph=D:\
:ts=\b\b\b\b\r:\
:wb=>:wn=\n:wr=\r:\
:pl=d5tswbphd9wnd5wrd5cdadwnwrcbab\
crm5ccaccnannuwnwr\
crm5ccaccnanntwnwr\
crm5ccaccnannownwr\
crm5ccaccnannfwnwr\
crm5ccaccnann6wnwr\
ccaccnand1:
#
Andy continues:
Some people have suggested that I set 'DCD' to be high always from the
modem. I have never before seen a reference to 'DCD', but I am
assuming that this and carrier detect are one and the same. At first
I tried setting this with a hardware switch, but this caused problems
because the UNIXPC thought that someone was tring to LOGIN on tty000.
This was bad and brought the system to it's knees.
No need to force CD high with the version 2 uucp suite (the 'stock' uucp on
the UNIXPC); only HDB (aka BNU) has the DCD (Data Carrier Detect) "problem."
You will also need to "undo" the tty line in /etc/inittab for the line you're
using; version 2's "getty" doesn't "like" bi-directional traffic as does the
uugetty which is part'n'parcel of the HDB uucp suite. Since you said your
modem is on tty000, the line in /etc/inittab looking like:
vid:2:respawn:/etc/getty window 9600
:ph0:2:respawn:/etc/getty ph0 1200
:ph1:2:respawn:/etc/getty ph1 1200
===> 000:2:respawn:/etc/getty tty000 2400
MUST be changed to look like (and the line's initial space OR ``:'' is very
important):
===> :000:2:respawn:/etc/getty tty000 2400
And then you can either reboot your system or you can, while su'd:
# telinit Q
which signals "init" to re-examine the /etc/inittab file (and remove any
getty that's camped on tty000 (in your case)). You should do a "ps -efl"
before and after the telinit to verify what's happening.
Uhhh, another thought just occurred to me: you just "might" still be using
the UA, and, if so, you're better off logging in as ``install'' and do the
``RS-232 Setup'' from the Administration window menu since there ARE some
misc. UA files that should also be altered.
Ask me at the next Users' Group meeting and I'll show how you can login as,
for example, "andy" and go right into the shell of your choice, or login as
"andy ua" and end up in the User Agent instead (this uses a documented
feature of the login program for ALL UNIX systems).
With the version 2 uucp suite (UNIXPC's stock), a tty line can only be in one
"state" at a time; this means it can be configured as a OUTDIALING line or it
can be configured as an INCOMING line, not both simultaneously (as IS possible
using uugetty; BTW, there are some "pd" versions of uugetty-like programs
floating around that you may want to check out).
BTW, `DCD' and `CD' are synonymous; I've been using modems for about 25
years, and back then `DCD' was in the vernacular.
Since you're using 3.51, you don't NEED to bring up the 1.0 FixDisk's uucico
to solve your immediate problem. In fact, on my primary UNIXPC, I only
installed 3.51a this past week; was operating with the stock uucico for years
with no problems (even into Ohio State).
What Andy DOES say that's interesting (and I've observed it too, both with
the stock version 2 uucp and the HDB uucp suites) is:
What I am experencing is that uucico, not the modem, is hanging up the
line. I feel this is the case because uucico makes two attempts to
dail out and on the second attempt I get a connection with the modem,
but uucico seems to have timed out. It then appears (I have no way of
checking) that the UNIXPC tries to LOGIN because there is a carrier
detect on tty000. This of course fails because Ohio-State is trying
to LOG my machine in.
I am truly stumped as to how to get uucico to hang around long enough
to see the carried detect from the modem. HELP!!
The way to see all what's happening is to simply run uucico per (and you don't
have to have anything queued for osu-cis to do this):
$ /usr/lib/uucp/uucico -r 1 -x 9 -s osu-cis
The "-r1" means call in master mode, with debug level 9 (the highest). You
can add the following to the end of the above line to cause the debug output
to be recorded in, say, /tmp/osu-cis:
> /tmp/osu-cis 2>&1
The above is necessary because the version 2 uucp suite doesn't have Uutry.
And you'll probably have to delete the "status" file for osu-cis before running
the uucico per:
$ rm /usr/spool/uucp/STST.osu-ci
^
The missing "s" is not a typo here......|...the version 2 uucp suite doesn't
support full names in all programs.
As a suggestion, you may want to do your uucp testing with a local site.
Since I know you're in Silicon Valley, you may want to test using the
following entry in your /usr/lib/uucp/L.sys file:
# aeras 2400
#
aeras Any ACU 2400 14089439152 "" \r\d\r\d\r ogin: uugarch word: freebee
#
and issue the following command to grab a file from that system:
$ uucp -m aeras!/u3/archive/sources/LISTING.Z ~/aeras/LISTING.Z
^
Uh, by the way, notice this:..........................|....That will cause
you trouble if you're using ksh. What I usually do is have such commands
for systems I call regularly in a script file which I execute per:
ksh> ls -l index.ae*
-rwxr-xr-x 1 thad users 62 May 15 1988 index.aeras
ksh> cat index.aeras
uucp -m aeras!/u3/archive/sources/LISTING.Z ~/aeras/LISTING.Z
===> ksh> sh index.aeras
In any event, I don't know why we're both seeing the "two-dial" two-step
from uucico (both versions). It always appears (viewing the debug output)
the first dial attempt is out-of-sync somehow, and the second one, which
is ALWAYS immediately re-issued by uucico, gets into sync with the modem
and the chat succeeds. Weird.
Hope the above helps!
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]