Can I setup a digipeater section to forward everything that's received on an interface, not just packets with a digi path?

[Greg Trasuk]

Hi all:

I'm working with a group from my local radio club (http://www.barc.ca).  We're trying to setup a remote control system through our APRS digipeater. 

tl;dr; We want to send a message to our digipeater and have it run a script to power-cycle one of our repeaters.

Here's the background...

The digipeater is run by a Raspberry Pi connected to a Byonics Tiny Traker.  The TinyTrak does the actual digipeating, but we also have APRX running to provide IGate functionality, routing RF packets to the Internet APRSIS system, and from APRSIS to RF.  It also sends out our beacons (e.g. we had a beacon out for the hamfest). 

We've had some difficulties with the Fusion repeater locking up.  We're going to get the firmware updated, and that should help, but in the meantime, I built a relay box that attaches to the digital outputs on the digipeater RPi and controls the power on the Fusion repeater (and indirectly the power to the Raspberry Pi that serves as the D-Star interface).  Along with a software utility that controls the digital I/O, the net result is that we can log in to the digipeater Pi over the internet (securely through ssh using dual-key encryption) and power-cycle the Fusion repeater. We can also power-cycle  the Internet router, just in case.

Which is great, but what if the internet connection is down?  It's a consumer-grade connection, and we've seen it go offline in the past (it's wireless, so it could be weather related, traffic-related, who knows?).

One of our group said, "I'd love to connect it to an APRS packet so we aren't dependent on internet connectivity."

APRX doesn't handle messages directly.  We thought about reading the 'aprx-rf.log' file, but that doesn't let us respond back with a status.  We considered using the AX.25 subsystem, but that seems to be overly complicating a system that works nicely as it is.  We have thought about adding the feature to the APRX source code, but none of has are all that current in 'C', nor do we want to go that deep into the APRX code.

I had a thought, though, which is...It’s already a digipeater.  It supports “Networked tcp-stream connected terminal devices” (Section 3.6.10 of the manual).  So… we make a daemon that sets up a server socket to listen on.  Then configure APRX to “digipeat” everything from the radio to that socket, and “digipeat” everything from the daemon to RF.  We’d have to decode the APRS packets from KISS format - but guess what?  That’s exactly what my ‘utils-for-aprs’ package does (in JavaScript).

I did a quick proof-of-concept on the idea.  The 'aprx.conf' file is included inline below, plus or minus some substitutions that Ansible will do when it's deployed to the digi.  With this configuration, APRX opens up a socket on the machine mentioned in the configuration, and 'digipeats' packets to it.  e.g...

2016-08-22 06:06:47.250 VA3TSK    d *VA3BAL-4>APJI23,VE3OAK*,WIDE2-1:>javAPRSIGate
2016-08-22 06:06:47.251 RC        T VA3BAL-4>APJI23,VE3OAK*,RC*,WIDE2*:>javAPRSIGate

Which is just about there.  The only problem is that it only forwards packets that have an unfulfilled digipeater path (note the 'WIDE-2-1' at the end of the packet from VA3BAL above).  If that's included in the messages, the digi will rebroadcast the power-cycle command, which I'd rather avoid.

So is there a way to setup APRX's digipeater in a kind of 'bridge' mode, where it forwards everything to the other interface?

Thanks in advance,

Greg, VA3TSK

'aprx.conf' - Note the {{blocks}} are substitutions that are resolved when the file is copied to the APRX machine
------------------------

# {{ ansible_managed }}

mycall  {{ mycall }}

<logging>
   pidfile            /var/run/aprx.pid
   rflog              /var/log/aprx/aprx-rf.log
   aprxlog            /var/log/aprx/aprx.log
   erlangfile         /var/run/aprx.state
</logging>

<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
</interface>

# Define the socket-based interface for the remote control system
<interface>
  callsign RC
  tcp-device {{rc_host}} {{rc_port}} KISS
  tx-ok true
</interface>

<digipeater>  # Path out to radio from remote control system (and other sources
              # if desired)
    transmitter $mycall
    ratelimit 60 120 # default: average 60 packets/minute,
                               #          burst max 120 packets/minute
    srcratelimit 10 20 # Example: by sourcecall:
                                #          average 10 packets/minute,
                                #          burst max 20 packets/minute


    <source>  # Remote control system
      source RC
    </source>
</digipeater>

<digipeater> # Path from radio to remote control system
  transmitter RC
  <source>
    source $mycall
  </source>
</digipeater>

[Claudio Núñez]

Hi Greg,

As i undestood you need to "catch" some "command" from APRS and do an "action".

That's a good proyect!!.

I will try to review your first design.

Let me see if I can help you with some idea.

As you say, APRX it's by design only I-gate and Digi, that's the reason isn't message capable. Don't need it!

In others words, APRX can't send a message  and for that don't confirm a message received (a).

But, actually you can recieve messages sended to the callsign of the igate/digi. ;-) 

This is an example of aprx-rf.log actually made with my station:

2016-08-27 18:58:40.197 APRSIS    R CX8FS-5>APDR13,TCPIP*,qAC,T2ROMANIA::CX8FS-2  :example of command{1

2016-08-27 18:58:43.748 CX8FS-3   T CX8FS-3>APRS,WIDE1-1:}CX8FS-5>APDR13,TCPIP,CX8FS-3*::CX8FS-2  :example of command{1

2016-08-27 18:58:44.757 CX8FS-2   T CX8FS-2>APRS,WIDE1-1:}CX8FS-5>APDR13,TCPIP,CX8FS-2*::CX8FS-2  :example of command{1

2016-08-27 18:58:52.203 APRSIS    R CX8FS-5>APDR13,TCPIP*,qAC,T2ROMANIA::CX8FS-2  :example of command{2

2016-08-27 18:58:55.747 CX8FS-3   T CX8FS-3>APRS,WIDE1-1:}CX8FS-5>APDR13,TCPIP,CX8FS-3*::CX8FS-2  :example of command{2

2016-08-27 18:58:56.747 CX8FS-2   T CX8FS-2>APRS,WIDE1-1:}CX8FS-5>APDR13,TCPIP,CX8FS-2*::CX8FS-2  :example of command{2

2016-08-27 18:58:59.196 CX8FS-2   d *CX8FS-5>APDR13,TCPIP,CX8FS-2*::CX8FS-2  :example of command{2

2016-08-27 18:59:28.292 APRSIS    R CX8FS-5>APDR13,TCPIP*,qAC,T2ROMANIA::CX8FS-2  :example of command{2

2016-08-27 18:59:31.747 CX8FS-3   T CX8FS-3>APRS,WIDE1-1:}CX8FS-5>APDR13,TCPIP,CX8FS-3*::CX8FS-2  :example of command{2

2016-08-27 18:59:32.747 CX8FS-2   T CX8FS-2>APRS,WIDE1-1:}CX8FS-5>APDR13,TCPIP,CX8FS-2*::CX8FS-2  :example of command{2

2016-08-27 18:59:35.197 CX8FS-2   d *CX8FS-5>APDR13,TCPIP,CX8FS-2*::CX8FS-2  :example of command{2

2016-08-27 19:00:27.238 APRSIS    R CX8FS-5>APDR13,TCPIP*,qAC,T2ROMANIA::CX8FS-2  :example of command{2

2016-08-27 19:00:30.747 CX8FS-3   T CX8FS-3>APRS,WIDE1-1:}CX8FS-5>APDR13,TCPIP,CX8FS-3*::CX8FS-2  :example of command{2

2016-08-27 19:00:31.747 CX8FS-2   T CX8FS-2>APRS,WIDE1-1:}CX8FS-5>APDR13,TCPIP,CX8FS-2*::CX8FS-2  :example of command{2

2016-08-27 19:00:34.111 CX8FS-2   d *CX8FS-5>APDR13,TCPIP,CX8FS-2*::CX8FS-2  :example of command{2

2016-08-27 19:00:37.879 APRSIS    R CX8FS-5>APDR13,TCPIP*,qAC,T2ROMANIA::CX8FS-2  :example of command{1

2016-08-27 19:00:41.747 CX8FS-3   T CX8FS-3>APRS,WIDE1-1:}CX8FS-5>APDR13,TCPIP,CX8FS-3*::CX8FS-2  :example of command{1

2016-08-27 19:00:42.747 CX8FS-2   T CX8FS-2>APRS,WIDE1-1:}CX8FS-5>APDR13,TCPIP,CX8FS-2*::CX8FS-2  :example of command{1

You can see the command "example of command" arrived from CX8FS-5 (my cel) to CX8FS-2 (my Igate).

But consider this:

1) Isn't confirmed by the protocol because of (a) so the sender will retry the command automatically several times, By design of APRS.

2) Appears in the log multiple times because of several configured interfaces, igating the packet. By design of APRX.

3) It's visible for ALL, so consider somebody else sending your message and executing your "action". :-{   By design of APRS.

It's not the best solution but if you have expertise parsing the file with Perl, Pyton or wherever script or program you are confident, could be a workaround for your problem.

I think it's possible to parse the file and avoid all inconveniences. but i think it's impossible to have feedback of the action with APRX.

Good luck.

Claudio

CX8FS

[Libor OK2ZO]

I'm not skilled in scripts programming. Just have some idea.

What about use ax25 interface for packets handling.
You should be able then write a simple script listening on ax25 port, same as aprx will. You can send packet-radio packet directly to the device, if you have strong enough signal there then. The script will recognise the command and sends boolean command to GPIO of a raspi.
Depending on the script, it can be also encripted by some code.

So, due a security reasons, I'd not suggest using aprs messages for such applications.

[Tom Hayward]

There is a simple solution to this: one-time passwords. This is how
the authentication works on the OpenTracker line:
http://wiki.argentdata.com/index.php?title=Authentication

To use it, you just send an APRS message to the OpenTracker containing
the one-time password and the command you want to execute, such as
toggle the relay or whatever. Now that it has been used, the password
is expired and will never work again. For the next command, you must
use the next password in your list.

Tom KD7LXL

[Libor OK2ZO]

ops, I've missed the words about AX.25. I know about some issues in newer kernel of rasbian, but! The change to ax25 iface is very easy and brings also some benefits while tunning modem and monitoring traffic..

[Libor OK2ZO]

Another easy solution is - put dtmf decoder to RX audio and you can control, what you want, using different codes.

What some sysops use here - GSM remote device - just send SMS.. :)

Why make it simply, when it is possible by hard way?! :)