James Ewen
2009-08-16 18:19:56 UTC
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.
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
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 keepusers 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