[aprssig] More New N Paradigm Data needed.

[Robert Bruninga]

After receiving some reports of anomolous WIDEn-N
handling, I am starting to wonder if we fully understand
how even the existnig digipeaters work.  Those of
you who fully understand UIFLOOD and UITRACE
can simply look at existing packets and see if there
are any bugs in your local digis.

The question on the table is whether all digipeaters of
WIDEn-N properly set the has-been-digipeated bit 
after the packet decrements to 0.  This is easy to
observe:

A proper packet that has decremented to "0"
should always look like this:

...WIDE1*:data...
...WIDE2*:data...
...WIDE3*:data... etc...

If it arrives as ...WIDE2:data....
or  arrives  as ...DIGIx*,WIDE2:data...

then we have problems and have to figure
out which digis are doing this.  The problem is
that since UIFLOOD does not trace, it is sometimes
hard to know how you heard the packet.  So the
ideal testers are those of you who live in the 
boonies and can launch or observe packets and
know for sure what digi was the last one to handle
it.    So far, we have found that UIDIG-ROMS do 
not set the * bit when the decrement gets to 0.

Reports are that maybe KPC-3 V8.2 and 9.0 dont
do it either.  And then there is the concern as 
to what they do with UITRACE?  SO also look
for packets to end in:
...TRACE3*:data...
...TRACE2*:data...
...TRACE1*:data...

Those are all the expected result.

If we see things that end in 

...TRACE3:data...
...TRACE2:data...
...TRACE1:data...

Then we have problems...

Again, if you are 100% certain of your understanding
of UIFLOOD and UITRACE and think you see a problem,
then let us know.  But only after thoroughly proving
beyond the shadow of a doubt exactly what is going
on and exactly what hardware is causing it... and
getting repeating results...

There are a lot of ambiguities involved, and so it takes
work to nail these things down...

thanks
de Wb4APR, Bob