[aprssig] APRS-IS: frames bypassing server filter

[Heikki Hannikainen]

On Tue, 14 Jul 2020, Lynn W Deffenbaugh (Mr) wrote:

> On 7/14/2020 6:14 PM, Wojtek SP9WPN wrote:
>       W dniu 2020-07-14 o 00:12, Lynn W Deffenbaugh (Mr) wrote:
>             You will receive packets generated by any station that you have gated from RF to the
>             APRS-IS for some period of time after you've last gated one of their packets.  Try
>             matching up the stations you're receiving with the packets being subsequently received
>             back from the APRS-IS.
>
>       I'm not sure about this. Most of the stations in question are not heard directly, but only
>       digipeated to me. This shouldn't count, should it?
> 
> The packet originator is all that matters, not who you copied the packet from.  If you gate a packet from a
> station, even via a digipeater, to the APRS-IS, you will receive future packets originated by those stations
> from the APRS-IS.  This is to support the IGate design details documented at:
> 
> http://www.aprs-is.net/IGateDetails.aspx

I'll just confirm here that this answer is correct and accurate.

If a TX-capable igate can receive packets from a station via a digipeater, 
it can surely pass messages to that station via the same digipeater(s).

The idea behind that has probably been the assumption that most 
digipeaters are high up and with wide coverage, without Internet access, 
and the igates are somewhere low with Internet access and with much less 
direct coverage. These days 3G/4G access is so cheap that SIMs can be 
dedicated to hilltops at ease.

At some point there have also been a few incorrectly configured APRS-IS 
servers out there, with default filters on the 14580 port, returning 
unexpected packets if the client does not specify a filter. It's easy to 
spot these by looking at the status page of your server 
(http://serveraddress:14501/) and looking at the filter strings of each 
client.


I don't know if there is a real broader need for such highly optimized 
low-data-volume connection, or is this just a single client requiring 
this. At least here even the cheap 3€-a-month 4G IOT SIMs have large 
enough data caps to handle all of APRS, AIS, Flarm/OGN and ADS-B at the 
same time. If it takes a lot of time to implement, it might be more 
cost effective to just purchase a slightly more capable data plan.

If there truely is a broad need, maybe we could look at a method for the 
iGate to signal capabilities to the APRS-IS server. Somebody might suggest 
another port than 14580 without iGate support, but that is quite difficult 
to get broadly and correctly configured on all servers, and then there 
would be quite a few misconfigurations where a tx-capable iGate is 
connecting to the wrong port. So my suggestion would be for the iGate 
software to send an extendable capabilities command to the APRS-IS server, 
after logging in, in a key-value comment format that would be ignored by 
older servers:

#capabilities rxonly=1

Similarly to how you can currently change a filter with "#filter t/m" for 
example. The iGate software would figure out the correct capabilities to 
send based on its existing configuration (transmit enabled or not) without 
requiring new user-selectable switches.

The server could then disable transmit iGate support for an rx-only igate.

Don't rush into implementing this yet; this is just a proposal. I'm not 
sure at this point whether it's worth a lot of coding to do this 
particular change. On the other hand having an extendable capabilities 
command may be useful for other things, and some improvements could 
possibly be made to make messaging work slightly better.

>       Is this true for non-message packets, too? Because I hardly ever see APRS messages in the logs,
>       just beacons and telemetry all the time. If APRS-IS server sends packets downstream only to stop
>       me from uploading the same packets back, it sounds like a weird protocol design...

I think you got it backwards. Some of it is to stop you from transmitting 
extra packets to RF, when the station is also present on the APRS-IS 
directly and there is no need to transmit on RF.

> IGate (not the APRS-IS) can make informed decisions, packets are delivered to it.  This is to support #4 in
> the "Gate message packets and associated posits to RF if all of the following are true:" list, specifically:
> 
> 4. the receiving station has not been heard via the Internet within a predefined time period.
> A station is said to be heard via the Internet if packets from the station contain TCPIP* or TCPXX* in the
> header or if gated (3rd-party) packets are seen on RF gated by the station and containing TCPIP or TCPXX in
> the 3rd-party header (in other words, the station is seen on RF as being an IGate).

> But in every case that I recall researching, my IGate DID actually gate packets in "recent" history for every
> station who's packets I subsequently received from the APRS-IS.

The timeout is currently 3 hours in aprsc.

   - Hessu