[aprssig] IGATE message routing bug?

Sun Nov 20 15:05:15 EST 2016

Pete said:
Accidentally sent this to just Kenneth.  My mistake as it was meant to be
publicly posted.

Pete, I do appreciate your posts, particularly this one. However, I don't
think discussing RX-only IGates constitutes encouraging them - I am just
trying to figure out how to improve that situation, and mine. If you have
any suggestions on how to effectively handle the RF traffic based on the
screenshot I just posted, I am all ears.

I did turn off my RX-only IGate (except for testing) and I am drilling
holes & soldering to build the computer interface to a 2m Transceiver. That
is what I am doing to improve APRS messaging locally.

Can anyone tell me if the the UDP/HTTP port or the qAO construct is
available for use in any client software?

Does the server duplicate checking really happen to a packet before
insertion into the connected clients' heard list?

I am going back to breathing lead fumes, for now.

.ja.

On Sun, Nov 20, 2016 at 9:58 AM, Pete Loveall AE5PL Lists <
hamlists at ametx.com> wrote:

> Accidentally sent this to just Kenneth.  My mistake as it was meant to be
> publicly posted.
>
> You are correct, Kenneth, as Lynn expressed and I went into greater
> detail, Jim's suggestion (which is already available via send-only ports
> such as the UDP and HTTP ports as you describe) achieves NOTHING because he
> does not understand the premise of an IGate.  It was determined from
> reviewing Bob's packets that he was making it to APRS-IS but that the
> injecting IGates were either RX-only (what he is asking to encourage here
> with using UDP & HTTP ports) that NEVER support messaging regardless of
> port they are attached to or Bob's station was considered outside of the
> nearest bidirectional IGate's "local" area (it was never determined what
> that "local" definition was for any of the IGates and I showed that Bob's
> digipeater "paradigm" makes it very complex to determine number of hops).
> It was not determined what defined that "local" area for the nearest
> bidirectional IGates (which we also didn't know which ones were
> bidirectional) but it had NOTHING to do with the servers that the IGates
> were connected to.
>
> Again, a RX-only IGate provides a FALSE sense of coverage as it is
> INCAPABLE of supporting messaging as APRS messaging requires BIDIRECTIONAL
> communication which a RX-only IGate CANNOT provide.  Yes, in very limited
> circumstances a RX-only IGate can be beneficial (SATGate, tracking-only
> alternate network for special events, etc.) but it is not beneficial on the
> general APRS frequency for general amateur radio use where messaging can be
> used and is encouraged.
>
> If Jim wants an IGate to simply show (without actual operational effect as
> previously discussed) that a received packet is "out of range", that
> mechanism is in place as is the mechanism for a RX-only IGate to show it is
> RX-only.  That mechanism was added to the Q algorithm by having the client
> use qAO (letter 'o' not zero) instead of qAR for those gated packets.  It
> was actually there all of the time but the ability for a client to use it
> was added after the discussion on Bob's thread.  Please note, however, that
> this is only an indicator that most people will never see because they will
> go to a nice GUI (including their own Internet connected clients) and only
> see they were tracked, not that a portion of the track did not have
> messaging coverage.  Jim's approach of trying to use different ports, etc.
> for packets gated to APRS-IS does not accomplish anything other than
> provide a seldom-seen indicator that a packet was -first- injected by an
> IGate unable to provide messaging services to that station on RF.  Note
> also that I said "first injected".  Because of server dupe checking which
> is critical to loop prevention, etc., we only see the first packet gated to
> APRS-IS, not any later packets which might include a bidirectional IGate
> within range (or an IGate that doesn't show qAO).  Use of the qAO construct
> is not harmful (its purpose has always been to simply show a gated packet
> without the ability to support messaging but no functional use in the
> APRS-IS network) but could provide a -clue- to why messaging in an area is
> not working.  BUT, it will also provide many "false positives" since the
> purpose of many is RX-only IGates is to provide "fill-in" coverage where
> the RX-only IGate is the first to see the direct packet before a nearby
> bidirectional IGate sees it via a digipeater.
>
> If Jim wants to improve messaging between APRS-IS and RF, encourage
> bidirectional IGates in lieu of RX-only IGates.  That will have the most
> positive effect on inter-network messaging.
>
> Hope this helps.
>
> 73,
>
> Pete Loveall AE5PL
> pete at ae5pl dot net
>
> > -----Original Message-----
> > From: Kenneth Finnegan
> > Sent: Sunday, November 20, 2016 2:05 AM
> > To: Jim Alles <kb3tbx at gmail.com>; TAPR APRS Mailing List <
> aprssig at tapr.org>
> > Subject: Re: [aprssig] IGATE message routing bug?
> >
> > On Sat, Nov 19, 2016 at 10:43 PM, Jim Alles <kb3tbx at gmail.com
> > <mailto:kb3tbx at gmail.com> > wrote:
> >
> >
> >       On Sat, Nov 19, 2016 at 11:32 PM, Lynn W. Deffenbaugh (Mr)
> >
> >               But I don't understand just what you think that "fixes"?
> >
> >
> >
> >       Bob's original problem - message packets got dropped until after a
> > position report was received.
> >
> >       Somebody configured something with the limited tools they had.,
> to get
> > control of the useless packets that wanted to be transmitted.
> >
> >
> > Bob's original issue is that there is disagreement between
> implementations on
> > the definition of what stations are "near-by" and which units (km or
> hops)
> > should be used when expressing the concept of near-by. When your RF-gate
> > heuristic is "within 50km of me" you HAVE to wait for a position packet
> before
> > starting to RF-gate to a station. If your metric is instead "within one
> digipeater
> > hop of me" you can start providing RF-gate service as soon as you
> receive any
> > type of packet.
> >
> > I don't see how you have changed anything here other than moving when the
> > RF-gate decision is made. As it stands now, I-gates send all their
> traffic to
> > 14580 and then get CCed back on all packets that the APRS-IS considers
> at all
> > possibly relevant to that I-gate; the I-gate then processes this feed
> from the
> > APRS-IS to decide which packets to RF-gate (which is very few of them).
> >
> > In any case, we're getting lost in the weeds here. Before you start
> describing
> > how us I-gate programmers need to be rewriting our uplink interfaces to
> the -IS
> > and how we should be defining a new NOHERD alias to solve something, you
> > need to very clearly describe an existing problem, how the current
> algorithm
> > does not solve this problem, and how your change would improve on it. I
> still
> > have not seen any of your comments line up a real existing issue with a
> possible
> > solution to it.
> >
> > --
> > Kenneth Finnegan
> > http://blog.thelifeofkenneth.com/
> _______________________________________________
> 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/20161120/df268f3e/attachment.html>