One of the things that appears to have puzzled Node ops for decades is understanding of NetRom Qualities. A PDF from NEDA(1) drafted in 1994 shows NetRom calculations based off of years of bench testing various settings for diode matrix based TheNet and X1J-4 nodes. While we’ve migrated off Diode Matrix configurations in favor of PC controlled ones we need to make adjustments due to the pounded/hidden backbone link nodes that aren’t in use via axip/axudp linkage.
First lets understand that in the NEDA found quality table anything over a quality of 203 for neighbor links is a statement that the linked node resides physically on your lan. As found by NEDA 228 is a good link for lan based nodes as it will propagate quality to the next hop as 203.
Here BAUNOD links to RSBYPI and it’s link quality is set to 203:
RSBYPI:N1URO-2} Connected to BAUNOD:ZL2BAU-3
r
BAUNOD:ZL2BAU-3} Routes:
Link Intface Callsign Qual Nodes Lock QSO
—- ——- ——— —- —– —- —
> ax0 N1URO-2 203 50 1
BBSURO is a neighbor node to RSBYPI 2 hops away thus it should appear with a derated quality of 181 on BAUNOD:
n bbsuro
BAUNOD:ZL2BAU-3} Routes to: BBSURO:N1URO-4
Which Qual Obs Intface Neighbour
—– —- — ——- ———
> 181 6 ax0 N1URO-2
162 6 ax0 SV1CMG-4
Now let’s visit a node 3 hops away which should appear with a quality of
161:
n mfnos
BAUNOD:ZL2BAU-3} Routes to: MFNOS:N1URO-14
Which Qual Obs Intface Neighbour
—– —- — ——- ———
> 198 6 ax0 SP2L-14
193 6 ax0 SV1CMG-4
161 6 ax0 N1URO-2
Yes it is there but as a tertiary route! This is how and why netrom brakes. It’s not the protocol, it’s the sysops. 198 and 193 are a higher quality and suggests something very wrong. It should appear with a
quality of 181 via SP2L-14 however even if that were true it’d be a secondary path which is false in nature. Let’s look at the other two
paths…
First:
MFNOS:N1URO-14 usa 250 6/B 5 0 0 0 %
2LJNOS:SP2L-14 Area: n1uro
While neighbors, link quality of 250 suggests Poland is handing out N1 calls now since the claim is MFNOS physically is on a lan in Poland. The quality shown at BAUNOD should be shown at 181 since it’s 2 hops via SP2L, and SP2L should show 203. The fact that it’s the primary path is correct being 2 hops vs 3 but it’s quality is being falsely raised due to the link quality of 250 used by SP2L. Think about it this way, if the true host is sending OBS (nodes) broadcasts at a quality of 203, how could it logically be possible to be a higher quality elsewhere?
Let’s look at the secondary route:
r
LAMURO:SV1CMG-4} Routes:
Link Intface Callsign Qual Nodes Lock QSO
—- ——- ——— —- —– —- —
> axudp GB7COW-5 255 168 0
jnos SV1CMG-6 255 781 0
> axip ZL2BAU-3 255 83 1
> radio1 SV1HCC-14 255 154 1
> bpq SV1CMG-7 255 500 0
axudp NA7KR-5 255 3 0
> xnet SV1CMG-3 255 162 0
axip SV1UY-12 255 6 0
> axip OK2PEN-5 255 3 0
axip SV1DZI-11 255 62 0
> tnos SV1CMG-14 255 187 0
> axudp PI1LAP-5 255 34 0
> fbb SV1CMG-3 10 0 0
This I don’t at all understand. It appears Greece now is handing out calls from all over the globe since quality is 255! So now the question is, how does a node (MFNOS) which doesn’t link to LAMURO show a priority path to BAUNOD via LAMURO? This is known as hijacking routes. If SP2L was configured for 203, ZL2BAU would then receive MFNOS at a quality LOWER than the 193 received by SV1CMG-4 -= WHICH DOESN’T HAVE A LINK TO MFNOS!!=- so hopefully now you can see how NetRom paths get hijacked.
Since axip/axudp links don’t use backbone/#alias nodes for internlinking, they’re direct, we then adjust our minqual to reflect such so that we avoid:
– hijacking paths
– spew nodes that are not connectable due to excessive hops
To accomplish this via vanilla NetRom (NOT INP3 / Xnet) the following has been tested to be quite valid for nrbroadcast:
min_obs: 4
def_qual: 203
worst_qual 128
verbose 1
If you have a neighbor with X-net based links then set your verbose on all your interfaces to 0 and worst_qual to 202, or if you have a neighbor on the same link interface running link qualities NOT equal to the same mathematical calculations set your verbose to 0 AND raise your worst_qual to 202 to reject falsely raised qualities from infesting your nodes tables.
*Keep in mind this as well; a user on HF (aka: 300 baud) is most likely going to time out off of your node if you have more than a screen worth of CONNECTABLE nodes… and having a nodes table of truly connectable nodes will bring credibility to your system and those end users you may get to visit will appreciate the integrity of your network.
I’ve had some netrom based queries lately so I hope this answers questions others have had. When the protocol is treated properly by sysops it’s not a bad dynamic routing protocol but when the humans abuse it… then it becomes troublesome.
(1) http://n1uro.ampr.org/neda/neda_annual_v005_1994.pdf
Brian n1uro
