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:
# 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.
- <port_name>
is the name of the AX.25, NET/ROM 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 NET/ROM
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.
- <peer>
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.
- window
is the AX.25 Window parameter (K) or MAXFRAME parameter for
this configuration.
- T1
is the Frame retransmission (T1) timer in half second units.
- T2
is the amount of time the AX.25 software will wait for another
incoming frame before preparing a response in 1 second units.
- T3
is the amount of time of inactivity before the AX.25 software
will disconnect the session in 1 second units.
- idle
is the idle timer value in seconds.
- N2
is the number of consecutive retransmissions that will occur
before the connection is closed.
- <mode>
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.
- u/U
UTMP - currently unsupported.
- v/V
Validate call - currently unsupported.
- q/Q
Quiet - Don't log connection
- n/N
check NET/ROM Neighbour - currently unsupported.
- d/D
Disallow Digipeaters - Connections must be direct, not digipeated.
- l/L
Lockout - Don't allow connection.
- */0
marker - place marker, no mode set.
- <uid>
is the userid that the program to be run to support the
connection should be run as.
- <cmd>
is the full pathname of the command to be run, with no
arguments specified.
- <cmd-name>
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.
- <arguments>
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:
- %d
Name of the port the connection was received on.
- %U
AX.25 callsign of the connected party without the SSID, in
uppercase.
- %u
AX.25 callsign of the connected party without the SSID, in
lowercase.
- %S
AX.25 callsign of the connected party with the SSID, in
uppercase.
- %s
AX.25 callsign of the connected party with the SSID, in
lowercase.
- %P
AX.25 callsign of the remote node that the connection came
in from without the SSID, in uppercase.
- %p
AX.25 callsign of the remote node that the connection came
in from without the SSID, in lowercase.
- %R
AX.25 callsign of the remote node that the connection came
in from with the SSID, in uppercase.
- %r
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, 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:
# 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 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.
