This section provides some detail on how to actually install and use some of the listed software. It will also detail some solutions to some tricky problems that you might encounter with the software.
The AX.25 protocol offers both connected and connectionless modes of operation, and is used either by itself for point-point links, or to carry other protocols such as tcp/ip and netrom.
It is similar to X.25 level 2 in structure, with some extensions to make it more useful in the amateur radio environment.
The NetRom protocol is an attempt at a full network protocol and uses AX.25 at its lowest layer as a datalink protocol. It provides a network layer that is an adapted form of AX.25.
Alan Cox developed some early kernel based AX.25 software support for Linux.
Jonathon Naylor <g4klx@g4klx.demon.co.uk> has taken up ongoing
development of the code, has added NetRom support and this is available in
ALPHA form for you to experiment with. The Linux code supports KISS based
TNC's (Terminal Node Controllers), the Ottawa PI card and the Z8530 SCC driver.
Any bug reports relating to the AX.25 or Netrom software should now
go to Jonathon.
The User programs contain a simple PMS (Personal Message System), a beacon facility, a line mode connect program, `listen' an example of how to capture all AX.25 frames at raw interface level and programs to configure the Netrom protocol. Included also are an AX.25 server style program to handle and despatch incoming AX.25 connections and a NetRom daemon which does most of the hard work for NetRom support.
The AX.25 software is comprised of two components, the kernel source and the utility programs. As of the version 1.3.* release of Linux kernel source the AX.25, Netrom, Z8530 SCC and PI card drivers are all included as a standard. I recommend you obtain and use the version 1.3.* kernel source. There are three reasons I'm recommending you use the alpha version software and they are:
Be warned though, this software is alpha and may have problem that you wouldn't otherwise encounter. Please take all the usual precautions and be sure to keep a working kernel as backup when testing new kernels. It is wise to test a new kernel by booting from it from floppy before actually installing it with lilo, though I haven't bothered for about 90 kernels revisions so I'm fairly confident you can pretty safely run with alpha kernels.
You can obtain the latest kernel source from:
ftp.funet.fi
/pub/OS/Linux/PEOPLE/Linus/v1.3/
You will also need the utility programs. The latest version of those can be found at:
sunsite.unc.edu
/pub/Linux/apps/ham/ax25-utils-1.3.30.tar.gz
or:
ftp.ucsd.edu
/hamradio/packet/tcpip/incoming/ax25-utils-1.3.30.tar.gz
The software comes in two parts, the kernel source, and the user programs.
If you are using the 1.3.* kernel source then all you have to do is build the kernel as you would normally.
The following should be safe:
# cd /usr/src/linux
# make config
# make dep;make
Do you want to be offered ALPHA test drivers ?
and:
Other ISA cards ?
then `y' when prompted:
Ottawa PI and PI/2 support.
To install the user programs you should try:
# cd /usr/local
# gzip -dc ax25-utils-1.3.30.tar.gz | tar xvvof -
# cd ax25-utils-1.3.30
... if you are using a.out binaries:
# install.sh a.out
... if you want to install ELF binaries:
# install.sh ELF
If you want to compile your own binaries then you should do the following:
# cd src
# make clean
# make install
Configuring an AX.25 port is very similar to configuring a slip device. The AX.25 software has been designed to work with a TNC in kiss mode or an Ottawa PI2 card. You will need to have the TNC preconfigured and connected to your serial port. You can use a comms program like minicom or seyon to configure the TNC into kiss mode if you wish.
You use the axattach program in much the same way as you would use the slattach program (refer to the NET-2-HOWTO for more information on slattach and the other network software for Linux). For example:
# /usr/local/sbin/axattach -s 4800 /dev/ttyS1 VK2KTJ-1 &
# sleep 2
would configure your /dev/ttyS1 serial device to be a kiss
interface at 4800 bps, with the hardware address VK2KTJ. The sleep
of 2 seconds is necessary just to give the kernel a little time to do some
housekeeping that it has to do before you try and change the interface.
You can use the axsetcall command to change the callsign of an AX.25 interface after it has been created if you wish.
All this step has done is to actually activate the device in the kernel, you need to run other programs before you an actually make use of the port. The AX.25 ports have a configuration file that can be read by any program that wants to use AX.25 to find information about the port. This file is called the:
/usr/local/etc/axports
file. The format of the file is as follows:
callsign baudrate window label
where:
is the AX.25 callsign you want to assign to the port.
is the speed at which you wish the port to communicate with your TNC.
is the AX.25 window (K) parameter. This is the same as the
MAXFRAME setting of many tnc's.
is a name for the port.
In my case, mine looks like:
VK2KTJ-1 4800 1 radio
At this stage not all of this information is used, it will be picked up and used in later developments. You now should be able to make outgoing AX.25 connections. To test AX.25 connected mode you could use something similar to the following:
/usr/local/bin/call VK2DAY via VK2RVT
The call program is a linemode terminal program for making AX.25 calls. It recognises lines that start with ` ' as command lines. The ` .' command will close the connection.
Please refer to the man pages in /usr/local/man and the
README file in ax25-utils-1.3.30 distribution for more
information.
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 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?". As detailed in the software list at the start of this document there are BBS systems that are being developed that you might want users to see when they connect, 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.
You do this within the /usr/local/etc/ax25d.conf. This file is the
configuration file for the ax25d AX.25 daemon which handles incoming
AX.25 connections.
The file is a little cryptic looking at first, but you'll soon discover it is very simple in practise, with a small trap for you to be wary of.
The format of the ax25d.conf file is as follows:
# This is a comment and is ignored by the ax25d program.
[<interface_call>]
<peer1> window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
<peer2> window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
defaults window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
<peer3> window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
...
default window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
Where:
at the start of a line marks a commment and is completely ignored by the ax25d program.
is the AX.25 callsign of the interface that this particular paragraph is for.
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 Windows 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 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 setting or resetting bits in an 8 bit map. You set that map by setting <mode> to the sum of the following values:
Setup utmp, and run on a ptty (planned).
UNUSED.
UNUSED.
UNUSED.
UNUSED.
UNUSED.
Disallow digipeated uplinks, only allow direct connections.
Lockout, Barred, immediate disconnect.
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:
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.
You need one section in the above format for each AX.25 interface you want to accept incoming AX.25 connections on.
There are two special lines in the paragraph, one starts with the string
`defaults' and 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 `defaults' 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
`default' line is what sets those default values. The kernel software
itself has some defaults which will be used if you don't specify any. The trap
is that the these defaults apply only to those rules below
the `default' line not to those above. You may have more than one
`default' rule per interface definition, and in this way you may
create groups of default configurations.
Ok, an illustrative example:
# ax25d.conf for VK2KTJ - 21/11/95
# This configuration uses the AX.25 port defined earlier.
[VK2KTJ-1]
NOCALL * * * * * 0 guest /usr/games/fortune
defaults 1 10 * * * 0 root /bin/login ax25login
VK2XLZ-1 * * * * * * * * *
VK2DAY-1 * * * * * * * * *
default 1 10 5 100 5 0 root /usr/local/bin/bbs bbs %u
#
This example says that anybody to the interface on my machine with the callsign
VK2KTJ-1 will have the following rules applied:
Anyone whose callsign is set to `NOCALL' should use the kernel default
parameters and have the fortune program run as guest for
them.
The defaults line changes two parameters from the kernel defaults
(Window and T1) and will run the /bin/login login program for them.
Any copies of login run this way will appear as ax25login
in a ps listing so that you can easily distinguish AX.25 logins
from others. Following are 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 bbs program to run with a command line argument of the callsign of the connecting peer in lower case with no SSID.
If you wanted to define rules for another interface, even a Netrom interface, then you would add another paragraph coded in the same way with rules and callsign appropriate to it.
This example is a contrived one but I think it illustrates clearly the
important features of the syntax of the configuration file. Jonathon includes
a much longer and more detailed example in the ax25-utils package.
If you want to carry tcp/ip over the AX.25 port you have configured, all you need to do is use the ifconfig program to configure the ip address and netmask details for the port and add a route via the port.
# /sbin/ifconfig sl0 44.136.8.5
# /sbin/ifconfig sl0 netmask 255.255.255.0
# /sbin/ifconfig sl0 broadcast 44.136.8.255
# /sbin/ifconfig sl0 arp mtu 256 up
# /sbin/route add -net 44.136.8.0 sl0
# /sbin/route add default sl0
The commands listed above are typical of the sort of configuration many of you would be familiar with if you have used NOS or any of its derivatives or any other tcp/ip software. Note the default route might not be required if you have some other network device conifgured.
To test it out, try a ping or a telnet to a local host.
To configure Netrom for an AX.25 interface you must configure two files.
The first is the /usr/local/etc/nrports file. This file describes
the Netrom port.
This file is formatted as follows:
callsign alias description
Where:
is the callsign that the Netrom traffic from this port will use.
is the Netrom alias this port will have assigned to it.
is a free text description of the port.
An example would look something like the following:
VK2KTJ MTCOLAH Netrom Switch Port
Note again that the first line refers to the first Netrom interface, the second line refers to the second Netrom interface and so on.
The second file is the /usr/local/etc/nrbroadcast file.
This file is formatted as follows:
port min_obs def_qual worst_qual verbose
Where:
is the port number obtained from the
/usr/local/etc/axports file. The first line in the file describes
AX.25 port number one, the second describes port number two etc. If you do not
have an entry in /usr/local/etc/nrbroadcasts for a port then
this means that no Netrom routing will occur and any received Netrom
broadcasts will be ignored for that port.
is the minimum obselesence value for the port.
is the default quality for the port.
is the worst quality value for the port, any routes under this quality will be ignored.
is a flag determining whether full Netrom routing broadcasts will occur from this port or only a routing broadcast advertising the node itself.
An example would look something like the following:
1 1 200 10 1
2 1 200 10 1
The Ottawa PI card is a Z8530 SCC based card for IBM PC type machines that is in common usage by Amateur Radio operators worldwide. While it is most commonly used by Amateur Radio Operators, it could be pressed into service in other fields where it is desirable to have the features of a Z8530. It supports a high speed half duplex (single DMA channel) port, and a low speed (<9k6bps interrupt driven) half duplex port. The PI2 is a new version of the card that supports an on board radio modem, and improved hardware design.
A driver for this card has been written by David Perry,
<dp@hydra.carleton.edu>, and is available from in the
standard linux kernel. Please refer to the AX.25 section above for details on
how to configure the kernel to include the PI card driver.
Once you have the PI card driver configured into your kernel then you should
reboot and when you do you should see mention of the PI card driver in the
messages that appear on the screen while the kernel is booting. The kernel
tests each of the I/O port addresses that a PI card might be configured for
and reports any that it finds. You should then look at the
/proc/net/dev file and you should see reference to devices called
pi0a and pi0b etc.
If you don't then recheck that you have configured and compiled your kernel correctly and that you are in fact actually running your new kernel. If you still don't then this suggests that your PI card was not detected by the kernel while it is booting and may indicate that you have some sort of hardware conflicting with your PI card that prevented it being detected.
If all of the above went as planned then you will need to configure your PI card for IP. The configuration of the PI card is virutally identical to that of any other IP interface. Something like the following should work ok for you:
# /sbin/ifconfig pi0a 44.136.8.5
# /sbin/ifconfig pi0a netmask 255.255.255.0
# /sbin/ifconfig pi0a broadcast 44.136.8.255
# /sbin/ifconfig pia arp mtu 256 up
# /sbin/route add -net 44.136.8.0 pi0a
# /sbin/route add default pi0a
Note that pi0a refers to the `a' port on the first PI card found, and
that pi0b would therefore refer to the `b' port on the first PI card
found etc.
As usual, when this has been done you can test the interface with the ping or telnet command to ensure it is working.
Many people like to run some version of NOS under Linux because it has all of the features and facilities they are used to. Most of those people would also like to have the NOS running on their machine capable of talking to the Linux kernel so that they can offer some of the linux capabilities to radio users. Brandon S. Allbery, KF8NH, contributed information to explain how to achieve this.
Since both Linux and NOS support the slip protocol it is possible to link the two together by creating a slip link. You could do this by using two serial ports with a loopback cable between them, but this would be slow and costly. Linux provides a feature that many other unix-like operating systems provide called `pipes'. These are special pseudo devices that look like a standard tty device to software but in fact loopback to another pipe device. To use these pipes the first program must open the master end of the pipe, and the open then the second program can open the slave end of the pipe. When both ends are open the programs can communicate with each other simply by writing characters to the pipes in the way they would if they were terminal devices.
To use this feature to connect the Linux Kernel and a copy of NOS, or some
other program you first must chosoe a pipe device to use. You can find one
by looking in your /dev directory. The master end of the pipes are
named: ptyp[1-f] and the slave end of the pipes are known as:
ttyp[1-f]. Remember they come in pairs, so if you select
/dev/ptypf as your master end then you must use /dev/ttypf
as the slave end.
Once you have chosen a pipe device pair to use you should allocate the master end to you linux kernel and the slave end to the NOS program, as the Linux kernel starts first and the master end of the pipe must be opened first. You must also remember that your Linux kernel must have a different IP address to your NOS, so you will need to allocate a unique address for it if you haven't already.
You configure the pipe just as if it were a serial device, so to create the slip link from your linux kernel you can use commands similar to the following:
# /sbin/slattach -s 38400 -p slip /dev/ptypf &
# /sbin/ifconfig sl0 broadcast 44.255.255.255 pointopoint 44.70.248.67 /
mtu 1536 44.70.4.88
# /sbin/route add 44.70.248.67 sl0
# /sbin/route add -net 44.0.0.0 gw 44.70.248.67
In this example the Linux kernel has been given IP address 44.70.4.88
and the NOS program is using IP address 44.70.248.67. The
route command in the last line simply tells your linux kernel to route
all datagrams for the amprnet via the slip link created by the
slattach command. Normally you would put these commands into your
/etc/rc.d/rc.inet2 file after all your other network configuration
is complete so that the slip link is created automatically when you reboot.
Note: there is no advantage in using cslip instead of slip
as it actually reduces performance because the link is only a virtual
one and occurs fast enough that having to compress the headers first takes
longer than transmitting the uncompressed datagram.
To configure the NOS end of the link you could try the following:
# you can call the interface anything you want; I use "linux" for convenience.
attach asy ttypf - slip linux 1024 1024 38400
route addprivate 44.70.4.88 linux
These commands will create a slip port named `linux' via the slave end of the pipe device pair to your linux kernel, and a route to it to make it work. When you have started NOS you should be able to ping and telnet to your NOS from your Linux machine and vice versa. If not, double check that you have made no mistakes especially that you have the addresses configured properly and have the pipe devices around the right way.