[aprssig] IGate Registering for ANSRVR (Messaging failures)

[Robert Bruninga]

Thanks…



If any user setting of anything in APRS deviates from normal consistent
expectations, the user should be cautioned against making such selections
and asked to confirm he knows what he is doing.  And then the setting shold
always be flagged as “non conforming” so the user does not forget he may
have broken APRS in his area…  Thanks, Bob



*From:* Kenneth Finnegan [mailto:kennethfinnegan2007 at gmail.com]
*Sent:* Friday, July 15, 2016 12:23 PM
*To:* Lynn W. Deffenbaugh (Mr); TAPR APRS Mailing List
*Cc:* Robert Bruninga
*Subject:* Re: [aprssig] IGate Registering for ANSRVR (Messaging failures)



I can't say with confidence what APRX does off the top of my head, but I
agree that it *should* be RF-gating based on seeing any type of packet from
a station come in on an interface. I'll need to ensure that that is the
default behavior.



That being said, APRX supports geographical filtering so it's possible for
users to configure APRX to be more restrictive with its RF-gating based on
distance, inside a rectangle, etc. Seeing an instance of APRX in the wild
which doesn't behave like we're discussing may be a deliberate
configuration choice by the operator.


--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/



On Fri, Jul 15, 2016 at 8:12 AM, Lynn W. Deffenbaugh (Mr) via aprssig <
aprssig at tapr.org> wrote:

I'm going on memory which is known at times to be faulty, but I believe
there is at least one IGate implementation that can be configured to
consider "local" to be based on distance.  But I also believe it to be true
that some IGates require hearing a position packet, not just any packet, in
order to consider a station available for gating messages from APRS-IS to
RF for that station.  I could be worng (sic) on both counts.

I can only state with conviction that APRSISCE/32 considers a station
"recently" "local" based on 30 minutes and at most 2 hops used (although
the calculation of that is interesting with stations originating WIDE2-1 in
a path, is that one used or was it originally that way?).  Eventually these
will be configurable, but for now, they're hard-coded.  You can see the
settings in an APRSISCE/32 instance by double-clicking the narrow vertical
bar immediately to the right of the map.  it will show the following
information:

Close Stations
<snip>
30 via RF (9 Direct 18 Local)
IStoRF: 2 hops in 30 minutes


If you want to see just the stations considered "Local", use View / None
followed by View / RF / Local.  Or you can send a ?APRSL query to an
APRSISCE/32 IGate and it will respond with a list of all currently "Local"
stations as defined for gating messages from the APRS-IS to RF.  Note that
this query is best done via the APRS-IS as the list can be fairly long.  A
?IGATE query will return the count of local, direct, and RF stations.  This
information is also periodically transmitted in an IGate status packet.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  If anyone can speak authoritatively on what criteria the other IGate
software uses for gating messages from the APRS-IS to RF, I'd be all
ears... er eyes and would love to be corrected or confirmed in my
recollection that one of them can consider distance rather than used hops.



On 7/15/2016 10:50 AM, Robert Bruninga via aprssig wrote:

In any case, most IGates must have received a position packet
from a station "recently" and consider it "close" enough
before messages will be gated from the APRS-IS for it.

WHAT!!???  This totally breaks APRS as a messaging system.  Where did this
come about.  It also breaks vicinity tracking, another very powerful APRS
capability.

There are MANY times and certainly in times of stress and emergency and
backup comms when a position is not possible or easy.  How did this creep
into the APRS system?

How do we fix it?

The criteria for IGateing back to RF is "LOCAL" meaning only that the
station was heard DIRECT or on the first hop.  (though this can be a
variable in remote areas)..

Bob
_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig



_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20160715/1adff43f/attachment.html>