Whole document tree
Linux is a powerful operating system and offers a great deal of flexibility in how it is configured. With this flexibility comes a cost in configuring it to do what you want. When configuring your Linux machine to accept incoming AX.25, NET/ROM or ROSE connections there are a number of questions you need to ask yourself. The most important of which is: "What do I want users to see when they connect?". People are developing neat little applications that may be used to provide services to callers, a simple example is the pms program included in the AX.25 utilities, a more complex example is the node program also included in the AX.25 utilities. Alternatively you might want to give users a login prompt so that they can make use of a shell account, or you might even have written your own program, such as a customized database or a game, that you want people to connect to. Whatever you choose, you must tell the AX.25 software about this so that it knows what software to run when it accepts an incoming AX.25 connection.
The ax25d program is similar to the inetd program commonly used to accept incoming TCP/IP connections on UNIX machines. It sits and listens for incoming connections, when it detects one it goes away and checks a configuration file to determine what program to run and connect to that connection. Since this the standard tool for accepting incoming AX.25, NET/ROM and ROSE connections I'll describe how to configure it.
This file is the configuration file for the ax25d AX.25 daemon which handles incoming AX.25, NET/ROM and ROSE connections.
The file is a little cryptic looking at first, but you'll soon discover it is very simple in practice, with a small trap for you to be wary of.
The general format of the ax25d.conf file is as follows:
You need one section in the above format for each AX.25, NET/ROM or ROSE interface you want to accept incoming AX.25, NET/ROM or ROSE connections on.
There are two special lines in the paragraph, one starts with the string `parameters' and the other starts with the string `default' (yes there is a difference). These lines serve special functions.
The `default' lines purpose should be obvious, this line acts as a catch-all, so that any incoming connection on the <interface_call> interface that doesn't have a specific rule will match the `default' rule. If you don't have a `default' rule, then any connections not matching any specific rule will be disconnected immediately without notice.
The `parameters' line is a little more subtle, and here is the trap I mentioned earlier. In any of the fields for any definition for a peer you can use the `*' character to say `use the default value'. The `parameters' line is what sets those default values. The kernel software itself has some defaults which will be used if you don't specify any using the `parameters' entry. The trap is that the these defaults apply only to those rules below the `parameters' line, not to those above. You may have more than one `parameters' rule per interface definition, and in this way you may create groups of default configurations. It is important to note that the `parameters' rule does not allow you to set the `uid' or `command' fields.
Okay, an illustrative example:
This example says that anybody attempting to connect to the callsign `VK2KTJ-0' heard on the AX.25 port called `radio' will have the following rules applied:
Anyone whose callsign is set to `NOCALL' should be locked out, note the use of mode `L'.
The parameters line changes two parameters from the kernel defaults (Window and T1) and will run the /usr/sbin/axspawn program for them. Any copies of /usr/sbin/axspawn run this way will appear as axspawn in a ps listing for convenience. The next two lines provide definitions for two stations who will receive those permissions.
The last line in the paragraph is the `catch all' definition that everybody else will get (including VK2XLZ and VK2DAY using any other SSID other than -1). This definition sets all of the parameters implicitly and will cause the pms program to be run with a command line argument indicating that it is being run for an AX.25 connection, and that the owner callsign is VK2KTJ. (See the `Configuring the PMS' section below for more details).
The next configuration accepts calls to VK2KTJ-1 via the radio port. It runs the node program for everybody that connects to it.
The next configuration is a NET/ROM configuration, note the use of the greater-then and less-than braces instead of the square brackets. These denote a NET/ROM configuration. This configuration is simpler, it simply says that anyone connecting to our NET/ROM port called `netrom' will have the node program run for them, unless they have a callsign of `NOCALL' in which case they will be locked out.
The last two configurations are for incoming ROSE connections. The first for people who have placed calls to `vk2ktj-0' and the second for `VK2KTJ-1 at the our ROSE node address. These work precisely the same way. Not the use of the curly braces to distinguish the port as a ROSE port.
This example is a contrived one but I think it illustrates clearly the important features of the syntax of the configuration file. The configuration file is explained fully in the ax25d.conf man page. A more detailed example is included in the ax25-utils package that might be useful to you too.
When you have the two configuration files completed you start ax25d with the command:
When this is run people should be able to make AX.25 connections to your Linux machine. Remember to put the ax25d command in your rc files so that it is started automatically when you reboot each time.