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

[Wes Johnston]

Bob, I don't think a packet that starts as SS1-1,SS2-2 will end up as 
DIGI1,SS1-0*,DIGI2,SS2-0*..... because the kpc3 digi code doesn't INSERT 
a digi when it does a call sub... it OVERWRITES the preceeding digi... I 
think that's how it works.

Wes

Robert Bruninga wrote:

>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
>  
>