[aprssig] APRS-IS: frames bypassing server filter

[Lynn W Deffenbaugh (Mr)]

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

>
>> This is done for several reasons.  One is to give you the opportunity 
>> to gate a "courtesy" posit for the source of any message you may have 
>> gated, but it is also so that your IGate can know if a staiton is 
>> injecting packets directly to the APRS-IS so you don't gate messages 
>> from the -IS to RF for addressed to a station that would have 
>> received them directly on the APRS-IS.
>
> 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...

Lots of people think the APRS-IS is an intelligent network with packet 
routing going on, but that is not the case.  The APRS-IS is simply a 
packet relay supporting RF communications via IGates. And in order that 
an 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).*

>
> I'd agree with Andrew KA2DDO: it seems there's some "minimal data 
> stream" offered to each Igate (and all IS-connected clients are 
> considered Igates). It probably serves some good purpose, but is not 
> well advertised.

In my experience and observations, this "minimal data stream" is all 
based on which stations' packets you have delivered to the APRS-IS.  And 
these packets seem to be delivered for longer than you'd expect as 
stations drive out of your RF coverage range.  And sometimes it seems 
like you get packets from the APRS-IS for stations that are nowhere near 
your station, but if you check your RF logs closely you'll likely find 
that you copied a packet via some digipeater path from every station 
within the past hour or two.  Yes, it does seem to go on that long.

I've not written an APRS-IS server, nor have I looked at the aprsc 
source code, but I have monitored the packets coming from the APRS-IS to 
a a filter-less IGate and have been just as confused as you seem to be.  
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.

I call it "WAD" - Working As Designed.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200714/43d02d72/attachment.html>