[aprssig] APRS-IS servers dropping packets sent to RF only by local clients

Fri Feb 16 06:50:18 EST 2024

This was put in place because this was a critical part of loop detection.  We have seen significant loops caused by people establishing multiple verified connections to APRS-IS and running multiple stations with the same callsign-SSID.  The loop prevention algorithms including the q algorithm were put in place because loops were literally crashing APRS-IS back in the early 2000s.  After implementing these algorithms, looping diminished significantly but that does not mean removing the loop prevention mechanisms would be "ok" now.  Quite the contrary.  We continue to see loops being detected and, therefore, being prevented.

If they want to see their packets on RF gated back to APRS-IS, either send them to APRS-IS directly (this also helps with telling other IGates that IGate is on APRS-IS) or don't use a verified login.  This part of the algorithm is also used to prevent someone making multiple verified connections to a server which, by definition, is looping.

One other thing they can do: if they want to check where packets might be gated to APRS-IS from, they can use a different SSID (send directly to RF using a different station than what is connected to APRS-IS).  They could reach out to their software vendor for that capability but be careful.  It is important that the -IGate- function use the same callsign-SSID  on RF as it uses on APRS-IS for other IGates to know who is connected.

73,

Pete Loveall AE5PL
pete at ae5pl dot net

-----Original Message-----
From: aprssig <aprssig-bounces at lists.tapr.org> On Behalf Of Heikki Hannikainen
Sent: Thursday, February 15, 2024 2:30 PM
To: aprssig at lists.tapr.org
Subject: [aprssig] APRS-IS servers dropping packets sent to RF only by local clients

I'd like to bring this question up for wider discussion, as a change to aprsc has been requested (persistently and with rather harsh wording). I'm suspecting it might not be safe and I'm not sure of all the consequences, so I'm quite reluctant to make a change.

Currently, if a verified client OH7LZB-1 is logged in to an APRS-IS server T2FINLAND (aprsc or javaprssrvr), and that client sends an APRS packet (perhaps a text message, or a position) only on RF, and that packet is received by another igate somewhere, and the packet traverses back to that same APRS-IS server T2FINLAND, that server will drop the packet and will not forward it to any other clients.

The server will not accept packets of a verified client (by that same callsign-SSID) unless that packet comes in from the client socket of that verified client. If it comes in from another igate, or another server, it's dropped.

In other words, an APRS-IS client must always send its own packets to the APRS-IS server, to ensure that they are received on the by all other APRS-IS clients.

This is documented in https://aprs-is.net/qalgorithm.aspx :

"""
     If a verified login other than this login is found in the q construct
         AND that login is not allowed to have multiple verified connects
         (the IPADDR of an outbound connection is considered a verified
login):
     {
         Dump to the loop log with the sender's IP address for identification
         Quit processing the packet
     }
"""

This is probably not well-known amongst users, and whenever someone wants to better see the RF transmit range, they might disable the transmission of their own packets to the APRS-IS, while they're still connected to it (acting as an igate, even).  They're then surprised that the packets are not arriving at the server and some clients are missing the packets.

Some users also have configured their software to send APRS text messages only to RF, not APRS-IS, while staying connected to APRS-IS, which will then cause the message to not be received by a recipient who happened to connect on that same APRS-IS server. This may be quite surprising for the user.

(The users of the VARA modem mentioned in the previous message would obviously need to do this to prevent a duplicate copy of the same packet, due to the destination callsign overwriting created a modified duplicate.)

I'm guessing something would break if this filtering was removed, but what exactly? Pete could probably comment better on the exact reasoning behind this step.

If it was removed, should the packet be fed back to the originating client having the same callsign too, or would that be asking for too much trouble? I wouldn't be surprised if a buggy igate might decide to retransmit its own packet again to RF.

Here are a few of the tickets and discussion about it, there have been others asking about this on Facebook APRS groups at least.

https://github.com/hessu/aprsc/issues/48
https://github.com/hessu/aprsc/issues/84

   - Hessu

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org