Aprx does not support messaging

[PhirePhly]

Aprx contains no behavior for APRS Messaging. At a minimum, aprx should reject all messages directed at any of its aprx_interfaces. Further actions based on APRS Messages (forward as email, send to syslog, etc) would be a nice bonus but not as important from a spec compliance point of view.

[PhirePhly]

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

[hessu]

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.

[PhirePhly]

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.

[oh2mqk]

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

[trasukg]

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?

[dandrzejewski]

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.

[PhirePhly]

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.

[trasukg]

@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.