Andrew@cup.portal.com (andrew scott lagodzinski) (01/03/90)
Hello Again, Once again I call out for help. I am having troubles getting my machine (3B1 ver3.51 OS) connected via UUCP to the archive server at Ohio State. It seems the problem is it take quite a long time for the computer at OSU to answer the phone, and by the time is does my machine has already timed out. I have tried connected to OSU using cu so I know I can connect. I have tried tacking several ":" on the end of the phone number but this does not help. I am using tty000 connected to a micom modem (hayes compatible command set), and have also tried ph0, but ph0 didn't enev dial the phone. I am going to include my L.sys, and LOGFILE if it helps. /usr/spool/uucp/LOGFILE follows... osu!uucp (1/1-20:09:01) (C,671,0) AUTODIAL (/dev/tty000: Interrupted system cal l) osu!uucp (1/1-20:09:01) (C,671,0) FAILED (DIALUP ACU write tty000 P16142923112: < 22) osu!uucp (1/1-20:09:28) (C,671,0) AUTODIAL (/dev/tty000: Interrupted system cal l) osu!uucp (1/1-20:09:28) (C,671,0) FAILED (DIALUP ACU write tty000 P16142923112: < 22) osu!uucp (1/1-20:09:33) (C,671,0) FAILED (call to osu ) /usr/lib/uucp/L.sys follows.... #sccs "@(#)uucp:L.sys 1.1" amiga Any tty000 9600 tty000 "" \d ogin:--ogin:--ogin: nuucp assword: spam osu Any tty000 1200 16142923112: "" \r\c Name? osu-cis nected \c GO \d\r\d\r\d\ r in:--in:--in: Uanon Andrew Lagodzinski andrew@cup.portal.com
thad@cup.portal.com (Thad P Floryan) (01/04/90)
In <25553@cup.portal.com> Andrew@cup.portal.com (andrew scott lagodzinski) discusses problems reaching uucp sites due to uucico timing out. Sigh. The "culprit" is the uucp software itself; I've monitored (using data-line monitors, communications test sets, and breakout boxes) how the DTR line drops just as the modems are beginning their handshaking song-and-dance, and was just as frustrated (with the "stock" version 2 uucp suite). One MUST look at the modemcap file and tailor parameters for one's situation. Andy didn't state what modem he was using (cross-linked from the L.sys and L-devices files), so I hope he calls and/or clarifies with additional info. After a while (several years ago), I got the stock uucp suite working fine on my system by customizing modemcap for my modems. Then I recently switched to HDB uucp and the BOZO ASSUMPTIONS made by that software is enough to put even Mother Theresa on a killing rampage. Loads of UNDOCUMENTED options. Just TRY and find what "\M" and "\m" mean in ANY published AT&T docs; I stumbled upon those in a "misc" Dialers file re: a comment about either forcing a modem to ALWAYS ASSERT DCD or to use the "\M" to force CLOCAL mode by the host computer. Sheesh. Give me a break. That kind of CRAP FROM AT&T? The world's foremost communications company? Assuming a modem MUST always assert DCD even when it's on-hook? Look at the AT&T-suggested entries for Hayes modems: always asserting DCD true via a DIP-switch setting. Only the setting for a "datakit" gave me a clue as to how to at least make HDB uucico dial out without its apparent 5-second timeout... start the modem asserting CLOCAL (forcing the system to assume DCD is true), then the uucico won't time out during the dial and WILL wait for the modems to do their handshake, then one can issue "\m" to de-assert CLOCAL upon receipt of the "CONNECTED" string. Stupid, stupid, stupid, stupid. What were the authors of HDB smoking when they conjured up THAT scenario? At least the version 2 uucp (which I presume Andy is using) doesn't have this problem. That assertion will NOT cause the system to think a modem connection has been "broken" even when you pull the modem's RJ-11 jack out of the wall; just think what this does if you're calling Ohio State long-distance; I suppose AT&T doesn't care since, for them, phone calls are free! :-) :-) After I "cool down" regarding this bogosity (in about a week), I'll post my discoveries to date and some temporary "fixes" one can use with HDB UUCP and modems and the real-world. And lest someone thinks I'm a "babe in the woods" concerning modems and connections thereof and wherewith, I test over 150 different modems a year for use with the computer systems I (personally) design; these systems are most-often sold to the phone companies themselves, and I've even an exclusive contract with one major East Coast state. The point being: one should NEVER ignore the crucial out-of-band hardware control signals concerning data communications (e.g. DTR, DCD, and others). Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
skwu@boulder.Colorado.EDU (WU SHI-KUEI) (01/05/90)
The problem was fixed in Release 3.1 of System V by adding the options \M and \m for opening the port with O_NDELAY and re-opening the port with CLOCAL off, respectively. Works like a charm.
bdb@becker.UUCP (Bruce Becker) (01/05/90)
In article <15338@boulder.Colorado.EDU> skwu@boulder.Colorado.EDU (WU SHI-KUEI) writes: |The problem was fixed in Release 3.1 of System V by adding the options \M |and \m for opening the port with O_NDELAY and re-opening the port with |CLOCAL off, respectively. Works like a charm. Although undocumented, this was available in HDB UUCP for the UnixPC as well. Without it, DCD must be configured to be on all the time... Cheers, -- \\\\ Bruce Becker Toronto, Ont. w \66/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/v/-e BitNet: BECKER@HUMBER.BITNET _< \_ "We can't afford to igNoriega this" - George 'Thug-free' Bush
sean@pattye.lonestar.org (Sean McCollister) (01/05/90)
In article <25594@cup.portal.com>, thad@cup.portal.com (Thad P Floryan) writes: > Then I recently switched to HDB uucp and the BOZO ASSUMPTIONS made by that > software is enough to put even Mother Theresa on a killing rampage. Loads of > UNDOCUMENTED options. Just TRY and find what "\M" and "\m" mean in ANY > published AT&T docs....... [ other comments deleted ] Well, Thad, I'm looking at page 5-51 of the "AT&T 3B2 Computer UNIX(R) System V Release 3.2 Release Notes." There are about 4 paragraphs dedicated to "Basic Networking Utilities: Intelligent Modems." In addition, there are quite detailed instructions on the use of the "\M" and "\m" options, as well as the ",M" subfield for the tty devices, in my /usr/lib/uucp/Dialers file. "UNDOCUMENTED"? Hardly. Of course, the 3B2 Basic Networking Utilities are a *supported* product. HDB UUCP for the unix-pc/3b1 *is not*. Unless the party line has changed, you shouldn't even have a copy of 3B1 HDB if you don't work for AT&T. How can you find fault with AT&T for not providing documentation for something they've said over and over again is not supported? Sure, it was nice of the folks at the DPTG to port it. It was nice of the folks at the STORE to make it available. But it's a bit much, don't you think, to expect the folks at the CIC to print docs, or the folks at the Hotline to provide support, for something nobody has paid any money for? When dealing with an unsupported product, you have to look for the information you need in unusual places. I got the impression from your article that you didn't look very hard. -- Sean Internet: sean@pattye.lonestar.org McCollister UUCP: {texbell,attctc}!pattye!sean
thad@cup.portal.com (Thad P Floryan) (01/06/90)
fmcgee@cuuxb.ATT.COM (Frank McGee) in <4415@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@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
woods@robohack.UUCP (Greg A. Woods) (01/07/90)
In article <25668@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: > 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. Neither was I, but if you have the '\M' (Dialers) hacks (they actually are not hacks, but reasonably good design, IMHO) in your uucp, then you also have the ",M" (Devices) hacks. More later.... You are actually lucky to have a version of HDB UUCP with these features. They seem to be a relatively recent invention. As for docs, > AT&T UNIX System V Release 3.2 System Administrator's Guide > (c)1989, ISBN 0-13-944794-6 Mine is: AT&T Unix System V/386 Release 3.2 System Administrator's Guide (c)1989, ISBN 0-13-944893-4 And as Mr. McGee says, on pages 8-25,8-26 the "\M,\m" stuff is documented, as is the ",M" on page 8-21. I find it hard to believe these are not in the generic 3.2 docs, though this is, unfortunately, possible. I also find it hard to believe the following comment was not in your Dialers file (but again, this is, unfortunately, possible): # Furthermore, you must add a ",M" subfield to the line field (field # 2) of the associated Devices file entries, as shown here: # # ACU culd0,M - 1200 hayes \T # # The ",M" subfield will cause the device to be opened with O_NDELAY set # (so the open doesn't hang waiting for carrier). After the open, # O_NDELAY is cleared. Then in the dialer script, "\M" sets CLOCAL and # "\m" clears it. Typically, CLOCAL is set for the duration of the # dialer chat, then cleared (so uucico and cu will detect dropped lines) # once you're connected to the remote system. As well, I find it hard to believe any AT&T person who knows about the above features would continue to suggest and try to justify the stupid idea of asserting DCD continuously on a port. It seems those who insist on ignoring the lessons of history are doomed to repeat them. -- Greg A. Woods woods@{robohack,gate,tmsoft,ontmoh,utgpu,gpu.utcs.Toronto.EDU,utorgpu.BITNET} +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA
thad@cup.portal.com (Thad P Floryan) (01/07/90)
sean@pattye.lonestar.org (Sean McCollister) in <346@pattye.lonestar.org> writes Well, Thad, I'm looking at page 5-51 of the "AT&T 3B2 Computer UNIX(R) System V Release 3.2 Release Notes." There are about 4 paragraphs dedicated to "Basic Networking Utilities: Intelligent Modems." In addition, there are quite detailed instructions on the use of the "\M" and "\m" options, as well as the ",M" subfield for the tty devices, in my /usr/lib/uucp/Dialers file. "UNDOCUMENTED"? Hardly. OOPS. OK, I *DO* have "AT&T UNIX System V Release 3.2 Utilities Release Notes" (c)1989, ISBN 0-13-944844-6. And page 5-51 does have the material cited by Sean. HOWEVER, neither the Table of Contents nor the non-existent index make note of BNU upgrades. Not very obvious! :-) Because this problem CAN "bite" other people, I'm including the notes in their entirety: " BASIC NETWORKING UTILITIES: Intelligent Modems Features have been added to the "/usr/lib/uucp/Dialers" and "/usr/lib/uucp/Devices" files to prevent problems that occur when using System 75s, System 85s, Hayes-compatible modems, and other intelligent modems that do not keep Carrier Detect (CD) high all the time. Devices: Adding a ",M" to the second field of an entry in the Devices files will cause the O_NDELAY flag to be set when the device is opened. This prevents BNU software from blocking on the device while waiting for CD. The example below shows how to add the ",M" to a Devices file entry for a device connected to an automatic call unit for a Hayes modem. ACU tty11,M - 1200 hayes \T Dialers: Adding "\M" before the chat script in a Dialers file entry will set CLOCAL, preventing any change in the CD lead from resetting the state of the device. Once the conversation is established, "\m" will clear CLOCAL. This will allow BNU to again monitor changes in CD (for example, to notice if the line drops). The example below shows how to add "\M" and "\m" to an entry for a Hayes modem in the Dialers file. hayes "=,-," "" \M\dAT\r\c OK\r \EATDT\T\r\c CONNECT \m\c Note: for some devices, adding a "\p" after the "\M" may be necessary. " Sean continues: When dealing with an unsupported product, you have to look for the information you need in unusual places. I got the impression from your article that you didn't look very hard. This morning's 12K posting details how and where I sought information. As I stated before, I have over 15 linear feet of bookshelf space consumed by the latest AT&T docs, and I did READ everything on the subject that was indexed and cross-referenced; the "Utilities Release Notes" was the only reference I didn't read because nothing in its index suggested BNU updates were included therein. For this "clue", I THANK YOU VERY MUCH! And I hope my "reprint" of the several pertinent paragraphs above helps other people. Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
bdb@becker.UUCP (Bruce Becker) (01/07/90)
In article <25668@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >[...] >/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 Should be: ACU ph0 ph0 1200 PC7300 \T ACU tty000,M - 9600 ark24k Direct tty001,M - Any direct Direct tty002,M - Any direct Direct tty003,M - Any direct Direct tty004,M - Any direct in order for the "\M", "\m" stuff to work correctly - otherwise you will indeed have problems with DCD. This stuff was documented in the comment headers of the relevant files for System V release 3 BNU uucp, but I'm not sure where else I've seen it... Cheers, -- \\\\ Bruce Becker Toronto, Ont. w \66/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/v/-e BitNet: BECKER@HUMBER.BITNET _< \_ "Head-slam me, Jesus, on the turnbuckle of life" - Godzibo
thad@cup.portal.com (Thad P Floryan) (01/07/90)
Just for the record, after the reference to SVR3.2 "Utilities Release Notes",
the TWO changes required worked fine. My system just completed its polls
of a number of sites and all worked fine.
For reference, the changes are (shown by a "^"):
/usr/lib/uucp/Dialers:
ark24k "" "" \M\p\r\c > dt\D\r\c CONNECT \m\c
^^ ^^^^
/usr/lib/uucp/Devices:
ACU tty000,M - 9600 ark24k
^^
As has been discussed in another message thread, the "Tables of Contents" and
"indices" in UNIX manuals (in general, not just the AT&T official docs), leave
a LOT to be desired. :-(
As for the libelous statement by another I was using "improper" software,
that was an assumption on your part, and you know what Benny Hill says about
the word "ASSUME"! :-)
Just in the last 90 days I've purchased many $K new AT&T equipment from
MicroAge (and NOT at the list prices, fortunately for my pocketbook :-), and
I still have active HotLine support. If you'll note, I did NOT trouble the
HotLine with these HDB problems. In fact, the only time I *HAD* to use the
HotLine was to report a REAL, SERIOUS bug for which they FedEx'd out a
fixdisk to me upon its resolution, which WAS crucial since I was to teach
a class in just 5 days from the point I discovered the bug; the fix DID
arrive in time and I publicly complimented the HotLine personnel on Usenet.
Hey, I just "might" be running SVR4.1 on one of my "systems" (which shall
remain nameless); the problems I brought up are NOT unique to the UNIXPC,
they ALSO exist on the 3B2 with SVR3.2.
Concluding, please note that the same fix (shown above) works on the UNIXPC
in case anyone's interested.
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]wtm@neoucom.UUCP (Bill Mayhew) (01/08/90)
I'll have to give AT&T credit. The V2.1 uucp system that comes bundled with the UnixPC made a lot of improvements, most notably the modemcap file which makes it farily easy to set up modem dialer chat scripts. Anybody that has worked with an older Unix or Xenix knows what a pain it is to have to write dialer programs. I would also like to criticize AT&T's v2.1 uucp for the 3b1 in particular. Uucico likes to cause kernel panics at odd intervals under non-repeatable circumstances. It seems to be related to using both the tty ports and the OBM (on board modem) (and not necessarily simultaneously). People that use either the tty or the OBM only don't seem to get the panics. Whatever causes the panic is goofy, as fron my recollection, the panics occur at an odd numbered address, which should not happen. It has been a while, so I don't remember the numbers any longer. I have to give credit to the Hotline, as they tried emailing me several replacement uucicos with various fixes, none of which, unfortunately, helped. AT&T even swaped the motherboard in my machine, which also did not help. Soembody from tier III support, or whatever it is called, had read a usenet article I posted and called me for information separately from the hotline's effort to resolve my trouble ticket. So... I was pleased with the service I got from AT&T, but it didn't solve my problem. What did away with the kernel panics was installing the unofficial BNU on my 3b1. Per the recent discussion of \M and \m to set ONDELAY open CLOCAL and unset it respectively: yes, the aforementioned tokens are documented in the comments as the top of the Dialers file. Of course, there is no printed documentation for BNU, but considering the cost, you get what you pay for.... However.... I tried using \M to set CLOCAL as the first token in my modem chat script, and it doesn't work for me. When I run BNU in debug mode, I see the "mlock tty000 succeeded" and then the script times out where the "processdev(..." should be with a "CAN NOT ACCESS DEVICE". If I tie the DCD pin high, the script succeeds and I do indeed see a CLOCAL SET where dialing begins. I use a trailblazer modem, which enables me to do a work-around. I set S53=4, which makes the modem hold DCD high all the time (which happens to be irrelevent for this purpose) and hold DSR high except for a brief period (specified by S47) when the carrier is lost. I would normally use a cable that wires 1,2,3,4,5,6,7,8,20 straight through between the modem and 3b1. For this I leave 8 on the modem end unconnected and run 6 from the modem end to both 6 and 8 on the 3b1 end; all other wires straight through. I suspect that my problems might arise from the fact that I run uugetty on the port with the gettydefs with CLOCAL off so that disconnected calls drop cleanly. That fact means that the chat script is enter with CLOCAL off before the first token is processed. Anyway, I'm happy that I can get things to work properly with my trailblazer modem. People that have Hayes or exact clone modems, it would seem, are in for more aggrivation if they want to use BNU and uugetty. If you're willing to not have a bidirectional port, then life would be somehwat easier I suspect. As for the real documentation from AT&T goes, the BNU docs that come with the 6386's Sys V r3.2, which is the newest release we have, are vastly superior to anything in the past. None the less, a neophyte to port settings, CLOCAL, ONDELAY, etc, would probably have a tough time. I suppose that's what makes job opportunities for people like ourselves that hypothetically know what we are doing. Bill
bdb@becker.UUCP (Bruce Becker) (01/08/90)
In article <1990Jan6.223717.12879@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes: |[...] |And as Mr. McGee says, on pages 8-25,8-26 the "\M,\m" stuff is |documented, as is the ",M" on page 8-21. I find it hard to believe |these are not in the generic 3.2 docs, though this is, unfortunately, |possible. I checked - it is, in fact, the case. It is not even hinted at in "Chapter 9: Basic Networking", of the generic "Systems Administrator's Guide". No wonder folks are having so many problems... |I also find it hard to believe the following comment was not in your |Dialers file (but again, this is, unfortunately, possible): | |# Furthermore, you must add a ",M" subfield to the line field (field |# 2) of the associated Devices file entries, as shown here: |# |# ACU culd0,M - 1200 hayes \T Also missing from the 3B1 BNU "Dialers" file. I found out about it from a friend who had a more up-to-date version of the file. Groan, -- \\\\ Bruce Becker Toronto, Ont. w \66/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/v/-e BitNet: BECKER@HUMBER.BITNET _< \_ "Head-slam me, Jesus, on the turnbuckle of life" - Godzibo
news@puzzle.UUCP (newshound) (01/08/90)
In article <25594@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >That assertion will NOT cause the system to think a modem connection has been >"broken" even when you pull the modem's RJ-11 jack out of the wall; just >think what this does if you're calling Ohio State long-distance; I suppose >AT&T doesn't care since, for them, phone calls are free! :-) :-) Take a look at how AT&T's recent modems handle DCD and you'll see the thought behind it. A 22xx series will drop DCD momentarily when carrier is lost, then turn it back on again. It makes using a non-AT&T modem difficult, but it can be done. By the way... Has anyone had this happen? Set stty hupcl, su to root, exit, then exit or control-D again? Here it intermittently causes DTR not to go off. -- Bob attctc!puzzle!bei
jcm@mtune.ATT.COM (John Mcmillan) (01/09/90)
In article <1867@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: : >I would also like to criticize AT&T's v2.1 uucp for the 3b1 in >particular. Uucico likes to cause kernel panics at odd intervals ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >under non-repeatable circumstances. It seems to be related to >using both the tty ports and the OBM (on board modem) (and not >necessarily simultaneously). People that use either the tty or : A long note. I got bored... hope I didn't miss anything interesting. Prior to 3.51c, enough errors existed in the [CT] ports drivers that it was possible to vector thru a jump table entry that was BEYOND the valid entries. The result was a trashed execution address. [Ref: requirement that index reg' load be immed. followed by index access.] The result was a kernel panic. Sometimes this involved simultaneous access to both sides of a communications chip: OBM & tty000 tty001 & tty002 tty003 & tty004 ... Sometimes it involved obscure accesses involving the clock-driven OBM tests and accesses to TTY000. Nothing about this should be focused upon UUCICO except that its throughput loads the ports more and increases the probability of the aforementioned interactions. john mcmillan -- att!mtune!jcm -- just muttering for self... not them