UUCP Help (LONG)
Thad P Floryan
thad at cup.portal.com
Sat Jan 6 22:57:06 AEST 1990
fmcgee at cuuxb.ATT.COM (Frank McGee) in <4415 at cuuxb.ATT.COM> comments on my
comments about the HDB UUCP suite's problems concerning assumptions about
modem operation.
Frank, I appreciate your taking the time to reply publicly. I have since
"cooled down" but my assertions and opinions haven't changed, and for good,
sound, technical reasons.
I believe you and others deserve an explanation why I posted the original
comments. I'll attempt to describe the technical problems as simply and as
succinctly as possible under the circumstances, so please bear with me.
This IS a long posting, but there's material and examples in here (and even
some humor! :-) that may be of benefit to many.
I started with version 2 uucp (L.sys, L-devices, etc.). My modems are
connected with all RS-232 wires straight thru between modem and systems.
After constructing rather complex modemcap entries which succeed to ALL
systems I needed to call, all works fine for several years. I became quite
an expert with modemcap and shared that expertise with many who needed help.
Now with 5 systems and multiple terminals, plotters, printers, etc. I needed
a LAN. So back in October 1989 I equip everything with AT&T StarLAN; this
includes Network Access Units (NAUs), Network Interface Units (NIUs), and
Network Extension Units (NEUs). The NAUs plug into the computers; the NIUs
(aka RS-232c NAUs) connect terminals and some modems and printers; the NEUs
serve to isolate legs of the network should I disconnect or reconfigure
anything (esp. when I bring one or two systems to the AT&T Users' Group at
the AT&T West Coast Training Center). At this point I'm still using the
version 2 uucp suite.
Initial performance tests of the StarLAN were disappointing, averaging 2K
bytes/sec for inter-system uucp file transfer. My posting to the net elicited
response suggesting use of the uucp "e" protocol which is available only with
the HDB uucp suite. So I finally install the HDB software, select the "e"
protocol for StarLAN connections, and now enjoy average inter-system uucp
transfer rates between 30K and 40K bytes/second. All's fine so far.
Because most of my "global" file transfers the past year or so are FTP via
the Internet, my "external" uucp usage has been minimal, but there still are
systems I must contact via traditional uucp means.
So now we're at the end of December 1989 when I read ALL the information that's
available for configuring the HDB uucp suite. This includes:
AT&T UNIX System V Release 3.2 System Administrator's Guide
(c)1989, ISBN 0-13-944794-6
AT&T UNIX System V Release 3.2 System Administrator's Reference Manual
(c)1989, ISBN 0-13-944861-9
AT&T UNIX System V Release 3.2 Streams Programmer's Guide
(c)1989, ISBN 0-13-944810-1
AT&T UNIX System V Network Programmer's Guide
(c)1987, ISBN 0-13-940461-9
UNIX System Administration Handbook (Nemeth, Snyder, Seebass) Prentice Hall
(c)1989, ISBN 0-13-933441-6
UNIX System Security (Wood & Kochan) Hayden Books
(c)1985, ISBN 0-8104-6267-2
UNIX Networking (Wood, Kochan, et al) Hayden Books
(c)1989, ISBN 0-672-48440-4
LOCAL NETWORKS, An Introduction (William Stallings) Macmillan
(c)1987, ISBN 0-02-415520-9
Managing UUCP and Usenet (O'Reilly & Associates) Nutshell
(c)1988, ISBN 0-937175-09-9
Using UUCP and Usenet (O'Reilly & Associates) Nutshell
(c) 1987, ISBN 0-937175-10-2
And, of course, the docs and man pages that accompanied the HDB software.
To my surprise, the Nutshell books were NOT helpful with configuring HDB uucp;
they WERE helpful with the older version 2 UUCP suite. For example, the
Nutshell books don't even acknowledge the existence of /usr/lib/uucp/Sysfiles.
In any event, after several days of reading, I figured just a few minutes'
time would be required to configure the files and be up and running. Per
the available documentation (above) everything looked straightforward. So
here's what I had after that "few minutes" (I'm NOT showing most StarLAN
entries here, and I'm not showing the files' comments unless they're pertinent
to this discussion (to reduce the size of this posting)):
/etc/inittab:
000:2:respawn:/usr/lib/uucp/uugetty -r -t60 tty000 9600
001:2:respawn:/usr/lib/uucp/uugetty -r -t60 tty001 9600
002:2:respawn:/usr/lib/uucp/uugetty -r -t60 tty002 9600
:003:2:respawn:/usr/lib/uucp/uugetty -r -t60 tty003 9600
004:2:respawn:/usr/lib/uucp/uugetty -r -t60 tty004 9600
/usr/lib/uucp/Sysfiles:
service=cu systems=Systems.cu:Systems \
devices=Devices \
dialers=Dialers
service=uucico systems=Systems.uucico:Systems \
devices=Devices \
dialers=Dialers
NOTE: Systems.cu and Systems.uucico contain ONLY StarLAN entries.
NOTE: system names and phone numbers (below) are fictitious (for this posting)
NOTE: only ONE Systems entry is shown for clarity
/usr/lib/uucp/Systems:
# public systems entries for uucp
#
callme Any ACU 9600 14085551212 "" \r\d\r\d\r\d ogin: Uanon
/usr/lib/uucp/Devices:
ACU ph0 ph0 1200 PC7300 \T
ACU tty000 - 9600 ark24k
Direct tty001 - Any direct
Direct tty002 - Any direct
Direct tty003 - Any direct
Direct tty004 - Any direct
STARLAN starlan - Any STARLAN
STARLAN_NAU,eg starlan - Any STARLAN \D.serve pc_uucp
STARLAN_UU,eg starlan - Any STARLAN \D.serve SLAN_uucico
/usr/lib/uucp/Dialers (the "..." denote omitted lines):
# @(#)uucp:Dialers 2.1
...
# Meaning of some of the escape characters:
...
# \M - set CLOCAL mode (as initial token does NDELAY open)
# \m - unset CLOCAL mode
...
direct
# Hayes Smartmodem -- modem should be set with the configuration
# switches as follows:
#
# S1 - UP S2 - UP S3 - DOWN S4 - UP
# S5 - UP S6 - DOWN S7 - ? S8 - DOWN
#
hayes =,-, "" \dAT\r\c OK\r \EATDT\T\r\c CONNECT
#
# Digicom 9624LE V.32 (MNP 5)
digicom =W-, "" \dAT\r\c OK\r \EATDT\D\r\c CONNECT
#
# ARK 24K (DTE rate fixed at 9600, modem rate varies per connection)
ark24k "" "" \r\c > dt\D\r\c CONNECT
...
# System85 data module
PDM =+ "" \K\p\p\r\c DIAL:-\K\p\p\r\c-DIAL: \M\T ANSWERED \m\c
#
# STARLAN dialers
STARLAN_NIU "" "" \r\d\r\d\r DIAL:-\r\d\r\d\r-DIAL: \D "" \d\d\c
pc_uucp "" "" NLPS:000:001:102\N\c
SLAN_uucico "" "" NLPS:000:001:101\N\c
SLAN_login "" "" NLPS:000:001:1\N\c
nls "" "" NLPS:000:001:1\N\c
...
# datakit which keeps DCD down until speed is set
# datakit "" "" \M\r\d\r\d\r TION:--TION: \m\D "" \d\d\r
...
OK, everything looks clean and sweet. All I added to Dialers were the
entries for "ark24k" and "digicom".
At this point, still the same modem cabling, ports, etc. that were used for
many years under version 2 uucp. As a reference point, my system is asserting
DTR, and the modem's DSR and DCD are "down" (as they SHOULD BE since there's
no active communication).
First test was to call INTO my system from a terminal and another modem;
works fine. Next test was to call out and I chose to use the latest Pcomm
that was just installed, and it dialed out just fine through tty000. Great!
Now things start to go bonkers:
1) $ cu callme
2) Connect failed: CANNOT ACCESS DEVICE
3) $ /usr/lib/uucp/uucico -r1 -x 9 -s callme
mchFind called (callme)
list (rmail) num = 1
name (callme) not found; return FAIL
list (rmail) num = 1
list (/usr/spool/uucppublic) num = 1
list (/usr/spool/uucppublic) num = 1
list (/) num = 1
list (rmail) list (rnews) list (lp) list (uucall) num = 4
_Request (FALSE), _Switch (TRUE), _CallBack (FALSE), _MyName (),\
_Commands rmail
_Commands rnews
_Commands lp
_Commands uucall
chdir(/usr/spool/uucp/callme)
conn(callme)
Device Type ACU wanted
mlock tty000 succeeded
timed out
generic open timeout
set interface UNIX
getto ret -1
Call Failed: CAN'T ACCESS DEVICE
exit code 101
Conversation Complete: Status FAILED
TM_cnt: 0
4) $ /usr/lib/uucp/Uutry -x 9 callme
/usr/lib/uucp/uucico -r1 -scallme -x9 >/tmp/callme 2>&1&
tmp=/tmp/callme
mchFind called (callme)
list (rmail) num = 1
name (callme) not found; return FAIL
list (rmail) num = 1
list (/usr/spool/uucppublic) num = 1
list (/usr/spool/uucppublic) num = 1
list (/) num = 1
list (rmail) list (rnews) list (lp) list (uucall) num = 4
_Request (FALSE), _Switch (TRUE), _CallBack (FALSE), _MyName (),\
_Commands rmail
_Commands rnews
_Commands lp
_Commands uucall
chdir(/usr/spool/uucp/callme)
conn(callme)
Device Type ACU wanted
mlock tty000 succeeded
timed out
generic open timeout
set interface UNIX
getto ret -1
Call Failed: CAN'T ACCESS DEVICE
exit code 101
Conversation Complete: Status FAILED
TM_cnt: 0
Needless to say, I spent a *LOT* of time trying to track down this problem.
A lot of time. Nothing in ANY of the above-listed docs provided any clues
or hints as to what could be wrong. Using Pcomm again, I was able to dial
out just fine, so that proved my wiring and modem were operational.
Was just about to give up on HDB uucp and delegate one system as a gateway for
only outside uucp traffic (using the version 2 uucp suite on that one system)
when I started looking at some of the other entries in Dialers.
Hmmmm, what's this comment "datakit which keeps DCD down until speed is set"?
Hmmmm, what's this about Hayes modems needing DIP switch 6 down?
Back to the docs.
The "datakit" entry included "\M" and "\m". WTF!? NOT ONE of the references
cited at the beginning of this posting showed those 2 items as valid. NOT ONE.
Your SysV '386 R3.2 book may show it, but the SysVR3.2 books I have don't.
Looking at a Hayes modem manual (remember, I have to make my own products work
with hundreds of different kinds of modems), I find the entry for DIP SW 6:
" DOWN RS-232C Carrier Detect lead will be logic TRUE at all times
even if there is no carrier signal.
"
Now I'm asking myself: "What were those guys smoking when they dreamed up
these bizarre scenarios? This, from AT&T? Sheesh." This is after some
14 hours of diddling with everything software to get the HDB to dial out.
Now I see the "en passant" reference to "\M" and "\m" concerning CLOCAL at
the top of Dialers. OK, nothing else succeeded, so let's replace the "old"
modem entry with the following entry using \M and \m:
ark24k "" "" \M\r\c > dt\D\r\c CONNECT \m
into Dialers and try:
$ cu callme
Connect failed: CAN'T ACCESS DEVICE
Sheesh. NOW it's time for a hardware solution. So I get the sledgehammer,
chainsaw, radial arm saw, and ... I'm about ready to dance under the full
moon in my jockey shorts while swinging a dead chicken over my head while
facing East towards Murray Hill, NJ :-)
Now it's time to look at the SVID manuals to see if they say anything; nada,
though there are some good comments re: CLOCAL in Volume 1. (FYI, the SVID is
the System V Interface Definition 3-volume set).
In any event, I put a Data Line Monitor and break-out box on the damned RS-232
line to see what's happening there during the HDB cu and uucico attempts. Not
a very pretty sight. To summarize: I temporarily hotwired the system's DTR
signal back into its DSR and DCD (isolating the DSR and DCD signals from the
modem), then:
$ cu callme
Connected
2400
Callme online. Press return to continue
~[thadlabs].
Disconnected
$
Sheesh. I *STILL* maintain that for AT&T software to INSIST that a modem be
so hot-wired is stupid, stupid, stupid, stupid. BTW, this successful connect
is still with the \M and \m in the Dialers.
I also got the "cu" to work by jumpering to "Assert DCD always" in the modem
itself, but it is unbelievable to me that AT&T software would controvert all
the great AT&T hardware (modem) control standards that AT&T established over
the years.
I have copies of all those AT&T hardware and modem manuals, and it now seems
that everyone *BUT* AT&T still treats those docs as the "Datacomm Bibles".
Frank comments that by disconnecting (or otherwise dropping) the connection,
the modem will respond "DISCONNECTED." OK, it does, BUT who is going to see
that message? Not uucico. The hardware signal (loss of DCD) is *THE* correct
signal to assert loss of carrier.
If the remotely called system should go down, its modem is (probably) going
to stay up, and now during a uucico the line will remain active even though
there's no continuing, ongoing traffic. THIS IS WHY my original posting was
so harsh.
"In band" control signals (a la Hayes) are simply no damn good. Even AT&T
recognized this regarding phone switching after the days of ol' Cap'n Crunch
with his toll-fraud schemes, and now the inter-office and trunk and whatever
switching is "out of band" (much like an RS-232's connection DTR, DSR, DCD,
etc. are "out of band.")
I'm NOT satisfied with the kludge hot-wiring the DCD signal for HDB uucp.
If I could afford the $$$ source license I'd fix the HDB problem myself.
Public comments are invited.
Frank also comments about AT&T UNIXPC support; as many here have read, I've
been publicly complimentary of ALL support I've received from the HotLine.
My gripe concerned ONLY the HDB uucp suite (which is NOT an "officially"
supported product on the UNIXPC) whose vagaries seem to ALSO plague the other
AT&T systems (yes, I've looked at a 3B2 Dialers file! :-)
Thad Floryan [ thad at cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
More information about the Unix-pc.general
mailing list