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

[Heikki Hannikainen]

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