[aprssig] IGATE message routing bug?

[Kenneth Finnegan]

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,
confusing problems.


> ​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
> contain
> 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
> (in
> 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
> path,
>

So you won't give RF-gate service to sources of messages which are directly
connected to the APRS-IS? Like CQSRVR?


> ​
> ​
> ​how about
> ​ resource​
>  loading on a raspberry ​Pi client? or a radio? or
> ​the​
>  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
modern network.


> ​​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
> hard-coded.
>

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?

--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161120/c81488fe/attachment.html>