InterNode Protocol support for Linux
There are several reasons why I wrote this and why you should consider using it:
- Avoid multiple AX.25 stacks
When using XNET or TheNetNode ontop of linux you basicly have
two AX.25 stacks, although you need only one.
- Modular approach
Most node programs try to be a solution to all problems,
offering a dozen different services in one monolithic
With the Linux kernel stack you will have the option to run
each server (node, bbs, convers) seperatly.
This gives you more options and more reliability since one
service may be brought down without harming the others.
- Better route propagation
This implementation tries to prevent huge amounts of data being
propagated. (This is explained later)
- Its Free Software
This is most obvious when compared with XNET in which case you
have to rely completly on a single source for bugfixes or
changes. When using Free Software you atleast have the option
of doing it yourself.
Although TheNetNode comes with source it still has a very
restrictive license that is absolutly NOT compatible with
the definitions of an Open Source license.
The patch is currently succesfully used on several systems.
Keep in mind however that this is a work in progress.
Versions 001 and 002 had some problems with propagating negative
routes, this should be fixed in version 003.
Since version 003 multiple local interfaces are supported and it
is possible to set their mnemonics right.
Version 004 has a fix for a rtt/rif race and can send out multiple
negative routes in one RIF.
- Add negative preload.
- test, test, test, test it again....
- Download the patch: 2.6.4-inp.diff
- Patch your kernel
- Compile and install the netrom module
- Load the ax25 and netrom modules as you normally would
- Attach the netrom interface (If you use the patched version of
nrattach, found here multiple interfaces
are supported and their mnemonic is automaticly set)
- Start netromd or add your neighbours manually
- Watch your Linux machine talk to its INP3 neighbours and have a party!
The following sections will go into the specification of the protocol
which unfortunatly isn't as clear as it should be.
It can be found at:
Integration with the existing NET/ROM stack
Translating time to quality
In order to make routing decisions that make sense a node needs to
know how to to translate a time measurment to a quality.
If this is not done there is no way to compare a route via an INP
neighbour to a route via a normal NET/ROM node.
In the specification this is not addressed.
This will inevitably leed to different algorithms being implemented
which might lead to network unreliability.
TheNetNode uses the folowing algorithm
qual = 255 - ( rtt / 10 )
Where qual is limited between 3 and 254 and rtt is in 10ms
In this case the maximum time for a node before it dissapears is about
The algorithm used by XNET is not known (closed source remember...)
but judging by the qualities displayed it is close to the following:
qual = 255 - ( rtt / 30 )
Although the quality used in the netrom broadcasts differs from this...
This leads to a maximum time of about 75 seconds which seems to be
For the Linux implementation I have choosen to use a division factor of 20.
This leads to a horizon at about 50 seconds.
Propagation of non INP capable nodes
In the specification there is no mention about the propagation of
non-INP nodes accross the network.
However watching the current implementations it seems that existing
nodes have their quality translated to a target time and propagated
as regular INP nodes from the first INP capable node on.
For this to be possible there needs to be some magic to translate the
node's quality into a target time and a hop count.
TheNetNode seems to be simply using the reverse of the method described
For the Linux implementation I use the same method.
In the 'official' INP3 specification there are a few things missing in
the L3RTT frame format, the frametype (INFOFRAME) and for the last
few decades a Carriage Return has always been 0x0d and not 0x10.
L3RTT frame format
||0x00 0x00 0x00 0x00
|Source node call
TEXT field: (There is a space between each field)
||TX time (in 10ms)
||pointer to node
According to the spec the text field should contain
'implementation specific information' and it should be scanned
for flags only (such as the $N flag for marking a node inp
However XNET does not seem to accept a neighbour that is not
transmitting the rtt and smoothed rtt fields in this fasion.
Also it will always take the netrom mnemonic specified in this
field no matter how often you tell it otherwise using normal
In order to be compatible the Linux implementation will follow
this format with some changes (the time and pointer field are
used to store the two fields of a struct timeval).
In the specification there is a discinction between positive
and negative information.
Positive information should only be transmitted if there is a
minimum percentual and a minimum absolute decrease of the target
For linux these are 25% and 100ms respectivly.
To prevent Broadcast storms all positive propagation is delayed
and done only once every five minutes.
However for negative information there is only one rule defined:
Propagate it immediatly. With the addition that there may be an
extra negative preload added.
At the moment all negative data is propagated without any preload.
Adaptive preload calculation is planned for later, at the moment
I am focussing on getting the implementation to work properly.
Additions to the specification:
According to the specification routes are only transmitted on link
connect or on change. However if a node for some reason drops a route,
this might be due to a bug, it will get lost forever.
As another example, it is possible in Linux to remove the netrom module
while the ax25 module will keep the interlink intact....
To prevent this every few hours all routes are resend to the neighbours.
Since the state we try to prevent is (hopefully) rare there is no need
to do this often.
Furthermore provisions have been taken to ensure that also
cummulative changes are propagated.
If a route is propagated with a target time of 1000ms and
each time a rtt frame is measured it decreases with 10ms.
On themself these decreases do not justify the route to be
But when this continous over time the target time will
become lower than the threshold and it eventually will get
Copyright (c) 2001 by Jeroen Vreeken (firstname.lastname@example.org)