chris@utgard.UUCP (Chris Anderson) (01/26/89)
Hi there, I'm having a problem using HDB uucp with a Telebits TB+. Whats happening is that connection is made fine, initial protocol exchanges are done, file names to be sent are exchanged, directories are made, ... then while waiting for the first packet, uucp says 'alarm 1', 'alarm 2', etc. all the way to 'alarm 10', then quits. I'm baffled. Since control data is exchanged, I assume that errors aren't timing it out. Also, this has happened every time - except for once. That time, the first file made it across, then it timed out. Cu works fine, with ~%take/put as well. Since the exchange works like a champ using 1200 baud (it's timing out at 2400baud), I assume that uucp is set up ok. I'm using the same setup for the Telebits as was posted awhile ago to comp.dcom.modems for Microport SysV. I haven't had the opportunity yet to have tried this using PEP mode. CAbling to the modem is *not* done according to Telebits: Signal Comp Modem TxD 2 3 Rxd 3 2 RTS 4 5 CTS 5 4 DSR 6 20 SG 7 7 CD 8 8 DTR 20 20 The reason that it's different, is that this is the hardware manufacturers (Plexus P-60 w/ICP ports) recommendation for modem cabling. I'm not familiar enough with RS-232 requirements to say if it's right or not. Any help you can give would be appreciated! Please e-mail to ihnp4!csun!csusac!fenris instead of the above address. Thanks in advance! -- Chris Anderson When in Danger or in Doubt, QMA, Inc. Run in circles, scream, and shout! -- Lazarus Long
hack@merkin.cactus.org (Greg Hackney) (01/27/89)
In article <257@utgard.UUCP> chris@boris.UUCP (Chris Anderson) writes: >I'm having a problem using HDB uucp with a Telebits TB+. Whats >happening is that connection is made fine, initial protocol exchanges >are done, file names to be sent are exchanged, directories are made, >... then while waiting for the first packet, uucp says 'alarm 1', >'alarm 2', etc. all the way to 'alarm 10', then quits. For what it's worth, I saw the same symptoms when calling rutgers' Telebits. Turned out that the flow control had to be set to "hardware" rather that XON/OFF when speaking with them. -- Greg
craig@n8ino.UUCP (R. Craig Peterson ) (01/31/89)
In article <257@utgard.UUCP> chris@boris.UUCP (Chris Anderson) writes: > connection is made fine, initial protocol exchanges >are done, file names to be sent are exchanged, directories are made, >... then while waiting for the first packet, uucp says 'alarm 1', >'alarm 2', etc. all the way to 'alarm 10', then quits. I've had the EXACT same problem as you appear to be having. I'm trying to use a TB+ to talk to a machine with a Hayes 1200 bps modem. Both sides are running HDB uucp. I talk fine to other sites. Very annoying!! -- R. Craig Peterson (N8INO) mcdchg!n8ino!craig craig@n8ino.UUCP
rpw3@amdcad.AMD.COM (Rob Warnock) (02/01/89)
+--------------- | | are done, file names to be sent are exchanged, directories are made, | | ... then while waiting for the first packet, uucp says 'alarm 1', | | 'alarm 2', etc. all the way to 'alarm 10', then quits. | I've had the EXACT same problem as you appear to be having. | I'm trying to use a TB+ to talk to a machine with a | Hayes 1200 bps modem. Both sides are running HDB uucp. +--------------- Yet another data point. Same problem. Exactly. Using a TB+ to talk to some 1200 baud thingy. But I'm running a 4.1bsd-based UUCP, though the other end (the answering end) is a System-V, and may well be using HDB. And my end is not using *any* flow control (TB+ interface "locked" at 9600). +--------------- | I talk fine to other sites. Very annoying!! +--------------- Ditto. Ditto! Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403
pag@tcsc3b2.UUCP (Philip A. Gross) (02/03/89)
In article <173@n8ino.UUCP>, craig@n8ino.UUCP (R. Craig Peterson ) writes: [...one person wrote...] > > connection is made fine, initial protocol exchanges > >are done, file names to be sent are exchanged, directories are made, > >... then while waiting for the first packet, uucp says 'alarm 1', > >'alarm 2', etc. all the way to 'alarm 10', then quits. > [... and another wrote...] > > I've had the EXACT same problem as you appear > to be having. > > I'm trying to use a TB+ to talk to a machine with a > Hayes 1200 bps modem. Both sides are running HDB uucp. > > I talk fine to other sites. Very annoying!! The problem you both are experiencing has to do with the XON/XOFF handshaking being implemented by the modem. Uucp has serious problems when trying to xfer files between systems where one of the modems is using XON/XOFF. Listed here are the NVRAM settings of our TB+: E0 F1 M1 Q6 P V1 X0 Version BA4.00 S00=002 S01=000 S02=04 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=007 S11=050 S12=050 S45=255 S47=004 S48=000 S49=000 S50=000 S51=004 S52=002 S53=000 S54=003 S55=000 S56=017 S57=019 S58=000 S59=000 S60=000 S61=128 S62=003 S63=001 S64=000 S65=000 S66=001 S67=000 S68=000 S90=000 S91=000 S92=001 S95=002 S100=000 S101=000 S102=000 S104=000 S110=255 S111=255 S112=001 S121=000 and finally, this is an excerpt from our HDB Dialers file: # This is for connecting to those systems which also have a Telebit modem, Yea! tbfast =W-, "" \d\rA\rAT OK ATS58=3\r OK ATS50=255\r OK ATS111=30\r OK ATDT\p\T\r\d\d\d\d\d\d\d\d\c CONNECT # This is for those installations not so fortunate to have a Telebit modem # and therefore, their systems have a difficult time with things like # XON/XOFF. tbnorm =W-, "" \d\r\r\rAT OK ATS58=0\r OK ATDT\p\T\r\d\d\d\d\d\d\d\d\c CONNECT The speed in which the computer and the modem communicate is locked in at 9600 baud, while we allow the modem to handle the transition to various speed modems. Therefore, all systems we communicate to are listed at 9600 baud in our HDB Systems file. BTW, all of the delays that you see in the Dialers, above are to ensure that uucp doesn't get impatient with the modem when the modem has to wait for the phone company to establish the connection. Sometimes the wait gets to be a bit long. Hope this info is of assistance... ===================================+=========================================== Philip A. Gross |INTERNET: pag%tcsc3b2@wb3ffv.ampr.org The Computer Solution Co., Inc. |USENET: ...!wb3ffv!tcsc3b2!pag 1009 Sycamore Square, P.O. Box 716 |UUCP: tcsc3b2!pag (804)794-1514 Midlothian, VA 23113-0716 |ATTMAIL: attmail!tcsc3b2!pag Voice: (804)794-3491 | The opinions expressed here are strictly mine and nobody elses. << I haven't heard what I have to say about that yet. >> :-)
wtm@neoucom.UUCP (Bill Mayhew) (02/03/89)
Several people have recently reported complaints about uucico timing out with alarms when dialing into a site that only supports slow connections (1200 or 2400 buad) dialing from a Trailblazer modem. This problem is can be fixed. The problem crops up apparently due to the buffer management scheme in the Trailblazer. When you initiate the call to the remote site in non-PEP mode, you lose the nfity intelligence built into the modem for pre-acknowedging the uucp g protocol from your originating modem. .. but you don't lose the buffering in the modem. The problem most likely happens when your machine has a higher baud rate talking to the modem than the baud rate of the data link. You might see bugs at the host operating at 2400 baud and the modem also at 2400 with MNP enabled on a poor line lowering the aggregate throughput to something less than 2400 baud between ends. Apparently, the Trailbazer is pretty conservative about buffer management when operating in non-PEP mode. The trailblazer seems to send flow control back to your host when the trailbalzer buffer has about 100 characters queued for transmission. The protocol start-up following the Shere=mach_name exchage is long enough to scare the trailblazer into flow-controlling your host. If you have set registers S58 and/or S68 to use Xon/Xoff or Enq/Ack in-band software based hand shaking, your host will gag on the flow control character and go out to lunch 'til the alarms time out. The good news is that the basic g protocol without sliding windows uses data packets of 70 characters, so there is in reality very little (in fact no) chance of over running the buffer in the trailbalzer because your host will wait for the acknowledgement from the rmote host before sending the next packet. In effect the protocol is self-regulating, not needing flow control. There are two tacks that you can take to solve the problem: 1. Set up your uucp chat script to disable flow control. You need to set S58=0 and S68=0. If you need flow control for interactive sessions later on, on the same line, program S52=2 to reload operating parameters on drop of DTR lead. Program the NVRAM to set S58 and S68 seasoned to taste for the interactive sessions. Make sure that your modem has a cable with leads 1,2,3,4,6,7,8 and 20 going to your host port so that when uucico toggles DTR at the end of the call that the NVRAM parameters will reload. 2. Talk to your modem at a baud rate less than or equal to the remote modem and prefereably don't use MNP protocol. Set S51=255 to enable autobauding of the host interface. Make sure that you start all your chat scripts with A\pA\pA\pA\pA\p. At lower buad rates, it might take up to five As for the modem to figure out the interface speed. I use method #1, and have had no problems calling into slow sites with it. I use method #1 beuase my trailbalzer also has to support incoming calls with uugetty. You could program uugetty to do the round-robin baud switching via the break key, but there are 6 buad rates that must be stepped through and it is also difficult to explain the procedure to neophyte l'users in the acctg. dept. and the like that are scared enough just at the mention of the word modem, let alone "buad rate" and "break". It's much easer to lock uugetty at 19.2K interface and leave the modem to do the translation. Before I got HDB and uugetty, my trailblazer was strictly dial-out under the icky generic System V uucp that doesn't have uugtetty. I used method #2 with good success in that case. Method #2 is probably a little easier than #1, but #1 lets you get a lot more mileage from your modem by also supporting dail-ins on the same line. I think it would be real handy if Telebit would publish a hint guide for setting up with uucp. It took quite a bit of head scratching when I first got the trailblazer to figure everything out. Things like the effects of S58/S68 can be pretty subtle, and hard to pin down without using a serial line analyzer. I've been using trailblazers here for about a year and a half now, and it has most definitely been worth the work. I've saved a lot of money in LD charges and generally improved the convenience of the system. I hope this clarifies a couple of things, --Bill wtm@impulse.UUCP ...!lll-winken!scooter!neoucom!impulse!wtm
wilkes@mips.COM (John Wilkes) (02/14/89)
In article <1488@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: > >Several people have recently reported complaints about uucico >timing out with alarms when dialing into a site that only supports >slow connections (1200 or 2400 buad) dialing from a Trailblazer >modem. I have a slightly different problem: 2400 works fine, but high speed TB-to-TB loses, the local uucico complaining about receiving something unexpected. (I forget the details just now, and the machine with the problem is not here.) Connection is made successfully, and login is successful. Packets fly back and forth for a little bit, and then it croaks. A simple poll, with no file transfer in either direction, works fine (if I remember correctly). The *only* thing I change is the speed to 2400 in my Systems file, and it works fine. Clearly, the uucp setup is fine, since 2400 works. Ditto for xon/xoff flow control. Kermit file transfers and cu both work fine at high speed between the two systems in question. Since connection is made and login is successful, uucico is not timing out waiting for PEP tones. What's really odd, is that my high speed connection worked just fine for several months, then suddenly stopped. I know I changed absolutely nothing on my end, and I am told that nothing changed on the other end. The host interface is locked at 19200 on both sides, and I use hardware flow control. (But maybe not for long? Read on.) In private communication with a net.friend, I have been told that Telebit has a problem in the 4.0 ROM. Without mentioning his name (since I did not warn him that I would quote him on this forum) here is what he told me: | A couple observations and/or possibilities... | | 1) Canonical rule passed down directly from the all powerful dieties: | You cannot lock the interface speed. Interface speed _must_ flow with | the transmission speed (i.e., 1200 baud connections must talk to the | modem at 1200, 2400 at 2400, etc.) The modem switch configurations I | sent you reflect this. | | If you lock the interface speed, I guarantee that you will fail | connections to some sites, and some sites will fail connections to | you. Yes, this is actually a bug buried somewhere in the 4.0 ROMs, | that is supposed to be fixed in the next release (if I remember my | history correctly). | | Remove the interface speed lock and try again. See if that makes any | difference. Can anyone confirm/deny this? Telebit, are you reading this? -wilkes -- -- work: {decwrl ames pyramid prls}!mips!wilkes -OR- wilkes@mips.com
wilkes@mips.COM (John Wilkes) (02/14/89)
I just ran diagnostics on my TB, and it flunked the ROM test. I suspect
that has something to do with my problem...
The command to run diags is "at&t" (no smiley, folks, that's the command.)
-wilkes
--
-- work: {decwrl ames pyramid prls}!mips!wilkes -OR- wilkes@mips.comkls@ditka.UUCP (Karl Swartz) (02/21/89)
In article <13224@electron.mips.COM> wilkes@mips.COM (John Wilkes) writes: >| 1) Canonical rule passed down directly from the all powerful dieties: >| You cannot lock the interface speed. Interface speed _must_ flow with >| the transmission speed ... >| >| If you lock the interface speed, I guarantee that you will fail >| connections to some sites, and some sites will fail connections to >| you. Yes, this is actually a bug buried somewhere in the 4.0 ROMs, >Can anyone confirm/deny this? Telebit, are you reading this? Yes, there is a problem in the 4.0 ROMs that can cause problems with certain modems if you lock the interface speed. Evidently, with a locked interface speed, the TrailBlazer shaves a slight amount off of each stop bit, so if things are set for 1 stop bit you actually get a tad less. Some modems gag on this. In practice, I run a locked interface speed for incoming calls and the only problems I've had are the the on-board modem of a UNIX PC. These modems also tend to pretend they support MNP even though they don't, and probably have other problems too. No other modems (not that I've tested all of them in existence) have had problems. And yes, word is that the next ROM update will fix this problem. -- Karl Swartz |UUCP {ames!hc!rt1,decuac!netsys}!ditka!kls 1-505/667-7777 (work) |ARPA rt1!ditka!kls@hc.dspo.gov 1-505/672-3113 (home) |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
schoch@trident.arc.nasa.gov (Steve Schoch) (02/22/89)
In article <1488@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: >2. Talk to your modem at a baud rate less than or equal to the >remote modem and prefereably don't use MNP protocol. Here's what I did. Unfortunately, this requires uucp source so if you don't have source from Berkeley, you're out of luck. I set S51 to 5 (19200 bps interface speed) and S66 to 0. Then my dialer, which is a modification of the hayes dialer makes the connection at 19200. If the modems answers in slow mode, the dialer ioctl's the line to whatever speed it answered and goes on with the rest of uucico. When S66=0 no flow control is used in slow mode and uucico doesn't get confused about at what speed it's actually talking. Steve
albers@ka3ovk.UUCP (Jon Albers.) (02/23/89)
I don't know why the interface speed can't be locked. We have been doing things that way here for over a year with no problems, and in 2 recent cases, the ONLY way to relaibly connect was with the interface speed, because the getty program was too dumb to figure out the correct speed, sending BREAK not withstanding. We have trailblazers on Zilog Z8000s, UniSys 5000/85s and 5000/95s, various PC clones running XENIX (including Compaq 386/25s), etc.. and locking the interface speed and allowing the TB to do the speed conversion allowed both high and low speed connections to work 100% of the time. As far as I can tell in my experience, the TB is smarter than getty by a long shot. FYI, here are the registers as set on a Compaq 386/25 running SCO XENIX 2.3.1, which allowes (through the use of a very nice dialTBIT) both dialin and dialout operation: E0 F1 M0 Q4 P V1 X3 Version BA4.00 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006 S10=007 S11=070 S12=050 S45=000 S47=004 S48=001 S49=000 S50=000 S51=005 S52=002 S53=001 S54=003 S55=000 S56=017 S57=019 S58=002 S59=000 S60=000 S61=045 S62=003 S63=001 S64=000 S65=000 S66=001 S67=000 S68=255 S90=000 S91=000 S92=001 S95=000 S100=000 S101=000 S102=000 S104=000 S110=000 S111=255 S112=001 S121=000 Jon -- | Jon Albers, IRS, Computer Services, Site Support and Installation(CS:M:S:P) | | UUCP:...wb3ffv!irsx01!ka3ovk!(root|albers) ARPA: JALBERS@SIMTEL20 | | We are looking for any sites anywhere in the U.S. with Trailblazers for UUCP| | Connections. We can poll you. |