Updated! Configuring Linux AX.25
This page explains how to configure a Linux AX.25 system. The examples here are based on the W8APR Linux system, which supports an FBB PBBS system, and also acts as a G8BPQ/NetROM/LinuxNode switch and simple AXIP gateway. We've also recently added a CLX DX Cluster to the machine, and I'll be updating this page Real Soon Now to reflect that. The system uses Linux' built-in support for AX.25, with the "ax25-utils" package to provide the programs needed. It also includes AX25-over-IP encapsulation to support the gateway.
The system has three RF ports. One is a DRSI card for 1200 baud user access on 2m, and the second is an Ottawa PI Card for our 19.2 baud network on UHF. The third is a serial-port interface for a KISS TNC; although it's inactive now, it will support a connection to our new 9600 baud UHF packet repeater.
This machine was originally set up with Debian Linux 1.3, with kernel 2.0.33 patched with ax25-module-14f (kernel versions 2.0.35 and later include this patch, so it's not necessary to add it if you're using one of those kernels). The user programs were from ax25-utils-2.1.42a. The axip digi is from the axdigi-0.02 package. The SCC driver uses the z8530drv-utils-2.4c package.
The hardware is a 486 with 32MB of RAM and about 500MB of hard disk; the basic AX25 stuff will run nicely in an 8MB machine, though. Update: We've upgraded the system to a Pentium 200 with 64MB RAM. Although all the other applications ran nicely on a 486, the CLX packet cluster software is quite resource intensive and on contest weekends even a Pentium 66 got bogged down. The Pentium 200 just loafs along with all services running.
We've also updated the software to a Debian 2.2 system with kernel 2.2.17 and the new ax25 packages referenced on the main page. The changes to the config scripts were very minor, and I've noted them in comments below.
There is one thing to watch out for with the new ax25 packages. If you install the ax25 stuff from Debian or RedHat packages, they will be installed in /usr/sbin with the config files in /etc/ax25. But... if you obtain the sources and build them yourself, the programs will be installed in /usr/local/sbin with the config files in /usr/local/etc/ax25. That can cause problems if the home-built programs need to read, for example, the axports file and are looking for it in /usr/local/etc/ax25 when it really lives in /etc/ax25.
The workaround is simple, though it's not The Right Thing according to the filesystem standards: make /usr/local/etc/ax25 a symbolic link to /etc/ax25. That way, no matter which directory a program looks in for its configuration files, it will find the same ones. To do that, issue this command:
What's the deal with callsigns, anyway?
One of the most confusing things about Linux AX.25 is the use of callsigns. Here's the scoop as I understand it.You need to have a unique call/SSID assigned to each physical port on the system. However, you don't have to actually use these calls for anything, and, as long as you send a legal ID according to the requirements of your regulatory authorities, the calls used don't have to be real; you can use an alias or some other identifier. (NOTE: I've been told that some countries view "fake" callsigns in the AX.25 "FROM" field to be a violation of the rules, so you'd be wise to check that out for your jurisdiction.)
In a system configured the way I describe here, these port callsigns will only be used as hardware addresses for IP traffic and won't be used for normal AX.25 or NetROM connections (though you could use them that way if you wanted to). Since the hardware address in a TCP/IP environment is usually invisible to the user, the callsigns used don't have much significance; they can be anything as long as they're unique.
Next, you need to have callsign/SSIDs associated with "virtual" ports such as NetROM or AXIP. Under some circumstances, these calls can be shared with other services, but it's best not to do so unless the sharing applications are known to work together. In the configuration described here, there is one unique NetROM call/SSID that's used on the air; two other NetROM ports (one for the F6FBB BBS and one for the node) share callsigns used by other services (these are two of those special cases...). The AXIP daemon, if you use one, will require one call/SSID of its own.
The callsigns I've mentioned so far are used as "source" callsigns in outbound packets. However, a Linux AX.25 system can listen for, and respond to, packets sent to other callsigns. In other words, you can configure your system to respond to as many different alias calls as you want, and you can have it respond differently depending on either the callsign of the station sending the packet, or the destination call. In other words, Linux AX.25 can be different things to different users; depending on who they are, who they are calling, and what port they are calling on, Linux can look like a BBS, a node, a cluster, or any other service you choose to offer. It can even look like nothing at all, because you can ignore certain users, or send them to /dev/null (that's the *nix equivalent of never-never land).
In our system, there are two services that listen directly for callsigns. One is the ax25d daemon that parcels most incoming connect requests to the appropriate place (like the node software), and the other is the FBB BBS software that listens for its own callsign. The rule here is that the FBB call/SSID (configured in FBB's init.srv file) must not be used by any other service. The only exception is that the FBB call/SSID can (but need not) be shared with the NetROM port it is listening to -- that way, a single callsign/alias can be used to connect to the BBS via either normal AX.25 or NetROM.
The ax25d configuration file allows great flexibility -- it can be set up to listen and respond to any callsign on any port. Unfortunately, FBB doesn't use it. But for other applications, like the node software, you can configure the system to use the same or different callsigns on each port, have different programs run depending on the call used, and have different actions occur based on the user's call. It's a bit complex, but you can do a lot with it. I'll describe the /etc/ax25/ax25d.conf file a bit later.
Of Interfaces, Ports, and Callsigns
Another aspect of AX.25 configuration that can be a bit confusing is the relationship between network interfaces, "ports" as used by the AX.25 tools and applications, and callsigns.Under Linux, every device that the kernel uses for networking is assigned a network interface name by the driver that initializes the device. For example, the first ethernet card in the system is known as "eth0". Devices created with the kissattach command have interface names like "axN" (where "N" is a number starting with 0 which increments by one each time another device is created). Other network hardware uses interface names like "sccN" for SCC cards or "bcN" for the Baycom driver.
Interface names are used by Linux networking tools like ifconfig and route. Most AX.25 tools and application, however, do not use them. Instead, they use a port name that is derived from the /etc/ax25/axports file. Here's a crucial insight. Although the format of axports puts the port name first in each line, and the callsign second, the mapping actually works in reverse: the link between AX.25 port and network interface is the callsign, not the port name.
This means that each network interface must have a callsign set as its hardware address before it can be accessed by a portname (of course, the hardware address is important for other reasons, like station ID and frame addressing, as well). Once the hardware address is set, the mapping in axports determines the port name assigned to that interface.
The kissattach command assigns the callsign as part of its syntax. Other hardware drivers, like the scc and dmascc drivers, don't. Therefore, when using those devices you need to use the ifconfig command to set the hardware address:
Then, and only then, will axports be able to assign a port name to the interface.
(By the way, thanks to Tomi Maninnen, OH2BNS, for helping me understand the linkage between interface names and ports.)
IP Addresses
Linux networking is built around TCP/IP concepts. Once you have the network interfaces, callsigns, and port names figured out, you also need to deal with IP addresses -- even if you're not planning to use TCP/IP at all! The rule is that every network interface on a Linux system needs an IP address, even if you don't plan to run IP on that interface. If an interface doesn't have an address, the whole networking subsystem can get confused and very unhappy.This means that every interface you create, whether with kissattach, nrattach, or some other hardware driver, needs an IP address assigned. If you're not going to use IP on a port, you can assign a dummy address like 192.168.1.1* -- but you need to assign something!
Some programs, like kissattach require the IP address as one of the command line parameters. Others don't; for those, you use the ifconfig command to set the address.
* The People In Charge of Such Things have set aside a number of IP address ranges for private networks and other uses that do not connect with the Internet at large. The block from 192.168.0.0 through 192.168.255.255 is one of those.
Starting AX25
Debian uses files in /etc/init.d to start various programs at boot time. So, we've created a file called /etc/init.d/ax25.init to configure and start the ax25 programs. If you're running another Linux distribution, you might have to put the contents of this file in the /etc/rc.local file instead. Some of the features of this file will become more obvious when we look at the other config files a bit later.Here's a sample ax25 init script.
The "axsetparms" program mentioned in the script is a little program I wrote to reset port parameters like maxframe, paclen, etc. at boot time. Here's more information about axsetparms.
axports
The most important of the config files stored in /etc/ax25 is /etc/ax25/axports, which defines the port names, their associated mappings, and some default parameters for each port. Since the programs run by /etc/init.d/ax25 rely on this file, you need to create it before you try attaching any interfaces or running the daemons.
# /etc/ax25/axports # # The format of this file is: # # name callsign speed paclen window description # scc0 W8APR-13 - 255 3 145.61 MHz (1200 bps) 19k2 W8APR-12 - 255 4 420.95/430.95 MHz (19.2kbps) uhf W8APR-11 - 255 4 UHF 9600 baud axip W8APR-10 - 255 4 axip interface
Remember that the callsigns used need to match those assigned with kissattach or ifconfig. And, note that the SSIDs attached to the callsigns are at the high end of the range. Linux AX.25 can use a lot of callsign/SSID combinations, but the calls actually connected to a give hardware port aren't the most important ones as they aren't normally used by human users. So, I'm using the high SSIDs for the hardware, and the lower ones for real services.
Why didn't I start with -14? I could have, but that's used for a dummy NetROM interface -- read on. And, remember that the calls used need to match those assigned using kissattach or the ifconfig command.
nrports and nrbroadcast
The /etc/ax25/nrports and /etc/ax25/nrbroadcast files set up NetROM. To make NetROM act like a traditional G8BPQ-style node, you need a bit more than the minimum configuration. For the MVFMA system, which wants to look like a BPQ node in front of an FBB BBS system, we need to define three NetROM ports rather than just one.The first (netrom in the nrports file) is a "dummy" interface. Nothing will ever connect to it, but its call will be used for outbound NetROM connections. In this example, I've assigned W8APR-14 and alias #MVFMA to the dummy port. The "#" character in front of the alias name means that this node will not appear in the standard nodes list at remote nodes.
NetROM port netbbs is configured to use W8APR-0 as its call and SSID, and MVFMA as its alias. The F6FBB software is configured to listen for W8APR-0 in init.srv, and to listen on port netbbs in port.sysi. With this configuration, a connection to W8APR-0 or node MVFMA will drop the user directly into the BBS. For this scheme to work, however, W8APR-0 and <netbbs> must not be included in ax25d.conf -- if two services are listening for the same call, Bad Things will happen.
Finally, the netnod NetROM port is bound to W8APR-1 and alias BBROOK. This port and callsign are configured in ax25d.conf to start up the "node" application -- so, a connect via NetROM to BBROOK brings up the node front end, and looks pretty much like what a user would see connecting to the BPQ front end of a DOS FBB system.
# /etc/ax25/nrports # # The format of this file is: # # name callsign alias paclen description # netrom W8APR-14 #MVFMA 235 Switch netbbs W8APR-0 MVFMA 235 FBB Port netnod W8APR-1 BBROOK 235 Node
We only broadcast NetROM info on the pi0a port:
# /etc/ax25/nrbroadcast # # The format of this file is: # # ax25_name min_obs def_qual worst_qual verbose # 19k2 5 250 100 0
Setting the "verbose" parameter to 0 means that we will only broadcast our own node information, and not rebroadcast routes to other nodes. That is appropriate for W8APR since we don't have routes to any nodes other than our own (a multiport switch is a different case).
ax25d.conf
Next, /etc/ax25/ax25d.conf defines what program to spawn when a user connects to the system. It's a very flexible structure that allows mapping callsigns to services on a very detailed basis.The interplay between this program and some others that listen for callsigns themselves can be confusing. You do not specify anything to do with either FBB or axip in this file. In our case, we're simply setting up access to the node for connects to W8APR-1 or the alias "BBROOK" on any radio port, or to the netrom node defined as "netnod" (which also answers to "BBROOK").
One thing to note when editing ax25d.conf -- that blank lines in the file can cause problems. For best results, make sure that blank lines have a "#" at the beginning.
# /etc/ax25/ax25d.conf # # ax25d Configuration File. # # AX.25 Ports begin with a '['. # [BBROOK VIA scc0] NOCALL * * * * * * L default * * * * * * - root /usr/sbin/node node # [W8APR-1 VIA scc0] NOCALL * * * * * * L default * * * * * * - root /usr/sbin/node node # [BBROOK VIA uhf] NOCALL * * * * * * L default * * * * * * - root /usr/sbin/node node # [W8APR-1 VIA uhf] NOCALL * * * * * * L default * * * * * * - root /usr/sbin/node node # [BBROOK VIA 19k2] NOCALL * * * * * * L default * * * * * * - root /usr/sbin/node node # [W8APR-1 VIA 19k2] NOCALL * * * * * * L default * * * * * * - root /usr/sbin/node node # <netnod> NOCALL * * * * * * L default * * * * * * - root /usr/sbin/node node #
Remember, the FBB PBBS is configured to listen for W8APR-0 and MVFMA; including those in ax25d.conf would cause much confusion.
node.conf, node.info, and node.perms
These three files control the LinuxNode user front-end. I haven't done any significant tweaking to the sample files provided with the ax25-utils package, other than customizing node.info to reflect our site, so I won't reprint them here.
ax25ipd.conf
The ax25ipd program can be used to setup AX.25-within-IP tunnelling, which is the basis for Internet Gateways and other cool applications. The ax25ipd.conf file is used to configure this daemon. Because there are several issues to consider when setting up ax-ip links, I've created a separate ax25ipd configuration page.
axdigi
Linux AX.25 doesn't include digipeater functionality as a standard part of the distribution. There is a separate program, axdigi, which provides basic cross-port digi capabilities. You can download axddigi from ftp://ftp.febo.com/pub/linux_ham/axdigi-0.02.tar.gz.The program works well, but it offers no configurability at all -- you just run it as part of the AX.25 startup script. Unlike most daemon programs, axdigi doesn't go into the background automatically -- you need to run it as /usr/sbin/axdigi &. If you forget the "&" character, the config script will hang forever. You Have Been Warned.
One result of axdigi's simplicity is that it allows wide-open digipeating from any AX.25 interface to any other. This may not be desirable, so keep this in mind if you decide to use it.
FBB AX.25 Configuration
Finally, here are F6FBB/Linux config files to map into the setup described here.There are two pieces of the FBB puzzle that I don't have working yet. I want to have a "BBS" command in the node front end that will launch the BBS, and I want an AX.25 connect to alias MVFMA to bring up the BBS. These are both doable, but require a little trickerly in ax25d.conf; I'm working on it and will update this page when I finalize the configuration for these functions.
Return to Linux AX.25 Configuration