Aprx does not support messaging about aprx HOT 8 OPEN

I think remote actions is a can of worms, particularly in a full Linux environment like Aprx is in. Linux supports so many other remote access capabilities through SSH and VPNs or microwave links, or even point-to-point dial-up modem links which I've used before for remote console access, that I can't justify the complexity of supporting any remote commands.

Since Aprx is not a user-facing application, the extent of messaging would only be logging/forwarding incoming messages and responding to a limited set of APRS query fields.

from aprx.

Note: There is a beginnings of a messaging system in interface.c:process_message_to_myself()

from aprx.

aprx should not have further actions (such as "forward as email"), those are quite clearly outside the scope of an igate and should be implemented as separate APRS-IS servers.

Please try to keep the focus on doing one thing and doing it well.

from aprx.

Being a digipeater is quite clearly outside the scope of an igate as well, so I don't think that argument holds water. I see aprx as an APRS packet router, and I feel that that includes shunting APRS messages to some other system to be processed.

from aprx.

Aprx has functions that are easy to do with embedded resources.
Mostly where AX.25 UI frame talk capability are useful.

from aprx.

How could we flesh out the implementation of process_message_to_myself()?

Right now, ack to RF interfaces is not implemented....Let's come back to that.

One poosibility might be a 'CGI'-style call to a shell script. process_message_to_myself() could open a pipe to an external shell. We could add a config item to the element, so you could specify:

<interface>
   serial-device {{kiss_tnc_device}} {{kiss_tnc_baudrate}} 8n1 KISS
   callsign     $mycall  # callsign defaults to $mycall
   tx-ok        true    # transmitter enable defaults to false
   telem-to-is  true # set to 'false' to disable
   <on-message>/opt/my-extension/bin/handle-my-message</on-message>
</interface>

The output from the message handler could be sent back in messages to the original sender. We'd probably want a limit of four or five lines of output (don't want to flood the rf channel).

But then those messages would need to be checked for 'ack' and re-sent on the sliding retry delay until an ack was received. Ditto for the 'ack' to the original message. Is there already a periodic timer or heartbeat that we can tie into for the 'ack's and retries?

from aprx.

I would suggest having some security on this if you allow it to execute programs or scripts. Perhaps a one-time password scheme or something. I could definitely envision uses for that capability.

from aprx.

@dandrzejewski - The end goal of this is actually to be able to power-cycle a repeater over remote control (see aprs-remote-control), so yes, security is an absolute requirement. We're thinking of using signed messages similar to the description in https://github.com/richark/aretf/blob/master/ARETF-APRS-Authentication.txt, with a couple of differences. First, I'm not comfortable with having a shared private key, so we're looking at a dual-key system. Second, recent discussions on the APRS-SIG list surfaced a suggestion that the "user-defined" packet would be a better choice than shoe-horning the signature into a message packet, and wouldn't incur the 67-character length limitation, which seems to be based on fitting a line onto a DOS terminal screen.

@PhirePhly - Yeah, the more I look at it, it doesn't make sense to add this to APRX. What I'm currently pursuing is a standalone message handler that would share the device with APRX using a port sharer like utils-for-aprs. That way, APRX can do what it does best (IGating and Digipeating) and the remote control system can do its thing independently.

from aprx.