Xref: utzoo unix-pc.general:4462 unix-pc.uucp:213 comp.sys.att:8423 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!brutus.cs.uiuc.edu!apple!fox!portal!cup.portal.com!thad From: thad@cup.portal.com (Thad P Floryan) Newsgroups: unix-pc.general,unix-pc.uucp,comp.sys.att Subject: Re: More on my UUCP problems Message-ID: <25729@cup.portal.com> Date: 8 Jan 90 16:32:40 GMT References: <25695@cup.portal.com> Organization: The Portal System (TM) Lines: 195 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 ]