[aprssig] Packet routing, path specification.

[Robert Bruninga]

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 inserting
the call of the digi before teh W1-1, then marking down the W1-1 to
W1-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 as
kd4rdb-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 I
visited there two weeks ago, and you acknowlege the bug in
http://www.ew.usna.edu/~bruninga/aprs/kpc3+82WIDEn.txt .  It's really
not just "one report that has never been reproduced"... it's real and
the uncovering of this bug undermines the work we all put into getting
rid of RELAY.  Putting WIDE1-1 in the UIDIGI is no different that using
the word RELAY in this context.... it still does not stop the dupes from
happening when a digi hears a packet first with RELAY/WIDE1-1, then
hears it again as some other derivation of WIDE2-x or WIDE4-x.  This is
what frustrates me.... and it _cannot_ be fixed in the v8.2 digi's
because Kantronics will not support the firmware anymore - even for
hire.  As I said earlier, I don't hold it against them... I understand
and accept their reasoning.

Pete also makes a good point today publicly which I was avoiding
mentioning publicly... there are people who will thwart the traps by
running WIDE2-6.  If we had hop counters (or at least more intelligent
UITRACE and UIFLOOD), those packets would be dropped.

We are at a point where we have a mismatched, convoluted network... and
it's easily abused..... if APRS continues to grow (and i have no reason
to think it won't), the network will become busier and will reach
saturation where I can't reliably track my neighbor around town.  I
guess when that happens, a certain number of people will grow tired of
it and peter out.  Then we'll reach a state of equilibruim, right?

Things have improved greatly... and they can get even better.  Even with
the fixes in the new system in place, I still see WIDE3-3 packets from
virginia down here in SC, though....

Wes







Robert 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 problem
>in 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 it
>is just impossible to tell because of he lack of a trace from
>the 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 firmwares
>and 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 than
>half digis converted.
>
>Bob
>
>
>_______________________________________________
>aprssig mailing list
>aprssig at lists.tapr.org 
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig 
>  
>


_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org 
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig