[aprssig] What is "TNC Channel Switching"?

Robert Bruninga bruninga at usna.edu
Fri Apr 11 09:58:24 CDT 2014


> If it can be shown that the Kantronics TNCs are only sensitive to these
> characters on the serial side, and as a prefix to a command,
>  then there is no reason to prohibit their use within the protocol
itself.

I disagree.  It is on the serial port where they do the damage.  When the
characters (if they were allowed to be part of theprotocol) have to get
from the PC to the TNC and that path in these TNC's is via the serial
port.  Hence allowing these characters in the protocol means they will
travel via the serial port and so this is just setting up the network for
this problem to occur.

And it is well known and proved by Mr Murphy that if bad things can
happen, then they eventually will.  Murphy's law.

That is why these two bytes were avoided in the protocol.  I see no reason
to allow their use which would allow a known probem to infect our
networks.

Bob, Wb4APR



-----Original Message-----
From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
Of Rick Green
Sent: Friday, April 11, 2014 10:45 AM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] What is "TNC Channel Switching"?

On Fri, 11 Apr 2014, Stephen H. Smith wrote:

> The Kantronics "stream switch" characters were a way of accommodating
> multiple logical channels in the 7-bit ASCII world that predated KISS,
> by using two typeable characters that were not used much (at least in
> American English and if you weren't a Unix programmer!).

That doesn't answer the OP's real question.  Is it necessary to treat
these characters as 'reserved', and prohibit their use within APRS
packets?
   To answer this, I feel we need to know the answers to two other
questions:
   Were the Kantronics dual-TNCs sensitive to these characters in received
data on the radio side?  Would they cut off the current stream and switch
the received data to the other radio in mid-packet??
   Did the Kantronics command language provide any way of 'escaping' these
characters so that they could be embedded within packets?  It was
mentioned that in practice they were 'prefixed' to a command to indicate
which stream this command is to apply.  Is it possible that the TNC was
ONLY sensitive to a stream switch character immediately after a ctrl-C as
it enters command mode, or immediately after a carriage return if already
in command mode?

If it can be shown that the Kantronics TNCs are only sensitive to these
characters on the serial side, and as a prefix to a command, then there is
no reason to prohibit their use within the protocol itself.

--
Rick Green, N8BJX

We, the People of the United States of America, reject the U.S. Supreme
Court's
  Citizens United ruling, and move to amend our Constitution to firmly
establish
  that money is not speech, and that human beings, not corporations, are
persons
                        entitled to constitutional rights.

 			http://www.MoveToAmend.org


_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig


More information about the aprssig mailing list