Theme: APRS-IS

Jeff WA4ZKO wrote:
Let me preface this with I don't fully understand the behind the scenes decision making by APRS-IS. Over the years I've asked around and received a lot of conflicting answers.

Lynn KJ4ERJ wrote:
Rule # 1: The APRS-IS is simply a packet transport network. It doesn't make any decisions beyond dupe-suppression at the point of entry.

Jeff WA4ZKO wrote:
Maybe Lynn can share insight into how APRS-IS handles such a situation? Is it smart enough to only send the message to one i-gate or does it send it to every i-gate reporting him as "local" to them?

Lynn KJ4ERJ wrote:
The APRS-IS doesn't do any routing. It simply delivers packets to connected clients, including IGates, based on filters. But the 14580 "filtered" port is also sometimes referred to as an "IGate" port for the following reason.

When a packet is received from RF by an IGate which forwards the packet to it's upstream APRS-IS server, that server makes a note of the station that was gated and (effectively) adds a filter to that connection to deliver any messages addressed to those gated stations as well as any TCP/IP-originated packets for those stations (so the IGate can choose not to gate packets to RF for stations that are also directly connected to the APRS-IS).

So, when a message appears on the APRS-IS addressed to a station, no "decision" is actually made. It is delivered to all connected clients whose filter selects said packet for delivery. With the implicit filter adjustment made for inbound packets, this causes the message to be delivered to the IGate. What the IGate does with the packet is strictly a local decision.

You'll notice that the filter addition for gated packets also enables APRS-IS-only clients to receive messages. Since the connected client is injecting his own packets, messages addressed to that station are delivered to that connected client regardless of whether or not the originating station matches any of the explicit filters in place.

So, if there are multiple gates receiving and gating packets for a single station, all of those gates (provided they're connected to a non-filtered APRS-IS server, see below) will receive messages addressed to stations they've copied. If all of those gates are transmit-capable (hopefully they are, again see below), then they'll all transmit the message based on their locally configured gating parameters.

This all works very well for FM which benefits from the "capture effect". All of the igates may simultaneously transmit (although in practice, if they hear the slower one might wait for the frequency to be clear), but the target station will "lock on" to the most powerful signal and ignore the others.

On HF, it's not so nice. If multiple HF IGates key the transmitter at the same time, the result is hash and the message is likely to not be copied. And this will happen with every retry by the message originator because each retry will still be delivered to the same set of igates which will do the same thing when the message packet is received.

Jeff WA4ZKO wrote:
I suspect a workaround fix is to only have one dominate i-gate in a region that is a 2-way, the rest be rx only gates???

Lynn KJ4ERJ wrote:
Receive-Only IGates can break the APRS-IS due to the dupe-suppression vs the IGate filtering. Consider if a Receive-Only IGate continuously delivers packets to the APRS-IS faster than the local transmitting gate. The packets gated by the transmitting gate will always be dupe-suppressed at the point of entry and that may cause messages destined for the gated stations to never be delivered to that IGate.

It's actually more complicated than that, and it actually works fine as long as all IGates are directly connected to an APRS-IS server that is being fed from a full feed. But if an IGate is connected to a filtered APRS-IS server (some are), then dupe suppression can prevent that IGate's APRS-IS server from ever hearing messages addressed to stations that the IGate may have heard but were gated to the APRS-IS quicker by some other IGate.

Ok, now who wants to try to come up with an algorithm for "viscous" message gating? (I am NOT serious!)


Theme: Specific IGATE as path setting

Philip PA3DFN wrote:
The mechanism how messages are delivered back to HF bothers me for a long time. Propagation on HF can change dramatic in a very short time.

For example when I receive an position report from Cyril, DF1CHB, my I-gate sends it to aprs-is. So aprs-is remembers my I-gate and every traffic from aprs-is to DF1CHB will be forwarded to HF.

The problem in my opinion is the fact that aprs-is "remembers" the route back to DF1CHB too long. When my I-gate is not receiving DF1CHB for some time, aprs-is is still sending packets back to forward to HF by the I-gate

Maybe the solution for this should be a sort of extra mechanism to discard packets from aprs-is to HF. The best solution would be to do it in the aprs-is database. Or in the I-gate software.

The timeout value could be set by the I-gate operator by his experience and watching the propagation.

Lynn KJ4ERJ wrote:
The IGate itself is responsible for the final decision on whether to gate a message from the APRS-IS to RF. Unfortunately, some IGate software simply forwards on all packets received from the APRS-IS, relying on the network's behavior. Other IGate software uses a concept of "recently" "close" where "recently" is typically 30 minutes and "close" might be distance, digipeater hops, or some other metric chosen by the author.

IIRC, the APRS-IS "filtered" or "IGate" ports will remember received stations for 30 minutes.


Theme: Prevent an IGATE from gating me

Carl KB1EJH wrote:
What is the specific coding to prevent an igate from gating a station to the internet? Say, you have a local station that that is abusing your gate with messages and you want to block them. I had tried -s/callsign-* but no luck with that.

Lynn KJ4ERJ wrote:
There is nothing you can do to prevent an IGate from gating a station. Per the APRS-IS specs at http://www.aprs-is.net/IGateDetails.aspx


Theme: APxxxx identifier

Cyril DF1CHB (F1MHV) wrote:
This IS -> RF igating based on « APxxxx » messaging-device-capable id is interesting…

Lynn KJ4ERJ wrote:
APRSISCE/32 incorporates a "message capable" determination based on the detected platform of the station. Platform is determined by multiple methods, one of which is the APxxxx ToCall. Other methods are the Mic-E identifier, the actual beacon character used, and sometimes the actual packet contents.
However, this information is not used for gating messages, but simply to provide a "Send message to" popup menu option. APRSISCE/32 can still send a message to anyone, they just don't get the shortcut popup menu option if they're not thought to be message capable.
The issues I see with constraining message gating based on any such detection are: 1) Maintaining the compatible list as new platforms are defined and 2) platforms like the TinyTrak4 that may or may not be message capable. If you have a TT4 with an attached display (or AvMap4), it's message capable. Otherwise it is not. I suspect many users don't know about the MSGCAP setting which actually modifies the character used in the posit beacons to indicate (or not) message capability.
You did realize that the posit itself says whether or not the station is message capable? You shouldn't have to look at the ToCall? See aprs101.pdf for details.


TO BE CONTINUED