[aprssig] APRS-IS: frames bypassing server filter

[Lynn W Deffenbaugh (Mr)]

Remember that there is NO INTELLIGENT ROUTING built into the APRS-IS.  
Any message addressed to a given station will be delivered to ALL IGates 
that have "recently" heard that station.  No such thing as "closest", 
nor "most recent", nor any other intelligence.  If an IGate delivered a 
packet from a station, that IGate will receive messages from that 
station for some period of time (measured in hours, if I'm not mistaken).

As Pete stated, it is up to the IGate software, not the APRS-IS, to make 
a decision on whether or not to forward the message to the local RF.

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


On 7/15/2020 10:58 AM, Mark Cheavens wrote:
> While not an IS author, the IS servers need to then only use qAO gated 
> packets as a source of last resort.
>
> Currently the message routing is to the last known source.
> - Unless I am wrong and ALL I-Gates will try and send a message?
>
> As an example:
> An APRS user is in range of "Harris". That packet is gated typically 
> by a few different I-Gates:
> 1. DURNGO (Mountain top I-Gate/Digi with low latency fiber - Proper 
> two way, 10,500ft)
> 2. KC5EVE-10 (My house in the valley 9,000ft also with low latency 
> fiber- Proper two way)
> 3. K5LRY-10  (Recieve ONLY I-Gate) - I don't know that HAM - It does 
> connect with "qAO"
>
> https://aprs.fi/?c=raw&call=HARRIS
>
> We need to make sure messaging works to the closest available two way 
> I-Gate.
> - If you look at other digi's in the "area" (Four Corners) you will 
> see that the above three I-Gates gate most of the packets.
> EGLPASS, LAMOSC, HARRIS, N5WNA-1
>
> Mark
> KC5EVE
>
> On 7/15/2020 9:27 AM, Lynn W Deffenbaugh (Mr) wrote:
>> Good catch John!
>>
>> 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
>>
>> On 7/15/2020 9:48 AM, John Langner WB2OSZ wrote:
>>> There is already a way for IGate stations to identify themselves as 
>>> two way
>>> or receive only.
>>>
>>> >From http://www.aprs-is.net/q.aspx
>>>
>>> qAR - Packet is placed on APRS-IS by an IGate from RF. The callSSID
>>> following the qAR is the callSSID of the IGate.
>>>
>>>
>>> qAO - (letter O) Packet is placed on APRS-IS by a receive-only IGate 
>>> from
>>> RF. The callSSID following the qAO is the callSSID of the IGate. 
>>> Note that
>>> receive-only IGates are discouraged on standard APRS frequencies. 
>>> Please
>>> consider a bidirectional IGate that only gates to RF messages for 
>>> stations
>>> heard directly.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> aprssig mailing list
>>> aprssig at lists.tapr.org
>>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>>
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200715/3af28e15/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: emfgjfhkjnfdbiff.png
Type: image/png
Size: 23383 bytes
Desc: not available
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200715/3af28e15/attachment.png>