[nos-bbs] verifying operation of ports

[George [ham] VerDuin]

On 02/03/2011 06:56 PM, Bill V WA7NWP wrote:
> On Thu, Feb 3, 2011 at 2:15 PM, Maiko Langelaar<maiko at pcs.mb.ca>  wrote:
>> As far as I know, the KISS protocol provides NO provision for the
>> acknowledging of data OR commands frames sent to the TNC. It's a
>> one way communication, so what is left to use ?
>>
>> A timeout scenario of sorts ?
>>
>> Hardware flow control (would that work with a TNC in kiss) ?
> By definition, KISS has no flow control..  Actual implementations differ.
Automating a recovery to a lost RF link is fascinating.
The litany of failure points is a lot larger than a TNC falling out of KISS.
Choosing a sane recovery methodology?  It might be why we have human 
operators.
None of that is news, right?

I like both both Maiko and Bill that some tools exist, like "at" inside 
and "cron" outside jnos.
There is also a "keep alive" functionality built in including a 
"reconnect" recovery method.
Maiko's concept of sharing the I/O stream with the OS for scripting 
purposes might already be available using the "tee" facility of Linux 
with a custom listener program that is designed to sense failed behavior 
of jnos I/O.
Mostly -- I like the concept of "tweeting" the sysop cell phone when 
things break.

For the TNC reset on power-up, I wonder if that TNC has the action 
option on a internal switch.
Or maybe a memory protect battery is dead?
And given the power down/up cycle is the original definition, why is the 
host still running?

This thread could turn into a chapter in the jnos book.
MRTG Maiko?  Thanks! & may you find yourself "bored" more often  [HI].
Cheers.
Skip