InterNode Protocol support for Linux

Why bother?

• 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 program. 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.

Status

Todo

• Add negative preload.
• test, test, test, test it again....

Getting started

• 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!

INP specification

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 25 seconds.

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 large. 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 above. For the Linux implementation I use the same method.

L3RTT FRAME

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

7	7	1	4	1	n	1
AX.25 shifted	AX.25 shifted	0x02	0x00 0x00 0x00 0x00	0x05	TEXT	0x0d
Source node call	L3RTT-0	TTL	Dummy header	Frametype	ASCII	CR


TEXT field: (There is a space between each field)

6	10	10	10	10	6	11	n	n	n
L3RTT:	n	n	n	n	XXXXXX	LEVEL3_V2.1	LINUX001	$M60000	$N
Frame identifier	TX time (in 10ms)	Smoothed rtt	Last rtt	pointer to node	Mnemonic	version	software version	max time	inp3 identifier


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 capable). 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 broadcasts. 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).

Route Propagation

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 time. 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. For example: 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 propagated again. But when this continous over time the target time will become lower than the threshold and it eventually will get propagated.