[aprssig] IGATE message routing bug?

[Jim Alles]

On Sat, Nov 19, 2016 at 11:32 PM, Lynn W. Deffenbaugh (Mr) <
ldeffenb at homeside.to> wrote:

> Taking the discussion back to the public list so others don't ask the same
> questions later...
>

​Yeah, that is ok, I was going to re-write a little.​ comments in-line

"One IGate delivering packets to port 14580 does not affect any other
IGate's connection nor the ability for other IGates to receive messages
directed to any received station.  The APRS-IS is not "smart".  A message
addressed to a specific station is delivered to ALL IGates that have
recently gated packets from the addressed station."

Agreed & understood. I am only interested in the behaviour of the part of
the system I do have control over.

>
>
> On 11/19/2016 10:42 PM, Jim Alles wrote:
>
> "Changing the port to which received packets are delivered has absolutely
> no effect on "fixing" anything."
>
> I believe you are wrong - the packets inserted into the unidirectional
> port are not inserted into the heard hash table.
>
> The APRS-IS is smart enough to not try to send messages back to you
> ​ for transmission
>  -
> ​IT CAN'T - ​
> you aren't there.
>
>
> 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.​

>
> Remote operators are still showing up on the APRS-IS and there's still no
> indication that they came through a non-transmitting IGate.
>
​yeah, I get that, except that suggests a separate, more complex proposal -
put something like NOHERD into the path, and modify the server software to
behave differently based on that - but that is not what I am going after,
here.​

​Way over my pay-grade.​

>
> Not being in the heard table doesn't do anything as far as I can tell,
> except prevent your UDP-injecting IGate from receiving messages that it
> wouldn't likely have done anything with anyway?
>
1. ​Reduce ba​ndwidth requirements. As Kenneth mentions, a case was
presented elsewhere for an RX only IGate that was on a satellite link,
where every byte in either direction costs $. Eliminating the  traffic from
the server due to an entry in the heard list can be important to some, and
that is not 'allowed for' in the design document coupled with the client
capability we have. The IGate operator should have the control to be able
to make it stop.

​2. Reduce server resource loading​. See (I can't find the reference).

​this may need more explanation.:
​3.​ Craft the traffic coming back to me from the server by shaping what I
insert into the heard table (making it my responsibility) so I am not
dealing with cruft from a station that is outside of my ALOHA circle, is
not in my local RF territory, and sometimes I hear due to ducting (I guess
I shouldn't think 'skip' anymore). Instead of dropping it on the floor,
send those undesirable (for our local RF territory) packets to the
unidirectional 'sending-only client' port. If one of those happens to be a
message, another one survived.

I think, to guide people towards an operating procedure that prevents the
situation Bob observed, having a client default configuration that sends
range & hop filtered <position beacons> to the restricted port (TCP 14580)
in order to guide the right messages to me for transmission and ALL
objects, messages and other types to UDP port 8080 regardless of where they
came from (OK, still no TCPIP in the path).

Though subtle, it will make it easier for people to do what they want/need
to do, and less likely to break messaging.​ At least it would give me more
configuration options, to do what I see fit.

I am not pretending to be able to lecture anyone here on signal processing,
some of you have forgotten more than I will ever know.
But it has been my experience it is more effective to reduce the noise
before processing than try to deal with it afterwards. And a connection to
an APRS-IS server on the restricted port does multiply the # of packets I
get back from it, in comparison to what I sent to it. I really don't want
to send it ALL that I hear.

But I do want to make the Centre region a messaging powerhouse.

good night,

.ja.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161120/e3ec8f1c/attachment.html>