[aprssig] The final WIDE2-1,WIDE1-1 solution!
HamLists at ametx.com
Sat Apr 2 15:55:00 CST 2005
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
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
More information about the aprssig