karn@mouton.UUCP (08/31/84)
To: TAPR TNC owners:
Fm: NK6K
Re: Software updates.
Since a TAPR software maintanence release will be out soon, I'd like to
make sure we have all bug reports and requests for changes in.
I'll list the ones I know about here, along with a disposition, if known.
Please feel free to make comments on any part of the TNC, hardware or
software. Please keep in mind the following though:
There are now at least 1300 TAPR TNCs (Beta + kit) in the world today.
Many people have written code to match the current user interface,
mailboxes, bulletin boards, host systems, gateways, etc. Ask yourself
if your proposed change will require a change in user software. If your
sugestion would cause recoding of other ham's software, unless it has a major
benefit, we would probably have to turn it down. This is called the
real world, which is something you get into when 1300 hams are involved.
A few of the discussions below will seem long and involved. That is because
some of the bugs are in more advanced features. The majority of the bugs
in the more common features were wrung out in the beta test.
On with the bugs:
1) If RETRY is not 0, the TNC will sometimes disconnect before the
retry count has expired. This problem took a long time to find,
because we couldn't reproduce it. Someone in the field came up
with a reliable way to make it happen. The symptom was affected by
both the number of frames in flight, and the number of frames in the
buffer waiting to be sent.
KD4NL has made a patch, we are testing it in the LA area now and will
release it next week. This should make some people very happy.
2) TNC "locks up". This is a difficult symptom to trace. Most of them
are caused by a fault in the hardware. We have found a bug in the
software that causes this, to my knowledge only one person has
fallen in to this particular hole. This is also patched along with
the retry bug.
3) TNC prints garbage on the screen, 64k worth, then comes back.
I have heard rumors that the GLB board can send a frame which causes
this to occur when it is received by a TAPR TNC. If anyone has firm
information on this, please send it in. Sometimes the rumor comes
in as "The GLB sends an illegal protocol frame", possibly an I or UI
frame with no PID byte. Based on that, and the symptom, we have
fixed a problem that would occur if that type of frame was
received. If you have any info on this, send it in. This will be
fixed in the next software update, i.e. it is not patched.
4) The beacon is not started even if a non zero value for beacon time is
stored in novram. True enuff. You must give a BEACON command
after every reset. This bug will be fixed in the next software update.
5) The 400 and 800 baud rates for HBAUD that were there in 2.1 disappeared
in 3.1. A patch is available for this, and has been sent to the AMSAT
guys who needed it. They use 400 baud PSK thru Oscar 10. Fixed in
next software update.
6) *** connect request comes out in transparent mode. I can't make
this happen. It will happen if CONMODE is CONV, you are currently
unconnected, and you manually go into transparent mode by saying
TRANS. When a connect occurs, you will go into convers mode and will
see all messages. If you want to do this, and remain in transparent
mode on connect, say CONMODE TRANS. If anyone has another way of
making this happen, please let me know.
7) If your terminal overruns the TNC's input buffer by ignoring an
<xoff> character, the TNC will never try to <xoff> you again. Serves
you right, too! This bug should be fixed in the next software update.
See also improvement #11 below.
8) TRACE 2xxx bit doesn't work. Non-header data is always dumped.
9) Autobaud is a bit flakey. Since the hardware has no specific
baud rate measuring capability, an easy fix is simply to limit the
autobaud choices to 300 and 1200 baud. If this would have caused
a great deal of difficulty in getting your board up the first time,
please let us know.
This is the end of the known bugs, i.e. those things which work
counter to the way we intended, or counter to the way things were documented.
Following are change requests.
1) Store a line to be transmitted when your TNC is connected to by another
TNC. E.g. CTEXT I'M IN THE SHOWER, PLEASE RING BELL. That message
would be sent automatically when a connect occured. This one stands
a good chance of getting in.
2) Store a line to be transmitted when your TNC refuses a connect from
another TNC. You'd like the other guy to see
*** WB6UUT busy: MAILBOX IS DOWN.
This is a little more iffy. Since the frame used for a connect nak,
DM, has no I field, we have to put the text in a UI frame. The connecting
TNC would have to have MON ON, and the UI frame would have to follow the
same digipeater path back, which may be a different path than UNPROTO
packets usually take. Thus, even if you used this facility, you stand
a finite chance of it not working. Is this worth the effort to
implement? Comments please.
3) Link status check. You'd like the TNC to automatically send a frame to
see if the other TNC is still there. If not, your TNC would timeout
based on RETRY. The command would be CHECK EVERY/AFTER n, where n
is some convenient interval. It would not apply if RETRY was 0. This
will require a protocol change or update. Right now, with the poll/final
controversy, there is no way to prod the other end into giving a response,
short of sending a zero length (PID byte only) Iframe. This seems a
bit tacky. This is on the list of things to get resolved at the next
protocol review in September.
4) Discard unacknowledged I frames when a disconnect occurs. Currently,
if there are outstanding frame, i.e. frames waiting to be acked or
resent, or frames that are in the terminal input queue but as yet unsent,
we dump them as UI frames to the UNPROTO address list. This is listed
under improvements because this is as we intended it to be, i.e. this
is a feature, not a bug. We feel this is a useful diagnostic aid. WE
in this paper, by the way, is various combinations of KV7D, KD4NL, and
NK6K, depending on which of us is responsible for that part of the code.
Comments on this one, please.
5) Implement a TNC resident file transfer protocol. When it comes to
file transfers, the TNC was designed to be transparent, just like a
modem. In fact, if you go into transparent mode, you can run any
program that assumes it's talking to a modem and get the desired
results. (And no, it doesn't dial the phone on ATDT commands,
wise guy). Note that if you want to transfer 8 bit data you must
set the AWLEN and PARITY options correctly, otherwise we'll trash the
high order bit. Most data transfer programs will run correctly
thru the TNC, as long as their internal timers can handle the inherent
delays in packet transmission and digipeating. Implementing a TNC
based file transfer protocol would please a small number of users,
who would still have to write code on their computer to interface with
the TNC's file transfer mechanism. I think the current scheme is the
right choice, and is more in line with the division of tasks set out
in the ISO seven layered OSI model. Comments?
6) Confirm entry into CONVERS mode. You want a warm fuzzy feeling that
the TNC has done your bidding in response to the CONV command. This
would require a change that would bother the mailbox/host/gateway
crowd. They do a lot of popping in and out of command mode to check
status, paths, and other things. An extra message might put the warm
fuzzy message into a file, unless they modified their code. Comments?
7) Go back into command mode after a disconnect initiated by the other
TNC. Currently, you are left in CONVERS or TRANS mode. This should not
both mailbox/host types since ctl-C in command mode is ignored. Comments?
8) Implement a watchdog timer. Have the software pulse a bit on the
parallel port at some inner point only reached if the software is
running correctly. This is so mountain top digipeaters can reset
themselves if something bad happens. Note that this is different than
the hardware transmit timer. Good idea, and it will probably be in the
next release.
9) Print the digipeat list when
a) Someone connects to you
b) When you get a connect request
c) When monitoring the frequency.
I think a) and b) should be done all the time. c) would add to
an already cluttered monitor mode. Anybody see a better way of doing
it. Adding another command to enable this would add to an already
lengthy command list. MPATH has been suggested.
10) Print connect and disconnect packets in monitor mode. How about
NK6K>WB6YMH <C>
WB6YMH>NK6K <D>
There are connect ack and disconnect ack frames, but that might be
getting carried away.
11) Increase the number of bytes that the TNC will handle from the terminal
after the TNC signals <xoff>. Currently, you must stop within
five bytes. After that, the TNC sends another <xoff> after each
of the following five bytes. After that, any characters received
before the TNC sends an <xon> are discarded. While this has not
been a problem for users writing file dumpers in assembler or some
high level languages, it has been a problem for programs which dump
a line, then look in their input buffer for <xoff>. We will probably
increase the guard space to at least 80 characters. Anyone need more?
12) Output <CR> after the callsigns on monitor lines. This would
give more room for digipeat paths and not break up data lines
as much.
13) Echoing xoff and xon. Currently, if the terminal sends a flow
control character out of sequence (xon before xoff, 2 xoffs in
a row, etc.), the TNC treats such characters as data and echos
them. This has the interesting effect of locking some terminals.
It has been suggested that we eliminate this feature and ignore
those characters.
That's the list as I know it to be. Submit any others to the TAPR PO
box. Now that we've got a secretary, she's in charge of not loosing them.
Remember, the TRACE command is handy for looking at the protocol and seeing
exactly what the TNC sent/received, including user data. Please include
hardcopy of traces for protocol error reports.
NK6K for KV7D and KD4NL, TAPR Software Group.