Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!nosc!crash!simpact!jeh From: jeh@dcs.simpact.com Newsgroups: comp.mail.uucp Subject: Re: What is ALTCHN? Message-ID: <1997.2778aeb5@dcs.simpact.com> Date: 26 Dec 90 22:07:49 GMT References: <2002.27759FE2@ofa123.fidonet.org> Organization: Simpact Associates, San Diego CA Lines: 50 In article <2002.27759FE2@ofa123.fidonet.org>, rick@ofa123.fidonet.org (Rick Ellis) writes: > On 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