[aprssig] IGATE message routing bug?
kennethfinnegan2007 at gmail.com
Sun Nov 20 13:17:35 CST 2016
On Sun, Nov 20, 2016 at 6:13 AM, Jim Alles <kb3tbx at gmail.com> wrote:
> but, I am not certain about this not being able to get messages into a
> service that lives on APRS-IS:
> "a few of us noticed that we were not getting ANY messages into or out of
> the ANSRVR or CQSRVR."
When Bob says into or out of, he means out of. I think with the one
exception of Direwolf, I-gates unconditionally send EVERY packet they hear
to the APRS-IS, so the only way they weren't getting messages to CQSRVR was
if they were out of range of any I-gates, and no level of hand wringing
about APRS-IS filtering is going to fix that.
The I-gate filter was added to Direwolf to support the satellite guys not
getting vanity credit on aprs.fi for bouncing through a satellite if they
happened to be near an I-gate. A feature I refuse to add to Aprx because I
think filtering things going to APRS-IS will cause lots of subtle,
> Not the entire RF-gate decision process, my IGate still doesn't know if
> the station is present on APRS-IS, elsewhere. (And I am worried about
> mobile smartphone clients on this point, as it is).
To quote aprs-is.net:
> A station is said to be heard via the Internet if packets from the station
> TCPIP* [...] in the header or if gated (3 rd party) packets are seen on RF
> gated by the station and containing TCPIP [...] in the 3 rd party header
> other words, the station is seen on RF as being an IGate).
Your station can get a very good idea of if a station is connected to
APRS-IS somewhere else, but now it seems like you're talking about saving
RF bandwidth, which isn't one of the problems you list below.
> The client software absolutely has to drop the packets with TCPIP in the
So you won't give RF-gate service to sources of messages which are directly
connected to the APRS-IS? Like CQSRVR?
> how about
> loading on a raspberry Pi client? or a radio? or
> Dick-Tracy wristwatch
> that I get for some future Christmas?
Some of the APRS-IS servers are raspberry Pis. We're talking about APRS
here, which is a comically small amount of data compared to any other
> Existing problems:
> 1. Bob not getting INTO ANSVR.
He was, or he was out of range of any I-gates.
> 2. The guy with the satellite link.
Frankly, the guy with the satellite link who can't afford a few extra
packets coming in on the 14580 port shouldn't be running an I-gate. We
shouldn't be redesigning I-gate behavior just to try and save a few guys a
couple MB per month.
> 3. Not having access to the configuration parameters, when they are
The last thing we need to be doing is exposing more knobs for users to turn
when setting up their first I-gate. We keep slapping on these extra
parameters to be tuned, and then I start getting bug reports against my
software because someone turned one of the knobs that they don't understand
and APRS starts doing something really whacky.
> 4. getting my IGate client instance to work the way I want it to, within
> reason and to support the entire community.
That is not a problem. That is a desire. What is your I-gate doing or not
doing that you want it to? When your I-gate gates "X", then receives "Y"
from APRS-IS, what does it do? What should it do?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig