[aprssig] Digi Deduplication Behavior

Kenneth Finnegan kennethfinnegan2007 at gmail.com
Tue May 20 23:05:00 EDT 2014


I'm trying to fully define the deduplication behavior for digipeaters.
This is to prevent any echos from other digipeaters of the same packet
from being digipeated again by the local repeater. Each transmitted
packet is somehow remembered for a period of time and all further
packets are compared against this list of previous packets.

I've seen two values for the dedup table age-out; 28 and 30 seconds.
I'm thinking the 30 is the correct value, for what little difference
it makes. Thus an identical packet received at least 31 seconds later
is considered a "new" packet (which is what makes the KCP-3 KISS
memory leak bug so fatal).

I haven't found a satisfying answer as to what fields the comparison
should be done for (be it a checksum of these fields or a one-to-one
comparison).  The routing path is obviously going to change with every
hop, but I've found an old thread where DigiNed was claimed to only
dedup on the information field, which would mean two stations
beaconing the exact same APRS message will be deduped (I'm really
splitting hairs here, aren't I?).

>From reading the spec, it looks like the full list of fields that we
could dedup based on is the source callsign, the destination callsign
(except for the SSID?), the AX.25 control and PID fields, and the APRS

The destination SSID is documented as being overloaded for routing
aliases, but grepping through my four day sample of APRS-IS, although
I see 2% of packets with non-zero destination SSIDs, most of them also
include WIDEn-N paths (usually entirely unrelated to the generic path)
and a quick sampling doesn't show any evidence that the destination
SSIDs were ever used.

Did the destination SSID get deprecated at some point? Does anything
actually change it (the expected behavior for generic paths wasn't at
all clear from reading chapter 4 of APRS 1.01)?
Kenneth Finnegan, W6KWF

More information about the aprssig mailing list