Configuring Linux AX.25: ax25ipd
We wanted to run an axip gateway so that the local DX Cluster, which is on our 19.2kbaud UHF network, could link with a remote cluster. We did not want to do NetROM-over-IP, so this configuration is a very simple, though not necessarily intuitive, one.
Getting the axip stuff to work was the biggest challenge we had -- it's not particularly well documented, and one of the principle concepts refused to make itself clear to me for quite a while. Hopefully, this information will make it easier for you.
Here's the part it took me a while to grasp: running the ax25ipd daemon does nothing more than create a new KISS interface on your system that's hooked to one end of a pseudo-tty ("pty") pipe. The other end is attached via kissattach, and the result is an ax25 interface that acts just like all the other interfaces -- it is configured with axports, etc.
The second confusing thing about configuring ax25ipd is that it can be used in "tnc" mode or in "digi" mode. Since I ultimately wanted to allow the Cluster to reach its remote friend via a digi path, I foolishly thought that digi mode was the one to use. Wrong. I'm still not sure what you use digi mode for, but it's not for this. I ended up using tnc mode, and using the axdigi program (describe below) to accomplish the digi function. (Actually, Tomi Manninen, OH2BNS, has pointed out that the "digi" mode can be used to solve the problem I note in the "Gotcha" section below. More details can be found there.)
Here's our ax25ipd.conf file:
# ax25ipd.conf socket ip mode tnc device /dev/ttyqf speed 9600 loglevel 2 route YNGDX xxx.xxx.xxx.xxx # IP address deleted
Note that the specified device is the "slave" end of a pty pair (first letter of the device name is "t"). The kissattach command uses the "master" end, which is the same device name but with a first letter of "p" (e.g., "/dev/ptyqf"). You have to open the master end of a pty first, or you'll get an I/O error. That means you need to issue the kissattach command before you start the axip daemon (as in the sample /etc/init.d/ax25 file above).
An ax25ipd Gotcha
Unlike xNOS, where each AXIP link requires its own call/SSID, Linux uses a single call for all AXIP links on the system. Although this makes it easy to add new AXIP links, it does have one disadvantage: except for one default route, an AXIP link can only handle traffic originating from the local callsign.Here's an example of what I mean. W8APR has an AXIP link to K8MK at 192.168.1.1, and K8MK has a similar configuration, with an AXIP route to K8MK at 10.0.0.1.
A local user at either station can use the call command ("call axip W8APR") to initiate a connect to the other, and will get the other station's node prompt. And, if W8APR-1 connects to the W8APR-0 node and then does a "c axip K8MK" command, he will get connected to K8MK.
However, if a user with another callsign logs in to the node and issues the same command, it will fail. For example, if N8UR connects to W8APR and then issues "c axip K8MK" from the node prompt, W8APR will call K8MK, but K8MK will not respond and the connection will fail.
This occurs because outbound connections from the node program are made with the node user's callsign, not the node call, as the source call. So, the connect request goes out over the axip link with a source address of N8UR, but K8MK can't respond since it has no way of knowing that packets for N8UR should be sent to W8APR via the AXIP link.
To make things worse, if you specify a callsign with SSID in ax25ipd.conf, only calls to that particular call/SSID will work. This problem can be alleviated by not specifying an SSID at all in the route command; if you use a callsign by itself, the system will respond regardless of the SSID attached to it.
You may be able to minimize this problem and make one AXIP link generally available to node users by using the "d" (default) flag on one route in ax25ipd.conf:
# ax25ipd.conf socket ip mode tnc device /dev/ttyqf speed 9600 loglevel 2 route YNGDX xxx.xxx.xxx.xxx d # Default route; IP address deleted
Now, any callsign that doesn't have a known route will be sent via this port. If your users need to connect to remote stations via more than one AXIP link, though, you'll have problems.
A way to solve this problem that may work for some applications, but which makes life a bit more difficult for end users, is to use ax25ipd in "digi" mode. In this case, the physical and axip interfaces on the system look like two digis which need to be expressly included in the connect string. Since ax25ipd routes based on the next digi callsign, or destination callsign, this can direct the packets out the proper port. So, if the local end of the axip link is W8APR-7 and the remote end is K8MK-8, a user could connect to W8APR and from the node prompt enter "c K8MK v W8APR-7 K8MK-8". Of course, this means the user needs to know that those two calls are the "digis" that he will use to reach K8MK.
Unfortunately, this digi function is available only within the node system; these digi calls aren't available over the air. In other words, as an end user, I cannot give my TNC a command like "c K8MK via W8APR, W8APR-7, K8MK-8" -- the system will ignore that unless you are running a program like axdigi to provide digipeater functionality. Unfortunately, axdigi is a somewhat limited program, and has one major flaw: if you use it, your system will allow unlimited digipeating by anyone through every port. This may be very undesireable. It may be possible to use a newer digi program like digi_ned to put together a more controlled digi environment. Though I've been using digi_ned for APRS applications with great success, I haven't tried it for this application (yet).
Return to Linux AX.25 Configuration