More on my UUCP problems

[Thad P Floryan]

Andrew at cup.portal.com (andrew scott lagodzinski) in <25695 at 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 at cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]