rfarris@rfengr.com (Rick Farris) (12/21/90)
Greetings, I'm trying to feed a DOS leaf-site. He's using uuslave.exe from ufgate 1.03. I'm using (if it matters) SCO UNIX 3.2v2.0. Everything works fine at 2400 bps, but using v.32, after a few seconds (3 or 4) of data, his end (DOS) generates a "received ALTCHN" message, and then everything stops. Eventually there is a timeout and carrier is dropped. Grepping through his exe file uncovers the message: uucico: received a ALTCHN (I don't support it) Can someone explain to me what ALTCHN is? (Oh, and if you're feeling real generous, you might suggest a way to fix the problem :-) -- Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@rfengr.com ...!ucsd!serene!rfarris serenity bbs 259-7757
rick@ofa123.fidonet.org (Rick Ellis) (12/24/90)
On <Dec 22 11:02> Rick Farris writes:
RF> I'm trying to feed a DOS leaf-site. He's using uuslave.exe
RF> from ufgate 1.03. I'm using (if it matters) SCO UNIX
RF> 3.2v2.0.
Have him update his version of uuslave by calling 714 939-1041 at 2400 bps. I
found a bug in uuslave the seriously reduced receive throughput.
RF> Everything works fine at 2400 bps, but using v.32, after a
RF> few seconds (3 or 4) of data, his end (DOS) generates a
RF> "received ALTCHN" message, and then everything stops.
RF> Eventually there is a timeout and carrier is dropped.
He might be overflowing his receive buffer, have him try setting it to a larger
value. If he is not using a FOSSIL com driver, he should be.
--
Rick Ellis
Internet: rick@ofa123.fidonet.org
Compuserve: >internet:rick@ofa123.fidonet.org
BBS: 714 939-1041
--------------------------------------------------------------------------jeh@dcs.simpact.com (12/27/90)
In article <2002.27759FE2@ofa123.fidonet.org>, rick@ofa123.fidonet.org (Rick Ellis) writes: > On <Dec 22 11:02> Rick Farris writes: > > RF> Everything works fine at 2400 bps, but using v.32, after a > RF> few seconds (3 or 4) of data, his end (DOS) generates a > RF> "received ALTCHN" message, and then everything stops. > RF> Eventually there is a timeout and carrier is dropped. I can't tell you how to fix the problem, but I can tell you what an ALTCHN message is. In theory, the uucp 'g' protocol provides for an "alternate data channel". There are four types of packets -- control packets, short data packets, long data packets, and "alternate data channel" packets. A uucp 'g' packet begins with (or, in the case of control packets, consists of) a six-byte header, as follows: +-------+-------+-------+-------+-------+-------+ | DLE | K | cklo | ckhi | ctl | XOR | +-------+-------+-------+-------+-------+-------+ The 'ctl' (control) byte is bit-mapped as follows: 7 6 5 4 3 2 1 0 +-------+-----------+-----------+ | T T | X X X | Y Y Y | +-------+-----------+-----------+ The T field denotes the type of packet: T value packet type ------- ------------------------------------------ 0 control packet 1 alternate channel data packet 2 long data block 3 short data block All indicates I have are that "alternate channel data packets" are unused in real-world implementations of uucp. Your system is complaining because it thinks it's seeing these and has no idea what to do with them. Now, it's pretty unlikely that overrun conditions (which are suggested by "it works at 2400 bps") will lead to six-byte sequences that just happen to start with DLE *and* pass the XOR check, but there it is. Perhaps the uucp you are using is trying to interpret the control byte before doing the xor check on the received header (a bad design, in my opinion). --- Jamie Hanrahan, Simpact Associates, San Diego CA Uucp protocol guru, VMSnet [DECUS uucp] Working Group, DECUS VAX Systems SIG Internet: jeh@dcs.simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh