karl@sugar.hackercorp.com (Karl Lehenbauer) (01/31/91)
In article <10061@marque.mu.edu> jtk@marque.mu.edu (Joe Klein) writes: >I have installed a Telebit T2500 on /dev/tty00 of a Bell Technologies >20MH 386 box running Intel System V R3.2. I am communicating with a >Telebit Trailblazer+ attached to an AT&T 3B15 that has been used for >a long time to provide reliable news feeds to multiple sites. > >When I try to transfer a file using uucp I get Alarm 1, Alarm 2 etc. until >uucp errors out. This problem happens in both directions. >What is the problem??? Any ideas??? Well, at 16 MHz on a cached 386, I know you can't reliably receive through the standard terminal driver at 19.2 KB, so that's probably your problem. Try 9600. It will probably work. Another thing to do is to buy NS16550A UARTs and get Uwe Doerning's FAS driver. Another possibility is to buy a smart card, but they are expensive and many are unreliable, so choose carefully. Check out the Frequently Asked Questions posting in comp.unix.sysv386. <karl -- -- uunet!sugar!karl "Stop annoying Mister President with impertinent -- Usenet access: (713) 438-5018 questions, Junior." -- Death Race 2000
time@tbomb.ice.com (Tim Endres) (01/31/91)
In article <7667@sugar.hackercorp.com>, karl@sugar.hackercorp.com (Karl Lehenbauer) writes: > Well, at 16 MHz on a cached 386, I know you can't reliably receive through > the standard terminal driver at 19.2 KB, so that's probably your problem. > Try 9600. It will probably work. I know of many computers *in*capable of handling 19.2K incoming, but still work well with Telebit UUCP at 19.2K. I am certain the reason this person had trouble was that they had register 58 set to use XON/XOFF flow control which definitely interferes with the UUCP g protocol. You can certainly back off to 9600, but unless your throughput at 19.2K is less than 1000cps, I wouldn't bother. As a point of reference, my Macintosh can only handle 19.2K for about 10 seconds (til there is disk I/O) and I still get 1330cps out of the connection even with the retransmits. tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208
chris@endgame.gsfc.nasa.gov (Chris Shenton) (02/07/91)
Recently, uucp alarms have been discussed and it sounds like the problem is
with data overloading, or that there's some annoying ^s/^q garbage going
on. Is my understanding correct?
I've got the same problem -- the machine which has stuff queued up croaks
with alarms. How can I tell who's got the XO{N|FF} problem? And how do you
know this stuff -- seems to be a great dearth of uucp info around!
Thanks in advance.
--
chris@asylum.gsfc.nasa.gov, ...!uunet!asylum.gsfc.nasa.gov!chris, PITCH::CHRISchris@endgame.gsfc.nasa.gov (Chris Shenton) (02/13/91)
More specific info on my `alarm' problem, if I may beg your indulgence.
First, the scenario: I uucico to a remote modem pool, and have the chat
negotiate the phone system into my destination. I'm using a Telebit V32
with MNP5 at 9600 baud; it fails the same way at 2400 baud, but works fine
to an other machine, with PEP.
I did a
uucico -r1 -x9
from machine thanatos to machine asylum. Here's the relevant part of the
output where thanatos alarmed. Note that they start talking, negotiating
for protocol, but fail on the send. When I *don't* have a file queued up on
thanatos, it hangs in the same place, but on "rmesg - 'H'" instead of
"rmesg - 'S'".
imsg >^M^J^PShere=asylum^@Login Successful: System=asylum
omsg "Sthanatos -Q0 -x9"
imsg >^PROK^@msg-ROK
Rmtname asylum, Role MASTER, Ifn - 6, Loginuser - uucp
rmesg - 'P' imsg >^PPgetxf^@got Pgetxf
wmesg 'U'g
omsg "Ug"
send 77
pkgetpack: Connodata=1
rec h->cntl 73
send 61
state - [INIT code a] (1)
pkgetpack: Connodata=2
rec h->cntl 61
send 57
state - [INIT code a]&[INIT code b] (3)
pkgetpack: Connodata=3
rec h->cntl 53
state - [O.K.] (10)
Proto started g
*** TOP *** - role=1, setline - X
gtwvec: dir /usr/spool/uucp/asylum
insert(C.asylumN1791) insert C.asylumN1791 at 0
return - 8
Wfile - /usr/spool/uucp/asylum/C.asylumN1791,Jobid = asylumN1791
Request: thanatos!D.thana43a719b --> asylum!D.thana43a719b (daemon)
setline - S
wrktype - S
wmesg 'S' D.thana43a719b D.thana43a719b daemon - D.thana43a719b 0666 daemon
send 37777777610
send 37777777620
rmesg - 'S' alarm 1
send 37777777610
alarm 2
...
send 37777777610
alarm 10
send 37777777610
tries = 10
got FAIL
...
If anyone can enlighten me as to what's causing this, I'd be forever
grateful. Is it my home box (thanatos), the home telebit, the destination
modem pool thing, or the uucico on the desination machine (asylum)?
Thanks in advance.
--
chris@asylum.gsfc.nasa.gov, ...!uunet!asylum.gsfc.nasa.gov!chris, PITCH::CHRISemanuele@overlf.UUCP (Mark A. Emanuele) (02/14/91)
In article <CHRIS.91Feb13103441@endgame.gsfc.nasa.gov>, chris@endgame.gsfc.nasa.gov (Chris Shenton) writes: > I did a > uucico -r1 -x9 > > from machine thanatos to machine asylum. Here's the relevant part of the > output where thanatos alarmed. Note that they start talking, negotiating > for protocol, but fail on the send. When I *don't* have a file queued up on > thanatos, it hangs in the same place, but on "rmesg - 'H'" instead of > "rmesg - 'S'". > rmesg - 'S' alarm 1 > send 37777777610 > alarm 2 > ... > send 37777777610 > alarm 10 > send 37777777610 > tries = 10 > got FAIL > ... > Looks to me like a serial line flow control problem. As per the telebit manual you MUST be using hardware flow control . I had the same problem when my HFC did not work. Hope this helps. emanuele@overlf.uucp -- Mark A. Emanuele V.P. Engineering Overleaf, Inc. 218 Summit Ave Fords, NJ 08863 (908) 738-8486 emanuele@overlf.UUCP
wolfgang@wsrcc.com (Wolfgang S. Rupprecht) (03/04/91)
jtk@marque.mu.edu (Joe Klein) writes: >I have installed a Telebit T2500 on /dev/tty00 of a Bell Technologies >20MH 386 box running Intel System V R3.2. When I try to transfer a >file using uucp I get Alarm 1, Alarm 2 etc. until uucp errors out. >What is the problem??? The 386 running (and I use the term loosely) Unix. >Any ideas??? Lowest cost fix: Get a two port serial card that has 16550 UARTs on it and run the "FAS" serial driver (available at an archive site near you). If you are handy with a soldering iron, or if your current serial card has sockets, just rip the old uarts out, jump on them a few times for good measure and pop in a set of 16550's. The bare 16550 chips cost anywhere from $5 to $20 each depending on where you get them. -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) uunet!wsrcc!wolfgang Snail Mail Address: Box 6524, Alexandria, VA 22306-0524