CT-User
[Top] [All Lists]

[ct-user] Post CT 9.37 internal serial port support issue?

To: <ct-user@contesting.com>
Subject: [ct-user] Post CT 9.37 internal serial port support issue?
From: darren.hatcher@bt.com (darren.hatcher@bt.com)
Date: Wed, 20 Oct 1999 16:24:23 +0100
CT Users,

Within the CQWW M/M team here in the UK (M6T/G0KPW), we are anticipating
using CT 9.39 for SSB leg next week. 

As part of the prep work we have been building a testbed to make sure that
CT with a DVP and NETTSR all happily work together along with a TNC (it
didn't last year). However, last night I discovered a problem with the
serial port support when the TNC disconnects (e.g. packet link drop out). 

The scenario is two PC's running CT and a TNC onwards into a packet network
(no DVP or NETTSR yet). This looks like:

PC A (COM1) <- NULL MODEM -> (COM1) PC B (COM2) <--> TNC X ~~ (RF path) ~~
TNC Y .....

So we have two machines both running the same CT - CT 9.37 or 9.39 (doesn't
seem to matter, I see same effect). PC B has one serial port as NETWORK at
9600 to PC A, the other using a serial set up as initially TNC (9600) in the
setup, but thence NETWORK (9600) once an onward connect has been done. PC B
is used to connect to PC A and TNC X to connect onwards to TNC Y. The TNC is
a KAM data engine.

The visible effects are:

If we drop the link, TNC X drops into command mode (cmd: prompt), but CT
still thinks it is network and spews corrupt data into the packet window
(e.g. B1B!B!B!B1B1 ...). Unusually we see it in the packet window even
though it is now NETWORK. The TNC complains whilst trying to process it and
CT complains back - cycle very quickly repeats (the packet window fills up
in less than a second and repeats). 

A side effect is that you can't get into the packet window to try to regain
control. Correctly, CT refuses to let you until you set the interface back
to TNC (and unusually set all other interfaces in SETUP to NONE - if any are
NETWORK you are still stuck). This has the onward problem of potentially
sending corrupt packet window data round the CT network at a very alarming
rate.

According to the release notes, some re-engineering work was done on the
serial port handling for 9.37 - has anything been done that might look like
the above? CT 9.27 works fine in this respect and does not throw data into
the packet window and lock you out of the packet window text box or forward
data. I don't have 9.36 or a close variant to see if it worked up to 9.37. I
have not tried 9.44, but given no news in the release notes or in the
reflector, so I'm assuming it is also still the same.

I am intending to do some more testing in this area to get more info
(hopefully a dump of the network traffic). But luckily it is easy to
recreate the problem (this note has already gone to Ken for his thoughts!).

If you're doing the same as us have a go to see what you get. However, if
anyone has spotted a mistake in the above, can they let me know what it was?

Many thanks, and good luck everyone,

Darren - G0WCW
for M6T/G0KPW 
email: darren.hatcher@bt.com

--
Submissions:              ct-user@contesting.com
Administrative requests:  ct-user-REQUEST@contesting.com
WWW:                      http://www.k1ea.com/
Questions:                owner-ct-user@contesting.com


<Prev in Thread] Current Thread [Next in Thread>