Grant: Fixing the Linux kernel AX.25
Date: December 2021
Amount: €179,690
Changes to the Linux kernel over the years have improved and modernized the kernel, but have also made existing AX.25 implementations incompatible and turned preexisting issues into bugs. This can make systems unpredictable or even unusable. Linux kernel development is complex, requiring deep specialized knowledge, and bugs are hard to trace. This may be one of the reasons, why the Linux kernel AX.25 stack is currently in such a bad state.
This ARDC grant funds will allow the Deutscher Amateur Radio Club to hire software developers who can create a stable Linux AX.25 implementation and prevent Linux distributions from dropping pre-compiled AX.25 support. The fixed and functional Kernel-AX.25 stack will improve global amateur radio infrastructure. Professional kernel development can bring Linux AX.25 back to life.
Learn more at https://www.linux-ax25.org/wiki/Main_Page.
Setting NetRom Parameters
I was looking at the old NEDA (NorthEast Digital Association) newsletters from twenty years ago (1999) and want to show you some pertinent NetRom parameters that might help with the bloated (some up to 800) nodes lists that we see from time to time. These started as X1J parameters, but you might find them useful to give you an idea how to tweak your BPQ, Xrouter, *NOS, Flex, etc systems. Each program might use a different naming convention, but reading the details of your documentation will align to NEDA labels. As always, adjustments can be made for a non-standard configurations like full duplex data repeaters, etc. Feel free to discuss the technical points here, but gear the explanation for the newer sysops. The parameters are broken down differently by the type of connection you have with another station (mostly RF-based). Adaption to an AXIP link via wired internet should follow the Dedicated Point-to-Point Link (DPPL).
USER PORT (typical 2 meter port):
No node table is broadcast to keep the channel clear. Do this by setting Initial (Default) Obsolescence at 5 and the Minimum Obsolescence to 6. Since the default is lower than the cutoff, it will never broadcast.
DPPL (only two backbone users on a dedicated frequency) [or AXIP]:
Your partner station should be a locked route with quality of 203.
Accept incoming nodes from your partner with minimum quality of 63.
Initial (Default) Obsolescence at Minimum Obsolescence to 3
Nodes Broadcast Interval 900 seconds (15 minutes)
The obsolescence count will start at 5 and decrement by 1 every 15 minute cycle and stop when it hits 3 if there is no refresh from your partner station. This keeps things clean and updated within 30 minutes.
Multiway Backbone with 3 Partners (typically 220 Mhz regional channel):
Your partner station should be a locked route with quality of 203.
Accept incoming nodes from your partner with minimum quality of 63.
Initial (Default) Obsolescence at 5
Minimum Obsolescence to 2
Nodes Broadcast Interval 900 seconds (15 minutes)
The obsolescence count will start at 5 and decrement by 1 every 15 minute cycle and stop when it hits 2 if there is no refresh from your partner station. This keeps things clean and updated within 45 minutes. This allows for occasional transmitter collisions between partners.
NOTE: current practice is to set minimum quality values at 150 or 180 is only to mitigate the effect of mislabeled nodes qualities broadcast to partner systems that get propagated. There are several systems that make all of the nodes in their table higher than they should be. When the network is cleaned out and realigned, then the minimum quality can be adjusted downward.
How are node qualities adjusted when the nodes table is passed around the network from partner to partner?
*** ONLY WHAT IS ON YOUR PHYSICAL BOX OR WIRED LAN SHOULD BE HIGHER THAN 203 ***
Initial partner default quality is 203 (out of 256) or 203/256
First hop between AXIP partners is 203/256 * 203/256 or 161/256
Second hop between AXIP partners is 161/256 * 203/256 or 128/256
Third hop between AXIP partners is 128/256 * 203/256 or 101/256
Fourth hop between AXIP partners is 101/256 * 203/256 or 80/256
Fifth hop between AXIP partners is 80/256 * 203/256 or 63/256
Let's look at how various stations relate to each other on the NetRom nodes list. First, each station sets their partners at a default value of 203 if on AXIP or DPPL. This is only the value between the two stations talking to each other. Here are some of my forwarding partners and some of their other partners.
Second, let's look at how those next-line stations actually calculate to my station. If my partner is 203/256 (or about 80% reliability) and so is their partner, then the second-level station is not going to be 80% reliability to me. BBGATE:AA6HF-4 is 80% to me on a direct connection, but has to be less when going through LAXNET:N6ROE-3.
By doing the calculation of each level's reliability of 203/256 against the next level,
we get 203/256 x 203/256 (same as 0.79296875 x 0.79296875) or 161/256 (0.628799438476).
If we extend this exercise by multiplying against the next level of 203/256 we get:
Going down level by level we get values of 128 (X), 101 (Y), 80 (Z), etc.
By setting MIN QUALITY you can cut off how many levels (hops) you want to see.
MIN QUAL 161 lets me see all stations closer to me above the level that X is on.
MIN QUAL 128 allows me to see down to the level of X.
MIN QUAL 101 allows me to see down to the level of Y.
MIN QUAL 80 allows me to see down to the level of Z.
@Bug Bash / Thanks to Dave who has fixed the bug (also working on Xfbb) Thanks to Theo how has found the Bug.
There is an (apparently) very old bug in netromd of the linuxax25 tools. This bug ensures that nodes broadcasts on an AX.25 port with paclen <256 do not go out or are incomplete. This is the case in both the original and VE7FET versions.
Syslog get spammend with this kind of messages
Feb 6 14:20:03 raspberrypi netromd[17311]: netromt: sendto: Message too long
Feb 6 14:20:08 raspberrypi netromd[17311]: netromt: sendto: Message too long
Feb 6 14:20:13 raspberrypi netromd[17311]: netromt: sendto: Message too long
Feb 6 14:20:18 raspberrypi netromd[17311]: netromt: sendto: Message too long
Feb 6 14:20:23 raspberrypi netromd[17311]: netromt: sendto: Message too long
Feb 6 14:20:28 raspberrypi netromd[17311]: netromt: sendto: Message too long
Feb 6 14:20:33 raspberrypi netromd[17311]: netromt: sendto: Message too long
Feb 6 14:20:38 raspberrypi netromd[17311]: netromt: sendto: Message too long
Feb 6 14:20:43 raspberrypi netromd[17311]: netromt: sendto: Message too long
Feb 6 14:35:04 raspberrypi netromd[17320]: netromt: sendto: Message too long
Feb 6 14:35:09 raspberrypi netromd[17320]: netromt: sendto: Message too long
Feb 6 14:35:14 raspberrypi netromd[17320]: netromt: sendto: Message too long
Feb 6 14:35:19 raspberrypi netromd[17320]: netromt: sendto: Message too long
This can be fixed by releasing a patch on the ax25tools/netrom/netromt.c file.
106c106,111
<
---
> int ax_paclen;
>
> ax_paclen = ax25_config_get_paclen (port_list[port].port);
> if (ax_paclen == 0)
> ax_paclen = NODES_PACLEN;
>
183,184c188,189
< if (len + ROUTE_LEN > NODES_PACLEN)
< break;
---
> if (len + ROUTE_LEN > ax_paclen)
> break;
197,198c202,203
< /* If the packet was not full then we are done */
< } while (len + ROUTE_LEN > NODES_PACLEN);
---
> /* If the packet was not full then we are done */
> } while (len + ROUTE_LEN > ax_paclen);
It can be easy to link an ax25 interface to Direwolf. This makes it possible to use RMSGateway, Uronode etc with Direwolf.
In this script Direwolf is started with the -p option. With the -p option a virtual tnc is created. /tmp/kisstnc.
With mkiss a kiss connection is made on the /tmp/kisstnc. With kissattach the PTY is connected to the ax25 interface.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
You must be logged in to post a comment.