[aprssig] TNC command formats

[scott at opentrac.org]

Good idea on the ^H thing - that might simplify things.

I think I'll have the commands take a port specifier if provided - if not
provided, they'll fall back to the currently defined default.

Tracking state's not that bad.  Each console session is already completely
separated, has its own state data structure, and each command handler
function gets a pointer to the console that invoked it.

Remote control will most definitely be implemented.  Probably in something
more secure than the horribly broken passphrase system currently in use.
Yeah, it works, more or less... but the very concept of it goes against
everything I've learned about cryptography.  Remember, Part 97 doesn't
prohibit authentication.

Over-the-air firmware updates are also planned.  It'll be in two parts - a
'trickle' file transfer protocol (and maybe a faster conventional one) with
delayed, batched acks and retries so you could push out a file over a number
of days on an APRS channel without a lot of extra load, and then a 'load
firmware from file' command after the file's been received and verified.

Scott
N1VG

-----Original Message-----
From: BDonnell at ar-northwest.com [mailto:BDonnell at ar-northwest.com]
Sent: Thursday, March 17, 2005 7:08 PM
To: aprssig at lists.tapr.org; scott at opentrac.org
Subject: RE: [aprssig] TNC command formats


Another alternative that occurs to me is that when you perform command
completion with <tab>, send <control-h> for each character typed so far, to
move the cursor to the left.  Then end the entire command verb in whatever
case you want, or the user configures.

Also, AEA did dual port commands in about the same way as Kantronics - with
a "/" separator.  

I like the approach where its possible to send a single command with enough
parameters to insure that the proper setting of the proper port is being
configured - what I'd consider to be a fully qualified command.  It doesn't
have to be the only way the command handler work, and it could be that a
fully qualified command would not change the context state of a partially
qualified context-sensitive command.  Accepting commands from two source
ports does complicate life in keeping track of context states.  Also, do
consider a remote control capability.  The NET/ROM style authentication
adopted by TheNet and Kantronics (at least) works pretty well if the pass
phrase is long enough, and isn't over-used.  There'd be another context
state to manage.  And you'd want to have a flag that prevents over-the-air
execution of commands that don't make sense, or defers activation of them
(more state keeping) until the control station disconnects.

73, Bob, KD7NM

 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3300 bytes
Desc: not available
Url : http://www.tapr.org/pipermail/aprssig/attachments/20050317/0fdfe0bf/attachment.bin