[aprssig] APRS-IS: frames bypassing server filter

Tue Jul 14 22:05:03 EDT 2020

 That's a very interesting question.
The APRS-IS backbone was deliberately and intentionally architected to support _two-way_ communications (as is mandated by most national amateur radio regulations), not receive-only monitoring and one-way broadcasting. One could technically claim (if they want to be an arm-chair lawyer) that receive-only I-gates are a violation not only of the APRS-IS architecture, but also of the amateur radio regulations because of deliberate blocking of and interfering with transmissions. Of course, the converse issues of preventing illegal transmissions (by either unlicensed senders, or senders in jurisdictions not having third-party traffic agreements with the I-gate's jurisdiction) makes that muddy, too, but the fact that legitimate RF users have a broken expectation of two-way communications if their packets make it to the APRS-IS backbone can be considered a problem.

Rather than change the architecture of the APRS-IS, which would require modifying every single Tier 2 server in the net (otherwise, the rotators could connect you to a non-fixed server at any time), a better solution might be to create a proxy pool to handle Rx-only I-gates. Such a proxy server would accept the RF->IS traffic from such I-gates, and would discard the traffic coming back.
An even better solution would be to use UDP delivery of received RF packets. Many of the existing Tier 2 servers support inbound-only traffic via UDP. Two-way users would still need to use TCP connections (some servers claim to support two-way UDP, but I can't comment on how well it works with client system firewalls in the way). However, the class of client being discussed here deliberately does not want two-way traffic anyway. Using one-way UDP does require that the I-gate software in use supports that protocol variant. How many I-gate-capable programs currently support UDP-submit to APRS-IS?
Andrew, KA2DDOauthor of YAAC (which currently doesn't support UDP-submit)

    On Tuesday, July 14, 2020, 8:25:20 PM EDT, Mobilinkd LLC <mobilinkd at gmail.com> wrote:  

 What would it take to change this behavior so that RX-only iGates with metered data connections can avoid consuming this unwanted & expensive data?
Kind Regards,

Rob Riggs WX9O
Mobilinkd LLC

On Tue, Jul 14, 2020 at 6:35 PM spam8mybrain via aprssig <aprssig at lists.tapr.org> wrote:

The purpose of the minimal data stream is so your Internet-connected station can function as a transmit-capable I-gate, not just a receive-only I-gate. The minimum packets you receive from the Internet are those intended for stations that your I-gate has delivered to the backbone, under the assumption that your I-gate is one of the nearest stations to send responses back to the RF station. The assumption is, if you can hear them on RF, you can send back to them on RF (and the backbone doesn't understand the concept of I-gates that can't, so you can't turn off such IS->RF traffic). 
The backbone sends such packets to all such I-gates that report receiving the RF stations, to ensure a redundant path to get to the RF station. After all, not all I-gates may be capable of transmitting at the time of packet receipt and getting all the way to the RF station (especially if the RF station is mobile and has moved since the last RF->IS-forwarded packet from it).
Hope this helps explain this design decision of the backbone servers.
Andrew, KA2DDO

-------- Original message --------
From: Wojtek SP9WPN <sp9wpn at gmail.com> 
Date: 7/14/20 18:14 (GMT-05:00) 
To: aprssig at lists.tapr.org 
Subject: Re: [aprssig] APRS-IS: frames bypassing server filter 

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?

> 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...

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.

Regards,

Wojciech

-- 
73!
Wojtek SP9WPN

_______________________________________________
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/b65d46fc/attachment.html>