On Tue, Oct 27, 2009 at 4:01 PM, Tom Hayward <[email protected]> wrote:
> Looks like the BALDI Tracker2 is signing the used-digipeater path
> twice. What's going on here?
>
> N7NJO-14>T7QURQ,BALDI,WIDE1,BALDI*:`22.mRvu/]"3w}=
>
> I think the original path was WIDE1-1,WIDE6-6, but I can't be certain.
> So far, this is the only packet I've seen signed twice. I didn't see
> any evidence to indicate that BALDI was actually digipeating twice, so
> I think this is just a signing issue.
The digipeater should only insert it's call when it is handling the packet.
Here are a couple more...
2009-10-26 15:13:01 MDT:
N7NJO-14>T7QUWX,BALDI,WIDE1,BALDI*,WIDE6-2,qAR,KD7DVD:`23rlA*u/]"3{}=
2009-10-26 15:13:03 MDT:
N7NJO-14>T7QUWX,BALDI,WIDE1,BALDI,ETIGER,KOPEAK*,WIDE6,qAR,AC7YY-12:`23rlA*u/]"3{}=
2009-10-26 15:14:30 MDT:
N7NJO-14>T7QUWX,BALDI,WIDE1,BALDI,TWOODS*,WIDE6-1,qAS,KJ7XE-11:`23rlA*u/]"3{}=
[Duplicate position packet]
The second and third packets listed are actually the same packet, but
being handled by different digipeaters after BALDI, and also being
injected into the APRS-IS via different i-gates. Looks like KJ7XE-11
is probably running a KPC-3 in KISS mode with his UI-View station,
since he's showing the tell-tale delayed packet symptoms.
What's your anti-dupe time on BALDI? You'll notice that in both cases,
BALDI acted upon the WIDE1-1, and then later on acted upon the WIDE6,
but at WIDE6-3 in both instances. Yet in the rules that you listed,
you have WIDE2 as an alias, with a hop limit of 2. Something doesn't
jive here... According to the rules, you'll only act upon WIDE2-2 and
WIDE2-1... you also say that WIDE1-1 with a hop limit of 1 is
disabled. The packets above tells us that this is not so. Unless
there's another BALDI out there, your rules are not what is in the
digipeater.
James
VE6SRV
