[aprssig] The final WIDE2-1,WIDE1-1 solution!

[AE5PL Lists]

Ok, if I understand correctly:

If everyone with KPC's are running 3+'s with 9.0, it is ok (although
Kantronics has made claims before which have proven to be false, so I
personally would feel better if some independent tests were done).
8.3 could have issues with any substitution-only paths because of no
dupe checking on UIDigi.
8.2 (I can demonstrate this and it has been discussed before here)
breaks with any substitution on a UIFlood path.  This is important
because KPC 3's can only be upgraded to 8.2.

These are only at issue because the entire n-N paradigm is being
constructed because of poor implementations in the Kantronics TNC's.  As
to some lid out there coming up with some bizarre paths, there are a lot
more out there than you might think ;-).

One final "issue" with the WIDE1-1,WIDE2-1 "solution" that came to me
this afternoon.  Hop counting on IGates could be impaired.  Even though
AE5PL-1,WIDE1,AE5PL-2,WIDE2* only went through 2 hops, it must be
assumed that it went through at least 3 hops.  Just one more thing to
think about.

73,

Pete Loveall AE5PL
mailto:pete at ae5pl.net 

> -----Original Message-----
> From: Wes Johnston
> Posted At: Saturday, April 02, 2005 12:32 PM
> Subject: Re: [aprssig] The final WIDE2-1,WIDE1-1 solution!
> 
> I verified this with Michael at kantronics.... kpc9.x UIDIGI 
> uses the same checksum method as UITRACE and UIFLOOD.
> 
> > I'm pretty sure that the dupe checking for UIFLOOD and 
> UITRACE are the 
> > same (compares checksum of source, destination and data 
> fields).  This 
> > applies to v 8.2 on the KPC 3 and v 8.3 of the KPC 3+.  The dupe 
> > checking for everything else (including UIDIGI) is simply callsign 
> > checking.
> >
> > It is rumored that v 9.0, which is now available for the KPC 3+, 
> > extends the checksum comparison to UIDIGI entries.  However