You're right, it shouldn't be a big code change. I've been holding off on it because there seems to be some disagreement on how hop limiting in particular should work - dropping excessive paths completely, counting already-used hops against the limit, or (like it does now) just capping the remaining hops. And then there's the exception of the WIDE1-1 behavior.
What I'd really like to see is a flowchart, or maybe even just a matrix, showing what the behavior should be. Something that everyone can look at and see what the implications are for each case, and that can serve as an implementation guide when everyone's had a chance to look at it. Scott James Ewen wrote: > > > Scott, > > Here's a little something that I've been meaning to discuss for a few > years now... (yeah, I'm a procrastinator). > > First thing, we need to discuss how a UIFLOOD or UITRACE algorithm is > supposed to work, ignoring the callsign insertion portion for the > moment. > > Let's just use the usual base alias of WIDE, where the path used by > the user would be in the form of WIDEn-N. > > The general concept was for people to set both "n" and "N" to the same > value, where "n" would indicate the number of hops desired when > initiated, and "N" would keep track of the number of hops to go. > > AX.25 packet rules limit the value of "N" to a maximum of 7. > > So, one would be able to use an outgoing path of anything between > WIDE1-1 and WIDE7-7, and expect it to be acted upon by a digipeater > that supports UIFLOOD or UITRACE. > > >From there, it was decided by consensus that it would be good to be > able to limit the number of hops supported by a digipeater to keep > users from abusing the network by using excessive "N" hop values. With > a majority of digipeater running on the Kantronics hardware, a > pseudo-trap concept was designed and implemented. Setting UIDIGI > WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 in the KPC-3 and KPC-3+ > hardware captures any of those paths, and does a simple callsign > substitution digipeat. This has the effect of giving a single hop, > overwriting WIDEn-N aliase with the callsign of the digipeater. > > The flaw in this design is that Kantronics will digipeat any other > combinations of n-N that do not match exactly with the UIDIGI > settings. If a user sends a packet with an outgoing path of WIDE7-7, > and a single digipeater acts upon the packet, that packet will bypass > the traps, since the packet would be WIDE7-6 or less. Using non > standard n-N values also bypass the traps. Using a path such as > WIDE1-7 will be acted upon by Kantronics TNCs with traps enabled. > > The OT2 digipeater rules allow us to setup WIDEn-N digipeating rules, > with hop limits. Setting a hop limit of 3 restricts the action of the > digipeater to packets that have an "N" value of 3 or less. However, > there is no check done on the"n" value, which means that packets with > a higher or lower "n" value will get acted upon. This can cause some > undesirable digipeater action such as when a digipeater is set up to > act as a fill-in digipeater. > > Setting ALIAS to WIDE, and HOPLIMIT to 1 should only act upon a packet > with a path of WIDE1-1, however, because the "n" value is not checked, > any packet with an "N" value of 1 is acted upon. This is undesirable > since all packets travelling through the APRS-RF network will end up > with an "N" value of 1 on their last hop. A workaround of setting the > ALIAS of WIDE1 and HOPLIMIT of 1 works to create a digipeater that > only acts upon WIDE1-1, and no other values of "n" when "N" equals 1. > > To further expand upon this, one would need to set an ALIAS of WIDE2 > and HOPLIMIT of 2 to act upon only WIDE2-2 and WIDE2-1 packet paths. > Setting another ALIAS of WIDE3 and HOPLIMIT of 3 would act upon only > WIDE3-3, WIDE3-2, and WIDE3-1 packet paths. > > If however a line of code was added to the firmware that checked to > make sure that the value of "n" was less than or equal to the hop > limit for that alias, we would ensure that the users only used proper > outgoing paths. One would not be able to use a malformed path such as > WIDE1-7, but a path such as WIDE2-1 would still be viable. This would > require that "N" would always have to be less than "n", and that "n" > was less than HOPLIMIT. > > Here's a small portion of the code. > > // Get value of N in alias > n = packet_data[a-6+c] >> 1; > // Must be a number > if (!isdigit(n)) continue; > > You check the"n" character to ensure that it is a number. > > // Get SSID, skip if it's already 0 (so why isn't H set?) > c = (packet_data[a] & 0x1e) >> 1; > > // Check against max N limit and cap it > if (c > globalcfg.digi[d].n) c = globalcfg.digi[d].n; > > Then you check to ensure that "N" is less than the hop limit. > > What needs to be done, is to not only ensure that "n" is less than or > equal to the hoplimit, and that "N" is less than "n". > > //Check to ensure that "n" is greater than "N" > if (n > c c = n) continue; > > I'm no C coder, but if you understand the concept, it should only be > one more line of code to ensure that the OT2 implements proper hop > limiting. > > James > VE6SRV > >
