[aprssig] Re: Tracing SSn-N paths! WOW

[Robert Bruninga]

Did I jump the gun?  (2 minutes later)....

I cannot remember if the ID parameter overwrites only
the previous digi, or ALL previous path data.  Rememebr,
that is always why I dispised ID for these many years.
If it obliterates ALL prior path data, then this idea is dead.

But if it only overwrites the immediately prior digi entry,
then the packet will arrive like this:

Sent:        SS1-1,SS3-3
Arrives     DIGI1,DIGI2*,SS3-1
Not as     DIGI1,SS1*,DIGI2,SS3-1

I was wrong in my first post, where I forgot that it overwrites
instead of "inserts" the ID digi....

Anyone surrounded by ID digis can check this?
GOing home now... Enjoy...
Bob


>>> Robert Bruninga 4/4/05 10:10:23 PM >>>
Another great New n-N Paradigm trick!!! (I hope)

Up till now, with SSn-N being supported in the UIFLOOD
parameter, so that we can move WIDEn-N support to 
UITRACE that is traaceable, we gave up traceability
on the SSn-N path.  So I recommended setting ID to ON
so that at least the path arrrives as DIGI2*,SS3-1 for
example where the LAST digi is identified.

But (drum roll please)....  if we use SSn-N with a leading
SS1-1,SSn-N we get the best of both worlds!

It will arrive like DIGI1,SS1*,DIGI2,SS3-1
Thus identifying the FIRST digi and the LAST digi
in the path as heard by this station!

And since the only time anyone really will be using
the SSn-N path is the guy that lives in the far corner
of a state and needs to use SS5-5 to hit the opposite
corner (without QRMING 150 digis in all directions)
then the path wont grow to huge proportions!

It always arrives as DIGI1,SS1*,DIGIn,SSn-N

Wow, what am I overlooking?
Is this beautiful or what?

de WB4APR, Bob


>>> Robert Bruninga 4/4/05 10:03:32 PM >>>
Wes,

Yes SSn-N will be untraceable.  
So I receommended ID ON, so that at least we
get to see the LAST hop.  But since we KNOW it is
untraceable, and is using UIFLOOD, then we KNOW
the digi on arrival of DIGI2,SS3-1 is the LAST digi.

Yes, we could encourage a path of SS1-1,SSn-N
and arrive as DIGI1,SS1*,DIGI2,SS3-1 which might
not be a bad idea EXCEPT that the Kenwood screwed
it all up and really bombs the network if NOID is selected.
So I thought setting ID ON wil get rid of that problem too.
Wow, I love this...!
POST TO SIG TO FOLLOW!

Bob


>>> Wes Johnston <wes at kd4rdb.com> 4/4/05 9:44:28 PM >>>
This is off sig...

Bob, if we use WIDE1-1,WIDE2-2 , and we're heard by a home relay, we
get
WIDE1-1*,WIDE2-2, and the first "real" digi that hears us gives us
DIGI1CALL*,WIDE2-1 .  We know the entry point into the network - well
we
know the entry point close enough.

On the other hand, if we use WIDE1-1,WIDE2-2, and we're heard by a
"real" digi, we get WIDE1-0*,WIDE2-2 .  Upon being heard by the next
digi, we'll get DIGI2CALL*,WIDE2-1 .  We now "think" the entry point
of
the packet was at the 2nd digi.....

So, perhaps we need to always include a UIDIGI trap call of WIDE1-1,
so
that if a digi hears a WIDE1-1, it repeats it under UIDIGI
call-substitution rules instead of UIFLOOD rules.

I know that WIDE is presently used by UITRACE, but that still leaves
UIFLOOD untraceable.  And we'll be using UIFLOOD for our SSn-n lans. 
I'm simply using WIDE here in the context of UIFLOOD because it's what
we're accustomed to dealing with. 

And the one element, universal path of WIDE2-2 is untraceable.... when
it's UIFLOOD.

This also has be wondering what happens when we have NOID set and
UIFLOOD sees a pre-depreciated WIDE2-1... it bet it won't do a
callsign
sub on the digi preceeding it.... I bet you a doughnut and cup of
coffee
that UIFLOOD NOID will only callsign sub when the two numbers in n-n
are
identical... as in WIDE2-2 or W3-3.

In order to make tracablity work, I am thinking we'll have to use
these
"pre-depreciated" path names to stop UIFLOOD NOID or ID from callsign
sub'bing on us..... and thereby making us loose the entry points....
SO.... W1-1,W2-1 is two hops.... W1-1,W3-2 is three hops.... W1-1,W4-3
is four hops

Food for thought.  Kept this off sig to avoid confusing the masses.
Wes