[aprssig] APRS-IS and I-gating

[Kenneth Finnegan]

On Fri, Nov 4, 2016 at 8:51 PM, Jim Alles <kb3tbx at gmail.com> wrote:
>
> The AGWPE port connects to two instances of Xastir, on different machines.
> One of these instances is latched on an aprsc server, with my personal
> callsign & passcode. The other instance is fixed on a JavAPRSSrvr, with the
> Penn State ARC callsign & its passcode.
>

Just for posterity, which specific -IS servers? I know there used to be
quite a number of -IS servers which tacked on extra filters on their 14580
ports despite what the client asked for (which is confusing and very
annoying), but I thought most of those servers had been fixed.


> So, without looking at any source code, my guess is it may be that the
> wrong field is being matched out of a parsed packet.
>

When you connect to a 14580 port with no additional user filters, the
server is left to heuristically decide which packets it thinks you might be
interested in. To quote http://aprs-is.net/javAPRSFilter.aspx - "So a
user-defined filter port (14580) will pass messages and [associated] posits
to the client and any gated station (and TCPIP packets from gated
stations), and nothing else until a filter definition is added."

So what you're describing sounds like the expected JavAPRSSrvr behavior. It
cc's you on all APRS-IS traffic for all stations which you have recently
I-gated, regardless of how far away they are now. Aprsc is more
conservative in what heuristics it uses to send you traffic you didn't
explicitly ask for. There are arguments for both methods; some prefer to
see their maps fill out with more stations, while others prefer the less
traffic from aprsc servers. Since the exact behavior is not rigorously
defined anywhere, I wouldn't say that either behavior is incorrect, and all
clients should be configured to properly handle either.


> I can't say that any of this wants to get transmitted on RF from Xastir.
> The log looks reasonable.
> However, there can be a significant impact on the local RF environment
> when an I-gate like Direwolf seems to want transmit most everything that
> comes in from the server.
>

Yeah, no. The premise is wrong here; you definitely don't want to ever have
a blanket "RF-gate all traffic from APRS-IS" configuration. APRS-IS servers
will send you plenty of traffic to keep your I-gate up to date on stations
recently heard via RF, but most of those packets are meant for you, not the
entire local RF network.

I-gates should only automatically RF-gate messages and associated posits
under something like the following conditions (quoted from the igate.c file
from Aprx):
*  1. the receiving station has been heard within range within
 *     a predefined time period (range defined as digi hops,
 *     distance, or both).
 *  2. the sending station has not been heard via RF within
 *     a predefined time period (packets gated from the Internet
 *     by other stations are excluded from this test).
 *  3. the sending station does not have TCPXX, NOGATE, or RFONLY
 *     in the header.
 *  4. the receiving station has not been heard via the Internet
 *     within a predefined time period.

You should be very conservative with what else you configure your I-gate to
RF-gate to the local network. Typical RF-gate filter configurations would
be for things like "these two repeater objects and any announcements
beaconed from that Internet-only APRS station" or "NWS alerts for the city
where this I-gate is located"

I haven't been following the thread on the Direwolf list very closely, but
if this blanket RF-gate everything behavior is default for Direwolf, that
is VERY concerning and arguably incorrect.

--
Kenneth Finnegan, W6KWF
Aprx Maintainer
http://blog.thelifeofkenneth.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161104/101ff51a/attachment.html>