darylm@Zaephod.gwd.tek.com (Daryl V. McDaniel) (05/17/88)
In article <4403@dasys1.UUCP> manes@dasys1.UUCP (Steve Manes) writes: >I've been installing Telebit support into 'cu' clone source this week and >... >Both are brand-new with 4.0 ROMs. Trouble #1: the S7 register, on >outdial, times out way faster than the value I've given it. For instance, >S7=60 times out closer to half that value. To log in to the other >Trailblazer using PEP and with the answer modem set to S92=1, I have to set >the calling modem to as high as S7=254 to have a good chance of staying on >line long enough to lock with the trailing-end PEP answer tones. >... I have encountered the same problem. It seems the first time an outgoing call is placed after power cycling the modem the timeout is correct. Every time after that it is about half or even less. So far, I have been able to get by with S7=180 > >Trouble #2: logging in at PEP with 9600 baud (under Xenix) produces a REAL >spasmodic display... more than I would assume with packetization. >... I haven't tried this with PEP (I use PEP at 19200 <interface speed>, and then ONLY for uucp) but I have noticed a distinct "jerkiness" using MNP with 2400-baud operation. Also, 80% of the time uucp will fail with a MNP 2400-baud connection. >+----- >+ Steve Manes >+ decvax!philabs!cmcl2!hombre!magpie!manes Magpie BBS: 212-420-0527 >+ SmartMail: manes@magpie.MASA.COM And now for some "new" information. There appears to be an interaction problem with some of the switch settings. Telebit is aware of this problem, I just want to ensure that everyone else out there knows. This is with V4.0 ROMs. If S0 is set to some value greater than 0 (we use 3) AND S92=1 AND (Q6 | Q7) when placing an outgoing call the modem will hang up as soon as it detects carrier. Once the problem was identified the fix was easy (for us anyway). Since we are using a BSD4.3 derived uucp I added "S0=0" to the chat scripts in L-devices for all entries associated with the telebit. When the call is completed, uucico drops DTR to the modem causing the EEPROM values to be reloaded. This resets S0 and all other switches modified by the chat script to their default values. BTW. I really like the "smart" DTR and DSR features of the TB+. These features allow us to use the TB+ for both dial-in and dial-out without having to modify any of the software for which we DON'T have source code. Since the OS our machine has doesn't support acucntrl or any of the neat IOCTLs recently discussed in comp.unix.wizards for opening a port when DCD is not present, the TB+ (or mechanical port switches) were our only solution. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Daryl V. McDaniel (503) 224-7056 Micronetics; Aloha Research Group 4730 S.W. 182nd Ave. ...tektronix!nosun!illian!darylm Aloha, Oregon 97007 WUI Telex: 6972206
wtm@neoucom.UUCP (Bill Mayhew) (05/19/88)
At the moment, I am "stuck" using an aged TB, version 3. I've found that uucp is broken when some other machine dials in at 1200 or 2400 baud. I can only get one C or D file though per call which means that it takes an awful long time to get mail through!! What happens is that the first file gets though, and then uucp returns to control state to begin the next file and then fails a checksum on the first packet. It seems like there is some risidual of the spoofing alogorithm that is munging up uucp at the lower speeds when there should be no spoofing at all. We sent the TB+, version 4 down to Mark Horton, so I can't currently verify if this bug in in the newer firmware. Sure is aggrivating, though! I've tried just about every combination I can think of, with and without MNP, etc, but they always gag on uucp at 1200 or 2400. Normal interactive person-typing-at-a-CRT type calls seem to be just fine at the lower speeds. Uucp seemed to work OK when regular old Hayes were swapped back in on the connection. I guess the Trailblazer is kind of like a mother in law; you just gotta love it anyway, despite the quirks. --Bill wtm@neoucom.UUCP
wayne@teemc.UUCP (//ichael R. //ayne) (05/22/88)
In article <1186@neoucom.UUCP> wtm@neoucom.UUCP writes: > ->At the moment, I am "stuck" using an aged TB, version 3. I've ->found that uucp is broken when some other machine dials in at 1200 ->or 2400 baud. I can only get one C or D file though per call which ->means that it takes an awful long time to get mail through!! What ->happens is that the first file gets though, and then uucp returns ->to control state to begin the next file and then fails a checksum ->on the first packet. It seems like there is some risidual of the ->spoofing alogorithm that is munging up uucp at the lower speeds ->when there should be no spoofing at all. -> ->We sent the TB+, version 4 down to Mark Horton, so I can't currently ->verify if this bug in in the newer firmware. Sure is aggrivating, ->though! I've tried just about every combination I can think of, ->with and without MNP, etc, but they always gag on uucp at 1200 or ->2400. Normal interactive person-typing-at-a-CRT type calls seem to ->be just fine at the lower speeds. Uucp seemed to work OK when ->regular old Hayes were swapped back in on the connection. -> ->I guess the Trailblazer is kind of like a mother in law; you just ->gotta love it anyway, despite the quirks. There is most likely nothing wrong with your TB except for some bad S register settings (and a lack of documentation). I had exactly the same complaint when I set mine up (Mike Ballard at Telebit should remember this one well). I suspect that what is happening is that you are using SOFTWARE (Xon/Xoff) flow control and are not locking interface speeds (ie you run your getty at 19200 or 9600 baud all the time). This all SEEMS reasonable from reading the manual but the poor TB is getting info from your machine at high speeds and trying to spit it out at 1200 baud. Since it can not do hardware flow control, it sends an Xoff which screws uucp "g" protocol up badly. Presuming that you can not do H/W flow control, you need to make your getty autobaud and have the TB set the RS232 port speed based on the tone set it uses. There is also an undocumented S register setting which I do not have handy (and my TB's are busy NEWSing). Calling Telebit (800 TEL-EBIT) tech support should solve this one rapidly. /\/\ \/\/ -- Michael R. Wayne --- TMC & Associates --- wayne@teemc.uucp INTERNET: wayne%teemc.uucp@umix.cc.umich.edu uunet!umix!teemc!wayne
wtm@neoucom.UUCP (Bill Mayhew) (05/25/88)
Thanks to Michael Wayne for the suggestions on running the trailblazer with the interface speed locked and running uucp at other than 9600 baud. It turned out that the vax end was running the trailblazer locked at 9600 baud and using xon/xoff protocol. This caused problems for us when uucico on the vax started dumping data intot the modem at 9600 baud, but the connection was only running at 2400. Quite obviously, after a few seconds, the modem sent back what it felt was an obligatory xoff as the buffer filled up. The xoff character apparently cuased the g-protocol to barf. I'm not sure why the effect always manifested itseft was just a single file getting though. I never saw the problem on my end of the line with impulse (a 3b1) because it always originated calls, and when it places calls, I also have it switch baud rates going to the serial port. Since the data rate was always within the thoughput bounds of the modem on my end, I never saw the real cause of the problem. The people at Telebit might want to consider a little footnote for their manual in the next release. This is an easy trap to fall into, and pretty easy to overlook. I sure left dumb that I didn't notice it myself. Unfortunately, the tty driver on the vax end doens't support harware handshaking, so it looks like the solution is to use the circular baudrate selection in gettydefs. Yuck. There are quite a few inexperienced users that call on that line between 8:00 and 5:00 pm, and it's hard enough to get them to connect, let alone handle mulitple baudrates and hitting the break key. I suppose one way around it would be to set up two gettydefs and have crontab switch them back and forth. Also could rewrite the tty driver, but our computer gurus don't like that idea. Any ideas out there? Thanks to all on the net who've assisted. Your help is definitely appreciated. --Bill wtm@neoucom.UUCP
les@chinet.UUCP (Leslie Mikesell) (05/26/88)
In article <1197@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: >It turned out that the vax end was running the trailblazer locked >at 9600 baud and using xon/xoff protocol. This caused problems for >us when uucico on the vax started dumping data intot the modem at >9600 baud, but the connection was only running at 2400. Quite >obviously, after a few seconds, the modem sent back what it felt >was an obligatory xoff as the buffer filled up. The xoff character >apparently cuased the g-protocol to barf. I'm not sure why the I thought trailblazers were supposed to know about g protocol. Did you have the modem set in the correct mode for g protocol or does it not limit its fake ACK packets to a number that will prevent its internal buffer from filling? Les Mikesell