[aprssig] Packet routing, path specification.

Fri Jun 24 14:14:05 EDT 2005

>>> Wes Johnston <aprs at kd4rdb.com> 06/24/05 1:07 PM >>>
I differ with you.... simply adding WIDE1-1 to UIDIGI does _not_ fix the dupe problems.  

I send a packet WIDE1-1,WIDE2-2.

an 8.2 kpc digi (with UIDIGI WIDE1-1 set as you recommend) hears my packet.  It is digipeated like this:
DigiCall*,WIDE2-2.

The digipeat that just happened was under UIDIGI rules and did _not_ place a checksum in the UIFLOOD or UITRACE dupe checker buffer.

So now that packet hits the digi in the next town and comes out as 
DigiCall*,NextTownDigi*,WIDE2-1.

My local digi hears the output of NextTownDigi, sees that the WIDE2-1 is elligible to digipeat under UIFLOOD or UITRACE rules, and since there is NOT a copy of the checksum of this packet in the dupe checker buffer, my local digi will repeat the packet again...

DigiCall*,NextTownDigi*,DigiCall*,WIDE2-0.

This is the whole reson we moved away from RELAY in the first place.... to get away from digipeaters digi'ing packets differently under UIDIGI and UITRACE rules....  See http://www.ew.usna.edu/~bruninga/aprs/relaypaths.txt and substitute the word WIDE1-1 for every instance of RELAY and you have a much better explaination of what I'm trying to say here.... 8.2's UITRACE is broken, and the fix for _that_ is no better than the RELAY digipeats we were using 5 months ago.

I hate to have to get this muddled down in details, but I can see it's necessary.... either to prove I'm on track, or so someone can correct me if I have missed a detail in my understanding of the various versions of KPC3 firmware.

The problem is that when a kpc3 v8.2 or 8.3 TNC digipeats a packet using UIDIGI rules, it does a call substitution but does not make the checksum of the packet available to the UIFLOOD and UITRACE functions.  I like to think of this as the left hand (uidigi) doesn't know what the right hand (uitrace and uiflood) is/are doing.  So if the same packet comes down the pike in a few seconds again, UIFLOOD or UITRACE can and will still digipeat the packet again.  The UITRACE function does not mark the 'has been digi'ed' bit when the UITRACE n-n counter reaches 0.... this forces us to use UIDIGI to cover the W1-1 to W1-0 transition that we agreed to use inplace of RELAY.

kpc3+ v8.3 at least does UITRACE properly (the transition from 1-1 to 1-0*), so it is not necessary to include WIDE1-1 in the UIDIGI command.  Still, anything digipeated by the UIDIGI fuction is not passed on to the UITRACE or UIFLOOD functions, so the left hand still doesn't know what the right hand just did.  This is workable though, because it allows us to run WIDE1-1,WIDE2-2 paths without the dupes.

kpc3+ v9.x solves this all by making UIFLOOD and UITRACE aware of the checksum of any packet digipeated by the UIDIGI function.  Problem for most digi owners is that the solution here is to upgrade, and that costs $190.  I suspect that not too many digi owners will do this.

However, by using WIDE1-1 as the first hop instead of RELAY, we at least have a workable fix for the times I happen to be in range of a 8.3 or 9.0 KPC3+ digipeater.  But the majority of the digi's in SC are kpc v8.2.

So I stand by my assertion that kpc 8.2 firmware is broken.  Can we go back to bashing NSR now? lol.
Wes

Robert Bruninga wrote: That problem is solved by simply adding WIDE1-1 to the UIDIGI list.  So that is why it is not fair to say that 8.2 is broke.  It will work just fine with that simple change.    Bob  aprs at kd4rdb.com 06/24/05 11:59 AM >>>        I'm talking about kpc8.2 firmware taking a WIDE1-1 packet and insertingthe call of the digi before teh W1-1, then marking down the W1-1 toW1-0, but not setting teh has been digi'ed flag....kd4rdb-14>W1-1,W2-1:mydata here...kd4rdb-14>DigiCall*,W1-0,W2-1:mydata here...when it should have been digi'ed askd4rdb-14>DigiCall,W1-0*,W2-1:mydata here...I guess it is UITRACE.... but never the less it's broken in v8.2...which is what most of the digi's are...I've seen UITRACE broken on air at a digi in Charleston SC when Ivisited there two weeks ago, and you acknowlege the bug inhttp://www.ew.usna.edu/~bruninga/aprs/kpc3+82WIDEn.txt .  It's reallynot just "one report that has never been reproduced"... it's real andthe uncovering of this bug undermines the work we all put into gettingrid of RELAY.  Putting WIDE1-1 in the UIDIGI is no different that usingthe word RELAY in this context.... it still does not stop the dupes fromhappening when a digi hears a packet first with RELAY/WIDE1-1, thenhears it again as some other derivation of WIDE2-x or WIDE4-x.  This iswhat frustrates me.... and it _cannot_ be fixed in the v8.2 digi'sbecause Kantronics will not support the firmware anymore - even forhire.  As I said earlier, I don't hold it against them... I understandand accept their reasoning.Pete also makes a good point today publicly which I was avoidingmentioning publicly... there are people who will thwart the traps byrunning WIDE2-6.  If we had hop counters (or at least more intelligentUITRACE and UIFLOOD), those packets would be dropped.We are at a point where we have a mismatched, convoluted network... andit's easily abused..... if APRS continues to grow (and i have no reasonto think it won't), the network will become busier and will reachsaturation where I can't reliably track my neighbor around town.  Iguess when that happens, a certain number of people will grow tired ofit and peter out.  Then we'll reach a state of equilibruim, right?Things have improved greatly... and they can get even better.  Even withthe fixes in the new system in place, I still see WIDE3-3 packets fromvirginia down here in SC, though....WesRobert Bruninga wrote:  but the New-N is an incomplete fix... the kpc3 8.2's don't work correctly.  I was all wound up (in a good way) about the progress we made with the WIDE1-1,WIDE2-1 stuff.... until I found out that the KPC3 has the additional UIFLOOD bug.           ?   I think you are referring to the "reported" 8.2 UITRACE dupe bug, not UIFLOOD.    And please note, it was one report.  To date, no one has confirmed the bug nor reported on being able to reproduce that one report.So I am still very leary that the "reported" dupe problemin the 8.2 use of UITRACE  really exists.  In this transition period between supporiting WIDEn-N in UIFLOOD (old digis which give no indication of which digi did what) and in UITRACE (new-N digis which does trace WIDEn-N)it takes very careful inspection to actually be able to correctly interpret what one sees.  And sometimes itis just impossible to tell because of he lack of a trace fromthe old digis.     So, it appears we can't fix things the way they outta be with the TNCs we have now...           I dont think that is a true statement.  With great input    >from a lot of folks, I think we have solutions for all  all reported anomolies in all ROMS and firmwaresand UIDIGI Roms except for the one single report above, which no one has been able to reproduce nor confirm.So I would not rush to judgment.  Things  have really improved around here and we are still less thanhalf digis converted.Bob_______________________________________________aprssig mailing listaprssig at lists.tapr.org https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig      _______________________________________________aprssig mailing listaprssig at lists.tapr.org https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig  