<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>One major problem with this is not all Tier2 servers support the HTTP POST and/or UDP submit paths. I'm testing new code in my client software for UDP submit, and so far, every time the DNS rotator for noam.aprs2.net gives me the IP address of a server that does not support UDP submit (doesn't have a listener open for it according to its status page). I may have to implement the more expensive TCP-based HTTP POST to get active confirmation of "no such port" at the server.<div><br></div><div>Are there any alternate domain names in aprs2.net that indicate only UDP-supporting servers, the way ssl.aprs2.net indicates only servers supporting APRS-over-TLS?</div><div><br></div><div>Andrew, KA2DDO</div><div>author of YAAC</div><br><br>-------- Original message --------<br>From: Pete Loveall AE5PL Lists via aprssig <aprssig@lists.tapr.org> <br>Date: 7/15/20 10:50 (GMT-05:00) <br>To: aprssig@lists.tapr.org <br>Subject: Re: [aprssig] APRS-IS: frames bypassing server filter <br><br>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.<br><br>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).<br><br>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.<br><br>73,<br><br>Pete Loveall AE5PL<br>pete at ae5pl dot net<br><br><br><br>-----Original Message-----<br>From: aprssig <aprssig-bounces@lists.tapr.org> On Behalf Of Lynn W Deffenbaugh (Mr)<br>Sent: Wednesday, July 15, 2020 9:28 AM<br>To: John Langner WB2OSZ <wb2osz@comcast.net>; aprssig@lists.tapr.org<br>Subject: Re: [aprssig] APRS-IS: frames bypassing server filter<br><br>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.<br><br>APRS-IS server authors, what do you think?<br><br>Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br>_______________________________________________<br>aprssig mailing list<br>aprssig@lists.tapr.org<br>http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org<br></body></html>