[aprssig] IGate (Identification? (RO or RT)?

[Robert Bruninga]

Is there a way to see who is one way, and who is 2 way?
I dont think so.

Looking at the raw packets, I see 6 IGates that hear my 2-2 packets (yes, I
coiuld drop to 1 hop), but if the local 1 hop IGaqtes are 1 way only, then
I just shot byself in the foot and dont know it.

So now the question is, can we ADD IT somehow.

It would have to be ADDITIVE.  That is, once we come up with the bit (we
only need ONE bit somewhere in the QXX construct to indicate it).  Then we
can at least see all future 2-way IGates (assuming all existing code is 1
way utnil upgraded).  Is there a way to do this without breaking anything?

That way I can see on a map WHERE my nearest 2 way gate is when traveling
and know what I am facing when traveling.

I think UIVIEW had a flag about being 2 way?  Others?

Bob, Wb4APR

On Fri, Jul 15, 2016 at 5:52 PM, Steve Dimse via aprssig <aprssig at tapr.org>
wrote:

>
> > On Jul 15, 2016, at 2:15 PM, Pete Loveall AE5PL Lists via aprssig <
> aprssig at tapr.org> wrote:
> >
> > #1 is Anthony's example.  The RO IGate gates his HT's message packet
> (let's say it is a messaging capable HT) but a bidirectional packet does
> not because it never gets digipeated.  The remote station sees his packet
> but the remote station's ack and possible responses are not seen since no
> bidirectional IGate considers his HT as local.
> >
> This is less broken than if the RO gate is not there? With an RO gate the
> the remote station gets the message but the HT does not get the ACK.
> Without the RO the remote station does not get the message. You aren't
> actually saying it is better the remote station does not get the message,
> are you?
>
> > #2 is a little more obscure but just as important since it is much
> harder to isolate.  Bidirectional IGate (let's call it RW) is connected to
> a server (connection type is irrelevant for this connection). That server
> (let's call it RW's server since it is often times either integral or in
> the same location as the RW IGate) is connected to APRS-IS via a restricted
> feed ("filter" is an inaccurate word; the feed is "restricted" to packets
> for the connected station and any stations the connected station has
> recently gated to APRS-IS plus any packets defined in a filter if
> defined).  Before you say it can't be or that is bad design, that is how
> most home installations of javAPRSSrvr are configured as they are on
> restricted bandwidth connections.  There are others who also run in this
> type of configuration.  Now, let's use the example in #1 but say the RW
> IGate does see that packet after one hop.  But the RO IGate already got the
> packet through APRS-IS to RW's server so dupe elimination prevents RW's
> server from sending the RW-received packet upstream.  Therefore, the
> upstream server to RW never sees the packet that RW gated to its server.
>
> I want to be sure I understand this. RO and RW hear the same packet, and
> are connected to the same javAPRSSrvr hub. RO gets the packet to the hub
> first. So of course everything upstream of that server only sees the packet
> from RO. The payload is identical but the path shows it came from RO, and
> not RW. And now what? Who cares what the path says upstream? Everything
> upstream is not filtered or restricted. Or is the mentioned upstream not
> the issue, and the problem happens in the first javAPRSSrvr? Does your
> software do the dup filtering BEFORE it determines which IGate sent a
> packet and blesses the sending callsign for passing through your
> 'restriction'? Only one IGate connection per javAPRSSrvr is fed the
> messages? If it is this, it sounds like a bug. If 10 IGates are connected
> to a single javAPRSSrvr and all heard the same station, all should get the
> every message to that station, right? If it is something else please try to
> explain again.
>
> The original APRServ hub offered a way to decrease bandwidth load on pure
> IGates by providing a feed with just messages and associated positions, and
> that is certain not to create problems. Granted there is more traffic now,
> but home bandwidth has also risen, and there aren't that many messages that
> it would be a serious issue for the vast majority of people.
>
> >
> > Now you might claim close-coupling of the software in #2 could force
> RW's server to send the packet anyway regardless of dupes but that is a bit
> self-defeating for other reasons and does not resolve the issue when the
> IGate is completely separate software from the server.
>
> Not suggesting this at all.
> >
> > I am not assigning "fault" to anyone or anything.  I am pointing out how
> RO IGates can and do interfere with APRS messaging.  I am also pointing out
> how this can be very difficult to track down with the denial of such cases
> (and these are only 2 examples).
>
> I'm interested in fault only to the extent it indicates what part of the
> system needs to change. I gave you five good reasons for one-way IGates,
> not to mention they are widespread and since the inception of the APRS IS
> they have been part of the landscape. If they really are causing a problem
> now the question is why and what should be done about it.
>
> If there are more examples I want to hear them. It makes no sense that an
> RO IGate should interfere with two way messaging, other than discouraging
> new, full IGates (just as your suggestion to create a zero hop IGate does).
> If there really are problems, it seems to me the problems might be caused
> by these things you've added, like the IGate restrictions, or perhaps bugs
> in your code. In this case isn't the correct thing to fix javAPRSSrvr
> rather than try to eliminate one way IGates?
>
> Steve K4HG
>
>
>
>
> _______________________________________________
> 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/20160716/37e7ff65/attachment.html>