Is what I ask possible in APRSISCE, ban a user from my iGATE


John Seiler
 

There is a amateur operator in the Pittsburgh Metro Area who has been beaconing every minute while mobile.  He was asked to change his beacon to no less than every 3 minutes and to use smart beaconing when mobile.  His one minute beacons is causing the digipeaters and iGATE to transmit his signals an unreasonable amount of time.  One digipeater with the greatest coverage in metro Pittsburgh purchased a new TNC which lets him code a banning of the individual.  As a result, his traffic moved to two other digipeaters, one purposely shut his system down because of the beating he has taken from this user, and the other is not operating for an unknown reason.    This individual has been asked very politely to change his beacons over the past 6 months, but has refused.  This individual has traveled south of Pittsburgh tonight and now my IGate picks him up and gates his beacons to internet every minute.  I am using a PC, APRSISCE software and a Kenwood D7100.  Is there a code sequence I can insert that would basically ban this user from my IGATE.  Alternately, is there any commend I can implement in the Kenwood D-7100 that would yield the same result.  I do not want to shut my system down and it is useful as a fill in digi.

Thanks,
John Seiler, K3MI


Lynn Deffenbaugh
 

There is no "blocklist" functionality in APRSISCE/32, and there never will be for IGating from RF to -IS.  The APRS-IS system can handle everything that the local 1200 (or even 9600) baud local RF channel can throw at it.

And I also don't know of any filters that can be applied to the D710 internal digipeater logic.

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


On 5/28/2022 7:19 PM, John Seiler via groups.io wrote:
There is a amateur operator in the Pittsburgh Metro Area who has been beaconing every minute while mobile.  He was asked to change his beacon to no less than every 3 minutes and to use smart beaconing when mobile.  His one minute beacons is causing the digipeaters and iGATE to transmit his signals an unreasonable amount of time.  One digipeater with the greatest coverage in metro Pittsburgh purchased a new TNC which lets him code a banning of the individual.  As a result, his traffic moved to two other digipeaters, one purposely shut his system down because of the beating he has taken from this user, and the other is not operating for an unknown reason.    This individual has been asked very politely to change his beacons over the past 6 months, but has refused.  This individual has traveled south of Pittsburgh tonight and now my IGate picks him up and gates his beacons to internet every minute.  I am using a PC, APRSISCE software and a Kenwood D7100.  Is there a code sequence I can insert that would basically ban this user from my IGATE.  Alternately, is there any commend I can implement in the Kenwood D-7100 that would yield the same result.  I do not want to shut my system down and it is useful as a fill in digi.

Thanks,
John Seiler, K3MI


N0YWB
 

Use Direwolf software TNC in place of the TNC built into the D-7100.  Direwolf can filter specific packets. See section 9.6 of the Direwolf User guide. https://raw.githubusercontent.com/wb2osz/direwolf/dev/doc/User-Guide.pdf


Justin Cherington
 

 As a result, his traffic moved to two other digipeaters, one purposely shut his system down because of the beating he has taken from this user”

His digi was always taking the beating, it just sounds like he wasn’t aware of it until the other digi closed up shop and now his digi is showing up on sites like aprs.fi.   Prior to that it was almost certainly still repeating the packets, it just wasn’t the fastest back to the servers and therefor was being discarded by said servers. 


not defending the beacon rate of this station, but is the latest digi owner actually experiencing anything different vs before? I’m in a very busy aprs area with thousands of packets received per hour and my modest setup handles it fine. What’s the specific issue? 


James Ewen
 

There are a number of scenarios to think about. 

1) This individual has set up his equipment and pays no attention to it, or how it is operating. 

2) This individual has set up his equipment is aware of it’s impact, and doesn’t care. 

3) This individual has set up his equipment is aware of it’s impact, and is actively monitoring it. They are observing the number of successful packets being delivered to the APRS-IS stream, and have chosen to use an aggressive setting in order to achieve a desired outcome via brute force. 

We probably aren’t looking at scenario number 1 because we have been told this individual has been contacted and made aware of the issue. 

If it’s scenario number 2, you won’t affect much change. 

If it’s scenario number 3, then actively working to try and block packets from this station may encourage the operator to use a more aggressive configuration in an attempt to be heard more by the APRS-IS. 

You could try moving all of your APRS infrastructure away from 144.390 to another frequency, but in the amateur radio world, the frequency spectrum is shared, and this station could move operations to the new frequency. 

Has anyone actually taken the time to communicate with the operator of this station? I’m not talking about a one way broadcast message, such as sending an email, but rather actually talking face to face, and asking what the operator is attempting to achieve. Find out what they are trying to do, and then maybe working to help educate them on how the APRS network works, what limitations it has, and the shared nature of the system. 

You might need to find someone that understands the APRS network operations to help with this as the first sentence quoted below shows that the writer does not understand how packets are handled in an APRS network. 

Many people tend to base their understanding of the operation of the APRS RF network based on the packets observed on the APRS-IS stream. One needs to understand that the packets observed on the APRS-IS stream are but a very minor subset of what is actually happening on the RF network. This limitation is by design. I-gates block delivery of packets to the APRS-IS if they have already seen a copy of that packet payload. Even the extremely fast APRS-IS network would get flooded if every copy of every packet ever heard on the RF network was forwarded to the APRS-IS stream. 

Think about that for a bit. The individual that decided it would be cool to gate packets from a 1200 baud RF channel to a multi-megabit network stream implemented traffic limiting right from the get-go to protect the APRS-IS from being flooded by packets. 

This built in protection is why there’s no concerted effort to limit the number of I-gates installed in a specific area. Only one I-gate will ever get to forward a copy of a packet to the APRS-IS. The rest just drop the packet. 

All digipeaters that support the next path element seen in a packet will handle that packet if they hear it. 

The removal of one digipeater from the network does not cause other digipeaters to suddenly spring into action. Any digipeater that heard the packet will have acted upon that packet in the past. If the observer is relying upon the APRS-IS, then the removal of a “fast” digipeater/I-gate combo will mean an alternate route will then show up. There has been no change in which digipeaters have been affected, except for the digipeater that was removed. The change is in which path is able to get the packet to the APRS-IS first. 

It can take some serious work to understand the nuances of how the APRS RF network functions. The easiest ways to learn is to start with a very basic system, observe its operation, and slowly add complexity, observing the interactions. 

Way back in the ancient path, when I was trying to figure out how to hand craft an APRS position packet, and we were setting up the first digipeaters in Alberta, I set up 4 digipeaters in my basement. I was sending test packets into the network, and observing the results. I had questions about what I was seeing, and I sent an email to Bob Bruninga asking for clarification on what I was observing. I had to chuckle at Bob’s reply which was “I don’t know for sure, I’ve never seen a properly deployed APRS network operating.”

Even Bob had a hard time with his baby because there are so many misconfigured digipeaters out in the wild. 

I believe I have a fairly solid understanding of APRS digipeater operations, but I get stumped a lot trying to figure out what is happening in and APRS network because of minor inconsistencies in the configuration of various digipeaters in the network. 

Minor changes can have significant impacts. One needs a very strong solid base knowledge of APRS digipeater operations to be able to reverse engineer the packets seen to try and figure out what is happening in the RF network. 

One cannot gain much insight into a complex digipeater network from observation of the APRS-IS stream as there is just too little information available. Doing so is akin to the parable of the blind men attempting to describe an elephant. 


On Sun, May 29, 2022 at 09:59 Justin Cherington <huntjlc@...> wrote:

 As a result, his traffic moved to two other digipeaters, one purposely shut his system down because of the beating he has taken from this user”

His digi was always taking the beating, it just sounds like he wasn’t aware of it until the other digi closed up shop and now his digi is showing up on sites like aprs.fi.   Prior to that it was almost certainly still repeating the packets, it just wasn’t the fastest back to the servers and therefor was being discarded by said servers. 


not defending the beacon rate of this station, but is the latest digi owner actually experiencing anything different vs before? I’m in a very busy aprs area with thousands of packets received per hour and my modest setup handles it fine. What’s the specific issue? 

--
James
VE6SRV


John Melcher, Jr.
 

What digi path does he use? APRS web site has some suggestions to reduce the amount of digipeating in a region.  1200 baud into a modern internet connection is below the noise level so I wouldn't worry much about APRS-IS load you're causing. 
73
John