[aprssig] Digi Deduplication Behavior
Stephen H. Smith
wa8lmf2 at aol.com
Tue May 20 23:57:32 CDT 2014
On 5/20/2014 11:05 PM, Kenneth Finnegan wrote:
> 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.
The dupe checking function is in virtually all software/firmware that handles
APRS-style n-N SSID decrementing. The KPC3s handle this correctly on n-N
type paths; i.e. WIDEn-N, TRACEn-N, SSn-N, etc. They DO NOT do this on classic
RELAY and plain WIDE path elements.
Apparently the dupe checking was part of the added code module that implemented
n-N decrementing when that capability was introduced, instead of being applied
to ALL path elements.
It was the lack of dupe checking on non-n-N traditional paths like RELAY and
WIDE that led to my inventing the "double WIDEn-N" scheme so that packets both
from home digis and from high-level true wides could be dupe-checked by KPC3s.
> 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).
In some devices and applications, this value is user-changeable. You can't
count on it ALWAYS being around 30 secs.
> 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
I think it's purely done on the payload, but not 100% certain.
> 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)?
It's one of those promulgated schemes that never gained traction.
The UIdigi firmware replacement for TNC2s actually had lines where you could
enter actual calls of adjacent digis at different headings from yours. These
would replace the next path element such as a generic WIDE, based on the
destination SSID value of the incoming packet . (I.e. a process similar to
substituting a real call for TRACE, but for the next digi down the line, rather
than your own.) All guides I have seen to configuring UIdigi have advised
users to just ignore these lines and leave them blank.
I suspect that part of the reason this never took off is that as you travel,
the desired direction you want to propagate toward would be constantly
changing. This would force you to keep changing the SSID enroute; a real pain
for trackers buried in the car's trunk.
A bigger problem with doing anything with destination IDs is that the Mic-E
compressed position format puts the latitude value here. Any moving station
with a north-south vector in it's velocity shows a constantly-changing value in
the destination field. Note that the Mic-E format is used exclusively by all
Kenwood and Yaesu APRS radios, and is a default option on TinyTracks; i.e. very
widely used by mobiles.
More information about the aprssig