<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I differ with you.... simply adding WIDE1-1 to UIDIGI does _not_ fix
the dupe problems. <br>
<br>
I send a packet WIDE1-1,WIDE2-2.<br>
<br>
an 8.2 kpc digi (with UIDIGI WIDE1-1 set as you recommend) hears my
packet. It is digipeated like this:<br>
DigiCall*,WIDE2-2.<br>
<br>
The digipeat that just happened was under UIDIGI rules and did _not_
place a checksum in the UIFLOOD or UITRACE dupe checker buffer.<br>
<br>
So now that packet hits the digi in the next town and comes out as <br>
DigiCall*,NextTownDigi*,WIDE2-1.<br>
<br>
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...<br>
<br>
DigiCall*,NextTownDigi*,DigiCall*,WIDE2-0.<br>
<br>
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
<a class="moz-txt-link-freetext" href="http://www.ew.usna.edu/~bruninga/aprs/relaypaths.txt">http://www.ew.usna.edu/~bruninga/aprs/relaypaths.txt</a> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
So I stand by my assertion that kpc 8.2 firmware is broken. Can we go
back to bashing NSR now? lol.<br>
Wes<br>
<br>
Robert Bruninga wrote:
<blockquote cite="mids2bbfd5c.087@FSGWHUB.usna.edu" type="cite">
<pre wrap="">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
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:aprs@kd4rdb.com">aprs@kd4rdb.com</a> 06/24/05 11:59 AM >>>
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->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
<a class="moz-txt-link-freetext" href="http://www.ew.usna.edu/~bruninga/aprs/kpc3+82WIDEn.txt">http://www.ew.usna.edu/~bruninga/aprs/kpc3+82WIDEn.txt</a> . 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:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">? 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.
</pre>
<blockquote type="cite">
<pre wrap="">So, it appears we can't fix things the way they outta
be with the TNCs we have now...
</pre>
</blockquote>
<pre wrap="">I dont think that is a true statement. With great input
</pre>
</blockquote>
<pre wrap=""><!---->>from a lot of folks, I think we have solutions for all
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-freetext" href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-freetext" href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<br>
</body>
</html>