[aprssig] APRS-IS and I-gating

Sat Nov 5 12:35:22 EDT 2016

Sorry for the duplicate post, this is what I intended to send:

Replies in-line. And please take this as a philosophical rant, not
personally ;-)

On Sat, Nov 5, 2016 at 1:51 AM, Kenneth Finnegan <
kennethfinnegan2007 at gmail.com> wrote:

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

Agreed, and I fully understand that the spec is open to interpretation. To
me. a single courtesy position packet from a station AFTER I have just
I-gated a message from (-the 'association' mentioned) to my local RF is
sufficient, and helpful to the person receiving the message, to figure out
who it came from, and where they are, regardless of my normal scope of
operations as an I-gate operator.

Especially when this messaging thingy can be broken by two stations using
the same tactical calls, from opposite coasts of the continent.

The issue I have is that I am seeing third-party traffic (and objects -
these are supposed to be station positions) from digis I have heard once or
twice, from over 350 miles away, and *no message traffic logged*.

And, no I cannot configure my station to not show that extra stuff on the
map... with just any client. (I'll expand on that in another thread).
But the I-gate is supposed to be be making the heuristic decisions based on
the specific "TCPIP"-containing  packets. And I think that is the primary
purpose of this extra traffic, just on the basis of the 'heard hash table'
of my station.

And if it is simply up to preference, then I of course I can choose which
APRS-IS server to use. but not while using rotate.aprs2.net; which is
recommended, and normally good operating practice.

And I hesitate to say that, because in this case, I do NOT want to see
aprsc map bug-for-bug for the sake of consistency - again, the opinion is
mine.

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

I am  not sure what premise, but I am talking about a garden hose vs. the
slow drip I would expect - not the fire hose of

"RF-gate all traffic from APRS-IS" at all,

> 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.
>
> Agreed - though not meant for me & my map so much, as my I-gate softwares
consumption. That is why, as a novice I-gate operator I assumed 'I hadn't
seen the light' vs. the awful realization that I have stumbled on the need
to trouble-shoot two entirely different issues, at the same time, AND they
interact with each other.

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

Agreed 100%, however, there is one other point of confusion I have
uncovered. In most client software I have used, I cannot minimize traffic
any further than leaving the subscription/filter field blank, which is the
case for this test scenario. In my opinion, that is not enough, but again,
I'll save that for a separate thread.

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

Be careful, my first thread there was just me working through my confusion
as a new user of THAT client (when I am talking to myself, it is not likely
to be very coherent ;-)

Also, the test bench configuration described there is entirely different
than the one used for the purpose of this thread - do not be confused!

> --
> Kenneth Finnegan, W6KWF
>
> Thanks for your attention to this!

Jim A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161105/2084d126/attachment.html>