Date
1 - 7 of 7
Strange flood of digipeated packets on KD0TLS-1 I-Gate
|
Todd Dugdale
I'm not sure if this is an APRSIS32 issue, or a general question about the APRS network. Either way, I find it to be baffling and mysterious.
My small I-Gate, KD0TLS-1, experiences a flood of digipeated packets about once a month. It stops when I need to restart the Win10 tablet that runs APRSIS32. The gateway is in suburban Minneapolis, and normally has an RX range of about ten miles -- confirmed by the capability stats of APRSIS32. Normally, it receives less than 400 digipeated packets each month. When this flood starts, the station starts gating roughly 500 packets an hour. Currently, that figure is sitting at over 74k for July. Many of these digipeated packets originate from far outside of the area: Michigan, western WI, SD, IL, NE, etc. I see this by looking at the map on aprs.fi. It's as if my small gateway is the only one for hundreds of miles -- but it's not, obviously. I wrote a blog post about this, and you can refer to it for more details. After I wrote that post, I rebooted the tablet for a Windows update and the flood stopped. Then it began again a week later. It stopped this morning when I restarted the tablet. This was an additional roughly 10k packets that week alone. I should emphasize that, for whatever reason, this flood is limited to digipeated packets only. My direct coverage remains unchanged. Nothing has changed in my station in any way to explain this, other than rebooting the Win10 tablet running APRSIS32. I'm not really complaining about this, or looking for a way to end it. I just find it incomprehensible. I've seen this happening to other small RX-only gateways in the MSP metro; never to the large gateways or digis, though. Any possible explanations? Todd Dugdale KD0TLS Plymouth, MN |
|
|
|
Lynn Deffenbaugh
First, let it be said that aprs.fi is NOT the place to try to determine what is going on in your local RF environment. The automatic dupe suppression of the APRS-IS transport guarantees that only the FIRST copy of any packet will be distributed causing aprs.fi to have a very incomplete set of packets. So, what does your local APRSIS32 instance tell you? Especially for those stations that you believe it is gating from "far outside" of your local area? The easiest way to answer this question is to do a "View / None" (confirm any removals if it asks), and then a View / RF / All. That window will then only show stations that have been received via an RF port, which is your TRUE RF coverage regardless of anything that anyone else is seeing. Another good setting to toggle in any APRSIS32 instance is to check Enables / Ports / Log All. This will cause APRSIS32 to write *.PKT files containing every packet that came through any RF port. This can be very handy when you're trying to diagnose long term (measured over days or weeks) issues like you are describing. Turn this on now and keep it on. When a problem happens, you can look at the *.PKT files and hopefully determine what the baseline is and what is/has changed as far as packet reception goes. For RF-supporting stations, I also like to check Configure / Scroller / Show IGate/Digi and Configure / Scroller / RF Only. This will cause the packet scroller on the left side to only show RF-received packets and add a new column that shows the digipeater from you copied the packet on the left and the originating station of the packet on the right. Of course, all of these packets should be * because we're asking to only see packets from RF. You may have to make sure that Configure / Scroller / Show All is NOT checked because it will trump all other filter settings (just like View / All does). Once this has been done, you can view the hourly packets on a
per-port basis by double-clicking the upper left pane to bring up
the Port Status list. Find your RF port in this list and you
should see a string of numbers for the most recent 8 hours with
the most recent hour listed first. Checking these numbers every
now and then will give you a much better idea of your actual RF
packet rate than anything that aprs.fi will ever see via the
APRS-IS network. The final advanced thing you can play
with is the various settings in Screen / Paths / Appearance. This
is what controls the lines connecting stations via digipeaters to
your IGate. You can play with the Times radio buttons at the
bottom of this dialog to get an idea of the "recent" coverage
coming into your station. Or check All to see everything that
your station is currently remembering.
And finally, since you are apparently
restarting APRSIS32 periodically, you can set Configure / Save
Posits / Save Filter to t/p to have it record all currently known
station position packets and reload them on startup. This is only
effective if you are immediately restarting APRSIS32 because the
saved posits are time-stamped and old posits (> 2 hours or so)
will not be reloaded on startup.
And when you see a packet flood
happening, you can always Enables / View Logs / Port(Mobilinkd)
and Enable that trace log to see the raw traffic to your TNC. It
almost sounds like you're getting some sort of echo or feedback
where multiple copies of a single packet are arriving from the
TNC. The *.PKT files mentioned earlier can help see if that is
the case, but the Port(Mobilind) trace log will provide immediate
visibility.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32 On 7/26/2022 12:51 PM,
todd.dugdale@... wrote:
I'm not sure if this is an APRSIS32 issue, or a general question about the APRS network. Either way, I find it to be baffling and mysterious. |
|
|
|
Todd Dugdale
I've set things up as you suggested this evening. Thanks for the specific instructions. I don't see how this is going to show me digipeated packets from far away, though. It seems that it will only show me the last local digipeater that handled the distant packet. But you know your own software.
The flood stopped after I rebooted the tablet for updates, but I'll watch the logs when it happens again. I just want to once again state that I'm talking about my gateway gating digipeated packets from 500-700 miles away. These aren't local packets, they aren't a handful from tropo. Initially, I tried Paths. But I had to set the screen so wide to potentially see stations originating from Nebraska and Iowa to Michigan and Canada, that it wasn't really worthwhile. Someone else suggested that these distant packets are really coming over -IS, and aprs.fi is falsely attributing dupes to my gateway. This is nothing more than speculation, however. I've also contacted two (of about five) gateway operators locally that have also experienced this in the past. Neither of them use APRSIS32, so that kind of points away from the software being the cause. I really appreciate you looking into this. These are excellent suggestions that will make my gateway more interesting and useful, regardless of the flood situation. |
|
|
|
Arnold Harding - KQ6DI
I had a similar experience about a year ago with a couple of IGates I control/monitor. The IGates I have run Direwolf, so again, different. What it appeared to be is some of the APRS-IS servers don't understand some of the filtering commands passed to them. It was only some of the APRS-IS servers.
I "fixed" the issue by removing the 'noam' or 'rotate' from the APRS-IS server list, and I force specific servers I know work correctly. This causes other issues when these 'forced' servers go down, but far better than constantly spewing on RF.
This might not be your issue at all. But it does sound a lot like what I was getting. Keep track if this only happens when you are connected to some specific APRS-IS servers. Maybe there is some pattern. I do know filtering sent to the APRS-IS servers played a big part.
Good luck with this issue.
Arnold, KQ6DI
|
|
|
|
Rob Giuliano
I can only speculate here. But, to me, if you are gating these distant packets to the IS system, then your station is likely hearing them over RF. They most likely are being placed on your 'local RF' by someone with an issue in their setup which probably includes a path. Find the IS->RF gate that is causing the problem, and you will likely find a solution. Robert Giuliano
On Thursday, July 28, 2022 at 08:34:55 PM EDT, todd.dugdale@... <todd.dugdale@...> wrote:
I've set things up as you suggested this evening. Thanks for the specific instructions. I don't see how this is going to show me digipeated packets from far away, though. It seems that it will only show me the last local digipeater that handled the distant packet. But you know your own software. The flood stopped after I rebooted the tablet for updates, but I'll watch the logs when it happens again. I just want to once again state that I'm talking about my gateway gating digipeated packets from 500-700 miles away. These aren't local packets, they aren't a handful from tropo. Initially, I tried Paths. But I had to set the screen so wide to potentially see stations originating from Nebraska and Iowa to Michigan and Canada, that it wasn't really worthwhile. Someone else suggested that these distant packets are really coming over -IS, and aprs.fi is falsely attributing dupes to my gateway. This is nothing more than speculation, however. I've also contacted two (of about five) gateway operators locally that have also experienced this in the past. Neither of them use APRSIS32, so that kind of points away from the software being the cause. I really appreciate you looking into this. These are excellent suggestions that will make my gateway more interesting and useful, regardless of the flood situation. |
|
|
|
Todd Dugdale
I think there might be something to this. The last time this happened, I was rotated to T2FINLAND, and I didn't rotate off for nearly two weeks. Restarting my tablet would rotate me to a different server, thus 'solving' the issue.
It seems that no real harm is being done by this phenomenon, but now I have tools to dig into it a little deeper and confirm that it doesn't involve RF reception at all. Todd D. KD0TLS |
|
|
|
Todd Dugdale
Rob,
someone locally said the same thing but couldn't explain how rebooting my tablet affected the misconfigured digi, or explain why only one gateway (mine) of a dozen was receiving all these packets from a misconfigured digipeater This is what moved the local speculation toward my gateway being misconfigured. Aside from the logging changes Lynn suggested, KD0TLS-1 is configured exactly the same as it has been for years. The only difference is that I upgraded the Mobilinkd TNC 1 to the new TNC3 -- but this was happening both before and after that upgrade. |
|
|