Garbled echo-back caused multiple beacons

[Andrew P.]

Greetings, all.

I just had a weird "feature" with my station. I periodically run a 2-way I-gate for testing purposes, and found that APRS-IS was showing mangled copies of my beacon. Turns out the problem was that I was receiving mangled digipeats of my own beacon over RF, and, because the packet checksum didn't match, my station was I-gating the mangled packets immediately after the original "clean" packet was sent to APRS-IS.

Unfortunately, the mangling digipeaters didn't have tracing turned on, so I don't know who was chewing my packets. 

Should my station protect itself from such behavior by not digipeating or I-gating any traffic whose original sender's callsign-SSID matches my station's callsign-SSID?

Andrew, KA2DDO 

[Lynn W. Deffenbaugh (Mr)]

Are you sure it's the digipeater and not your own reception? If your
TNC is in PASSALL (if it has such a mode) or if you have any overruns or
parity errors on the serial line between the TNC and your system, this
behavior can occur.

It may be happening on other packets, but we typically only look at our
own raw packets.

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

Post by Andrew P.
Greetings, all.
I just had a weird "feature" with my station. I periodically run a
2-way I-gate for testing purposes, and found that APRS-IS was showing
mangled copies of my beacon. Turns out the problem was that I was
receiving mangled digipeats of my own beacon over RF, and, because the
packet checksum didn't match, my station was I-gating the mangled
packets immediately after the original "clean" packet was sent to APRS-IS.
Unfortunately, the mangling digipeaters didn't have tracing turned on,
so I don't know who was chewing my packets.
Should my station protect itself from such behavior by not digipeating
or I-gating any traffic whose original sender's callsign-SSID matches
my station's callsign-SSID?
Andrew, KA2DDO
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

[Andrew P.]

The funny thing is, now the problem has stopped happening. So I don't know if the offending digipeaters went off the air or what. I'm trying to see if there is a way to identify receive overrun, as it currently isn't reported. But it was very strange when it was happening, as I would see one mangle within a second of the original beacon, and the second (different) mangle about 20 to 30 seconds later.


-------- Original message --------
From: "Lynn W. Deffenbaugh (Mr)" <ldeffenb-***@public.gmane.org>
Date:10/22/2014 10:57 (GMT-05:00)
To: TAPR APRS Mailing List <aprssig-***@public.gmane.org>
Subject: Re: [aprssig] Garbled echo-back caused multiple beacons

Are you sure it's the digipeater and not your own reception? If your
TNC is in PASSALL (if it has such a mode) or if you have any overruns or
parity errors on the serial line between the TNC and your system, this
behavior can occur.

It may be happening on other packets, but we typically only look at our
own raw packets.

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

Post by Andrew P.
Greetings, all.
I just had a weird "feature" with my station. I periodically run a
2-way I-gate for testing purposes, and found that APRS-IS was showing
mangled copies of my beacon. Turns out the problem was that I was
receiving mangled digipeats of my own beacon over RF, and, because the
packet checksum didn't match, my station was I-gating the mangled
packets immediately after the original "clean" packet was sent to APRS-IS.
Unfortunately, the mangling digipeaters didn't have tracing turned on,
so I don't know who was chewing my packets.
Should my station protect itself from such behavior by not digipeating
or I-gating any traffic whose original sender's callsign-SSID matches
my station's callsign-SSID?
Andrew, KA2DDO
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig