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, NetRom 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 AX25 utilities, a more complex example is the node program also included in the AX25 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 customised 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, NetRom and Rose connections I'll describe how to configure it.
/etc/ax25/ax25d.conf file.This file is the configuration file for the ax25d AX.25 daemon which handles incoming AX.25, NetRom 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:
# This is a comment and is ignored by the ax25d program.
[port_name] || <port_name> || {port_name}
<peer1> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
<peer2> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
parameters window T1 T2 T3 idle N2 <mode>
<peer3> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
...
default window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
Where:
at the start of a line marks a comment and is completely ignored by the ax25d program.
is the name of the AX.25, NetRom or Rose
port as specified in the /etc/ax25/axports, /etc/ax25/nrports
and /etc/ax25/rsports files. The name of the port is surrounded
by the `[]' brackets if it is an AX.25 port, the `<>' brackets
if it is a NetRom port, or the `{}' brackets if it is a Rose port.
There is an alternate form for this field, and that is use prefix the port name
with `callsign/ssid via' to indicate that you wish accept calls to the
callsign/ssid via this interface. The example should more clearly illustrate
this.
is the callsign of the peer node that this particular configuration applies to. If you don't specify an SSID here then any SSID will match.
is the AX.25 Window parameter (K) or MAXFRAME parameter for this configuration.
is the Frame retransmission (T1) timer in half second units.
is the amount of time the AX.25 software will wait for another incoming frame before preparing a response in 1 second units.
is the amount of time of inactivity before the AX.25 software will disconnect the session in 1 second units.
is the idle timer value in seconds.
is the number of consecutive retransmissions that will occur before the connection is closed.
provides a mechanism for determining certain types of general permissions. The modes are enabled or disabled by supplying a combination of characters, each representing a permission. The characters may be in either upper or lower case and must be in a single block with no spaces.
UTMP - currently unsupported.
Validate call - currently unsupported.
Quiet - Don't log connection
check NetRom Neighbour - currently unsupported.
Disallow Digipeaters - Connections must be direct, not digipeated.
Lockout - Don't allow connection.
marker - place marker, no mode set.
is the userid that the program to be run to support the connection should be run as.
is the full pathname of the command to be run, with no arguments specified.
is the text that should appear in a ps as the command name running (normally the same as <cmd> except without the directory path information.
are the command line argument to be passed to the <:cmd> when it is run. You pass useful information into these arguments by use of the following tokens:
Name of the port the connection was received on.
AX.25 callsign of the connected party without the SSID, in uppercase.
AX.25 callsign of the connected party without the SSID, in lowercase.
AX.25 callsign of the connected party with the SSID, in uppercase.
AX.25 callsign of the connected party with the SSID, in lowercase.
AX.25 callsign of the remote node that the connection came in from without the SSID, in uppercase.
AX.25 callsign of the remote node that the connection came in from without the SSID, in lowercase.
AX.25 callsign of the remote node that the connection came in from with the SSID, in uppercase.
AX.25 callsign of the remote node that the connection came in from with the SSID, in lowercase.
You need one section in the above format for each AX.25, NetRom or Rose interface you want to accept incoming AX.25, NetRom 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.
ax25d.conf file.Ok, an illustrative example:
# ax25d.conf for VK2KTJ - 02/03/97
# This configuration uses the AX.25 port defined earlier.
# <peer> Win T1 T2 T3 idl N2 <mode> <uid> <exec> <argv[0]>[<args....>]
[VK2KTJ-0 via radio]
parameters 1 10 * * * * *
VK2XLZ * * * * * * * root /usr/sbin/axspawn axspawn %u +
VK2DAY * * * * * * * root /usr/sbin/axspawn axspawn %u +
NOCALL * * * * * * L
default 1 10 5 100 180 5 * root /usr/sbin/pms pms -a -o vk2ktj
[VK2KTJ-1 via radio]
default * * * * * 0 root /usr/sbin/node node
<netrom>
parameters 1 10 * * * * *
NOCALL * * * * * * L
default * * * * * * 0 root /usr/sbin/node node
{VK2KTJ-0 via rose}
parameters 1 10 * * * * *
VK2XLZ * * * * * * * root /usr/sbin/axspawn axspawn %u +
VK2DAY * * * * * * * root /usr/sbin/axspawn axspawn %u +
NOCALL * * * * * * L
default 1 10 5 100 180 5 * root /usr/sbin/pms pms -a -o vk2ktj
{VK2KTJ-1 via rose}
default * * * * * 0 root /usr/sbin/node node radio
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 NetRom configuration, note the use of the
greater-then and less-than braces instead of the square brackets. These
denote a NetRom configuration. This configuration is simpler, it simply
says that anyone connecting to our NetRom 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:
# /usr/sbin/ax25d
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.