[aprssig] APRS-IS: frames bypassing server filter

[Pete Loveall AE5PL Lists]

There are already 2 ways to not receive packets from the server: UDP and HTTP (send-only ports).  After watching abuses by people trying to "work around" built-in configuration restrictions by modifying paths, etc., I don't have any intention to alter javAPRSSrvr's operation to allow someone to "break" messaging by faking a receive-only IGate.  We added the qAO construct as a client-implementable construct to help determine a cause when messaging is reported as "broken" on RF but not to provide a switch to alter server operation.  Since rx-only IGates by definition break messaging, this was something that was desirable to determine why a particular IGate wasn't messaging.  It also lets us know who is connecting via non-IGate capable limited feeds (see FIRENET port 14580) and send-only ports when messaging is reported as "not working" between RF and APRS-IS.

If you don't want to see packets originated by stations heard on RF by your IGate (i.e. don't want to support messaging), you may be able to disable the gate capability in your client, change to using a send-only port (UDP or HTTP), or connect to a FIRENET port 14580 which do not support bidirectional IGates.  In all cases, we will know if your IGate is messaging to RF and other IGates will know your station has APRS-IS connectivity (so therefore will not gate to RF messages for your client).

The amount of data being passed to a rx-only IGate from the server is minimal at best and it has always been the job of the -IGate- to use those packets to determine what gets gated to RF.

73,

Pete Loveall AE5PL
pete at ae5pl dot net



-----Original Message-----
From: aprssig <aprssig-bounces at lists.tapr.org> On Behalf Of Lynn W Deffenbaugh (Mr)
Sent: Wednesday, July 15, 2020 9:28 AM
To: John Langner WB2OSZ <wb2osz at comcast.net>; aprssig at lists.tapr.org
Subject: Re: [aprssig] APRS-IS: frames bypassing server filter

So, if the APRS-IS server would look for the qAO on incoming packets on an IGate-capable port, they could skip the adding of the packet source to whatever they are using to forward future packets out that connection.  I like the idea.  I requires NO changes to the protocol, allows the IGate operator (and the software) to indicate in a standard fashion that it is receive-only, and the APRS-IS server can take action on information that is already being passed.  And it doesn't break if the IGate is connected to a non-supporting APRS-IS server instance, they'll just continue to receive the packets that they receive today.

APRS-IS server authors, what do you think?

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32