[aprssig] UIDIGI and the New Paradigm - WARNING - LONG!

Thu Apr 7 09:07:48 EDT 2005

Awesome report, thank you. This is the type of information I was looking
for. I would suspect the shortcomings you found would not be an issue if the
UI-digi was not trying to function as the major trap for an area. If other
digi's were effective traps then the wide7-6 paths would not be getting to
the digi in the first place. I suspect that even if you get someone to set
their path like that it would be very few users. That would mean they had to
really research the new concept to figure a way around it. If they did that
much looking they might then figure out that what they are doing is
overloading the network. Given these shortcomings I think it is still
worthwhile compared to the current state of the networks to implement this.
I now feel confident that I can change the PROM on our dumb X1J digi. If you
would be so kind as to post a sample of your config file that would be
great.

Brian, N2KGC

-----Original Message-----
From: Ron Stordahl [mailto:ron.stordahl at digikey.com]
Sent: Thursday, April 07, 2005 12:06 AM
To: TAPR APRS Mailing List
Subject: [aprssig] UIDIGI and the New Paradigm - WARNING - LONG!

Testing this evening produced some unexpected results and the conclusion
that the New Paradigm cannot be fully implemented in UIDIGI as it
currently exists.  Skip to the end for a summary.

Wishing to allow only these paths to be fully functional:

WIDE1-1 (for 1 hop)
WIDE2-1 (for 1 hop) - but it's really 2 hops.
WIDE2-2 (for 2 hops)
WIDE1-1,WIDE2-1 (for 2 hops)
WIDE1-1,WIDE2-2 (for 3 hops)

I set the relevant parms thus on the nearby UIDIGI and surrounding
UIDIGI's that can hear the nearby UIDIGI:

UIDigi WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7,MN
UIDCsb 1 (enable callsign substitution for UIDigi calls)
UIFlood MN (call to be used in the flood algorithm)
UIFLDfl 0 (make call substitution after last 'floodcall' digi'd)
UITrace WIDE (call to be used in the trace algorithm)
UITRFl 0 (make call substitution after last 'tracecall' digi'd)

Then I generated from a TinyTrak3 packets with these paths:

WIDE1-1  (it was digi'd once as expected) - shown in the dig'd packet as
N5IN-2*,WIDE1 and not digi'd further.  I can hear 1 level out and did
not hear another digi repeat the packet.

WIDE2-1 First as N5IN-2*,WIDE2, and a second time as N5IN-2,WIDE2*  I
had expected it to act just as WIDE1-1, but in fact it acts as WIDE2-2
(in regards to the number of hops allowed).

WIDE2-2 - Shown in the first digi'd packet as N5IN-2*,WIDE2-1 and in the
second as N5IN-2,WB0WTI-11*,WIDE2. If it was digi'd further I have no
way to tell as I can't hear further out.  However I would be willing to
bet that it is in fact limited to 2 hops as it should be.

WIDE3-3 (it was digi'd once only as expected) - shown in the first
digi'd packet as N5IN-2* with nothing following.  There were no
additional hops, and I could hear them if they existed.

WIDE3-2 Shown in the first digi'd packet as N5IN-2*,WIDE3-1, in the
second as N5IN-2,WB0WTI-11*,WIDE3 and I suspect there is a 3rd hop as
N5IN-2,WB0WTI-11*,WIDE3*, although it would be too far out for me to
hear. I draw that conclusion based upon what I could here in the case of
WIDE2-1, where there were 2 hops.  And if this is so I suspect that
WIDE3-1 will also produce 3 hops.

Now for combined paths:

WIDE1-1,WIDE1-1.  The first digi'd packet contains N5IN-2*,WIDE1,WIDE1-1
and is not repeated by any of the surrounding digi's.  I had expected a
second hop, but it did not occur.

WIDE1-1,WIDE2-1.  The first digi'd packet contains N5IN-2*,WIDE1,WIDE2-1
and is not repeated by any of the surrounding digi's.  I had expected a
second hop (and maybe a 3rd) but it did not occur.

WIDE1-1,WIDE2-2.  The first digi's packet contains N5IN-2*,WIDE1,WIDE2-2
and is not repeated by any of the surrounding digi's.  I had expected a
total of 3 hops, but only one occurred.

Apparently the WIDE1 is the end of the line, perhaps I should have
expected that.  In order to permit these to work I had to add WIDE1-1
into the UIDIGI list thus:

UIDigi WIDE1-1,WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7,MN  and I also
made this change in the surrounding UIDIGI's..

Now combined paths again with this new setting:

WIDE1-1,WIDE1-1 The first digi'd packet contains N5IN-2*,WIDE1-1 while
the second and final digi'd packet contains N5IN-2,WB0WTI-10*

WIDE1-1,WIDE2-1 The first digi'd packet contains N5IN-2*,WIDE2-1, the
second N5IN-2,WB0WTI-10*, and I suspect a third N5IN-2,WB0WTI-10,WIDE2*

WIDE1-1,WIDE2-2 The first digi'd packet contains N5IN-2*,WIDE2-2, the
second N5IN-2,WB0WTI-10*,WIDE2-1 and I suspect a third
N5IN-2,WB0WTI-10,WIDE2*

Finally approaching some conclusions:

You can't shoehorn the New Paradigm into the UIDIGI, but you can get
part way there.  a UID of
WIDE1-1,WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 works thus:

WIDE1-1,WIDE1-1 (works as expected producing 2 hops)
WIDE1-1,WIDE2-1 (produces 3 hops and not 2 as hoped)
WIDE1-1,WIDE2-2 (works as expected producing 3 hops)

With RELAY added to UID (now both RELAY and WIDE1-1 are in UID)

RELAY,WIDE1-1 works as WIDE1-1,WIDE1-1 (2 hops)
RELAY,WIDE2-1 works as WIDE1-1,WIDE2-1 (3 hops not 2 as hoped)
RELAY,WIDE2-2 works as WIDE1-1,WIDE2-2 (3 hops)

WIDEn-N for n=N and n>2 but < 8 all terminate with a single hop, thus:
WIDE1-1,WIDE4-4 allows just 2 hops.

Unfortunately WIDE5-4 produces 5 hops (it is not trapped).

For WideN-M where M<N the trapping fails.

You will also note that in order to substitute WIDE1-1 for RELAY it is
necessary to place WIDE1-1 in the UID list (otherwise serious problems
result which are detailed above).  By doing so I believe RELAY and
WIDE1-1 act identically, the latter not producing any less QRM.

=============================================================

1) If you wish to support both RELAY and WIDE1-1 (in the UID list, and
thus treated differently than WideN-n in that it is no longer a UIFlood
or UITrace token) then both of these must be placed in the UID list.  By
doing so you will have space remaining for just additional 6 tokens.  If
you are in a 3 hop area then the UID list would have to contain:

RELAY,WIDE1-1,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 plus 2 more tokens.  To
fully implement restrictions against excessive paths you would need to
add WIDE4-3,WIDE4-2,WIDE4-1,WIDE5-4, etc which totals 18 tokens.  There
is no room to do this.  And the result is inconsistent as while it
allows a path of WIDE3-3, it also allows a path of RELAY,WIDE3-3 or
WIDE1-1,WIDE3-3 which is 4 hops.  Someone who wishes to break the rules
can use a path of WIDE7-6 and get 7 hops.  Also paths such as
RELAY,RELAY,RELAY,RELAY,RELAY will be supported.

2)  If you wish to abandon RELAY and WIDE1-1 in its special application
as a twin to RELAY, then the UID list for a 3 hop area will contain just
WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 giving you space for 4 additional tokens
out of the 18 additional spaces you would need to fully implement.  In
this implementation the following paths will be permitted:

WIDE1-1 (1 hop)
WIDE2-2 (2 hops)
WIDE3-3 (3 hops)

but you will be able to block just 4 our of the remaining 18 paths such
as WIDE7-6 which will produce 7 hops.

3)  If you wish to retain RELAY, but not include the special application
of WIDE1-1, you gain one additional slot in the UID list.

Conclusion:  The New Paradigm can only be poorly supported by UIDIGI at
present.  Abandoning RELAY (and/or the special use of WIDE1-1 as an
equivalence for RELAY) simplifies things only slightly.  While I have no
means to test the KPC3+, I suspect it may the same shortcomings as UIDIGI.

Assuming users are well behaved it may be worthwhile to implement, but
if users were well behaved we wouldn't need to place limits upon them as
intended by the New Paradigm in the first place.

I had hoped for better.

Only Marco Savegnago IW3FQG, the author of UIDGI, is in a position to
fully solve this problem by allowing a simple hop limit to be enforced
in the code irrespective of what paths a user tries.

Ron, N5IN

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