22. Some sample configurations

Following are examples of the most common types of configurations. These are guides only as there are as many ways of configuring your network as there are networks to configure, but they may give you a start.

22.1. Small Ethernet LAN with Linux as a router to Radio LAN

Many of you may have small local area networks at home and want to connect the machines on that network to your local radio LAN. This is the type of configuration I use at home. I arranged to have a suitable block of addresses allocated to me that I could capture in a single route for convenience and I use these on my Ethernet LAN. Your local IP coordinator will assist you in doing this if you want to try it as well. The addresses for the Ethernet LAN form a subset of the radio LAN addresses. The following configuration is the actual one for my linux router on my network at home:

                                         . . . . . .
  ___               _________         .
   | Network       /         \     .    Network
   ||         |    .     44.136.8/24        \ | /
   |               | Linux   |   .                          \|/
   |               |         |  .   _____      __________    |
   |          eth0 | Router  |  .  /     \    /          \   |
   |_______________|         |_____| TNC |____|  Radio   |__/
   | |  and    |  .  \_____/    \__________/
   |               |         | sl0
   |               | Server  |
   |               |         |   .
   |               |         |     .
   |               \_________/        .
  _|_                                    . . . . . .

# /etc/rc.net
# This configuration provides one KISS based AX.25 port and one
# Ethernet device.

echo "/etc/rc.net"
echo "  Configuring:"

echo -n "    loopback:"
/sbin/ifconfig lo
/sbin/route add
echo " done."

echo -n "    ethernet:"
/sbin/ifconfig eth0 netmask \
		broadcast up
/sbin/route add eth0
/sbin/route add -net netmask eth0
echo " done."

echo -n "    AX.25: "
kissattach -i -m 512 /dev/ttyS1 4800
ifconfig sl0 netmask broadcast
route add -host sl0
route add -net window 1024 sl0

echo -n "    NET/ROM: "
nrattach -i netrom

echo "  Routing:"
/sbin/route add default gw window 1024 sl0
echo "    default route."
echo done.

# end


# name  callsign        speed   paclen  window  description
4800    VK2KTJ-0        4800    256     2       144.800 MHz


# name  callsign        alias   paclen  description
netrom  VK2KTJ-9        LINUX   235     Linux Switch Port


# ax25_name     min_obs def_qual        worst_qual      verbose
4800            1       120             10              1

Note the following:

22.2. IPIP encapsulated gateway configuration

Linux is now very commonly used for TCP/IP encapsulated gateways around the world. The 2.2 and 2.4 kernels provide a new method, making the old ipip configuration obsolete. The ip command contained in the IPROUTE2 package is now the main tool, as described in the Linux 2.4 Advanced Routing HOWTO.

A typical configuration would look similar to the following:

   __________                      _________
  /          \      Internet      /         \
  |          |                    |         |     ______
  |   UCSD   |                    |  Linux  |    /      \
  |          |                    |         |    |      |
  | ampr.org | eth1          eth0 |  IPIP   |    |  PR  |
  |          |____________________|         |____| Node |
  ||                    | Gateway |    |      |
  |          |y.y.y.y      x.x.x.x|         |    |      |
  |          |                    |         |    \______/
  |          |                    |         |
  \__________/                    \_________/

The configuration file for this example is the following:

# /etc/rc.d/rc.tunnel
# This file is a simple configuration that provides the IPIP encapsulation,
# commonly used when utilising the ampr.org ( routing via UCSD.
# The script is located on IPIP gateway with eth0 interface, connected directly
# to the internet and other (e.g. sl0) interface, connected to packet radio
# subnet, e.g. 44.177.155/24.
echo "  Configuring:"
ip tunnel add ucsd remote $IP_eth1 mode ipip
# 'ucsd' is (any suitable) tunnel name
ifconfig ucsd $IP_eth0 up
# tunnel initialisation
ip route add 44/8 dev ucsd via $IP_eth1 onlink
# tells that tunnel should be used when sending packets to ampr.org network
# onlink is the magic word, do not forget
echo " done."
# end.

In any case, the tunnel must be set up on both sides of the route. The tunnelling interface configured above is used for both encapsulation and decapsulation. However, the same principle can be used for one of those tasks, exclusively. When needed, the standard routing (via UCSD), used in previous example, can be avoided by setting the IPIP tunneling between two PR stations, where only one of them has its own internet (public) non-ampr IP address. The task is then to set up the one-way IPIP tunnel, to achieve a quicker and more stable route from non-ampr IP address to ampr IP address station. In this case, the setup, mentioned above, is used for encapsulation. The other side of the route can leave out the route setting, due to its pure decapsulation task.

22.3. AXIP encapsulated gateway configuration

Many Amateur Radio Internet gateways encapsulate AX.25, NET/ROM and ROSE in addition to tcp/ip. Encapsulation of AX.25 frames within IP datagrams is described in RFC-1226 by Brian Kantor. Mike Westerhof wrote an implementation of an AX.25 encapsulation daemon for UNIX in 1991. The ax25-utils package includes a marginally enhanced version of it for Linux.

An AXIP encapsulation program accepts AX.25 frames at one end, looks at the destination AX.25 address to determine what IP address to send them to, encapsulates them in a tcp/ip datagram and then transmits them to the appropriate remote destination. It also accepts tcp/ip datagrams that contain AX.25 frames, unwraps them and processes them as if it had received them directly from an AX.25 port. To distinguish IP datagrams containing AX.25 frames from other IP datagrams which don't, AXIP datagrams are coded with a protocol id of 4 (or 94 which is now deprecated). This process is described in RFC-1226.

The ax25ipd program included in the ax25-utils package presents itself as a program supporting a KISS interface across which you pass AX.25 frames, and an interface into the tcp/ip protocols. It is configured with a single configuration file called /etc/ax25/ax25ipd.conf.

22.3.1. AXIP configuration options

The ax25ipd program has two major modes of operation. "digipeater" mode and "tnc" mode. In "tnc" mode the daemon is treated as though it were a kiss TNC, you pass KISS encapsulated frames to it and it will transmit them, this is the usual configuration. In "digipeater" mode, you treat the daemon as though it were an AX.25 digipeater. There are subtle differences between these modes.

In the configuration file you configure "routes" or mappings between destination AX.25 callsigns and the IP addresses of the hosts that you want to send the AX.25 packets too. Each route has options which will be explained later.

Other options that are configured here are:

  • the tty that the ax25ipd daemon will open and its speed (usually one end of a pipe)

  • what callsign you want to use in "digipeater" mode

  • beacon interval and text

  • whether you want to encapsulate the AX.25 frames in IP datagrams or in UDP/IP datagrams. Nearly all AXIP gateways use IP encapsulation, but some gateways are behind firewalls that will not allow IP with the AXIP protocol id to pass and are forced to use UDP/IP. Whatever you choose must match what the tcp/ip host at the other end of the link is using.

22.3.2. A typical /etc/ax25/ax25ipd.conf file

# ax25ipd configuration file for station floyd.vk5xxx.ampr.org
# Select axip transport. 'ip' is what you want for compatibility
# with most other gateways.
socket ip
# Set ax25ipd mode of operation. (digi or tnc)
mode tnc
# If you selected digi, you must define a callsign. If you selected
# tnc mode, the callsign is currently optional, but this may change
# in the future! (2 calls if using dual port kiss)
#mycall vk5xxx-4
#mycall2 vk5xxx-5
# In digi mode, you may use an alias. (2 for dual port)
#myalias svwdns
#myalias2 svwdn2
# Send an ident every 540 seconds ...
#beacon after 540
#btext ax25ip -- tncmode rob/vk5xxx -- Experimental AXIP gateway
# Serial port, or pipe connected to a kissattach in my case
device /dev/ttyq0
# Set the device speed
speed 9600
# loglevel 0 - no output
# loglevel 1 - config info only
# loglevel 2 - major events and errors
# loglevel 3 - major events, errors, and AX.25 frame trace
# loglevel 4 - all events
# log 0 for the moment, syslog not working yet ...
loglevel 2
# If we are in digi mode, we might have a real tnc here, so use param to
# set the tnc parameters ...
#param 1 20
# Broadcast Address definition. Any of the addresses listed will be forwarded
# to any of the routes flagged as broadcast capable routes.
broadcast QST-0 NODES-0
# ax.25 route definition, define as many as you need.
# format is route (call/wildcard) (ip host at destination)
# ssid of 0 routes all ssid's
# route <destcall> <destaddr> [flags]
# Valid flags are:
#         b  - allow broadcasts to be transmitted via this route
#         d  - this route is the default route
route vk2sut-0 b
route vk5xxx b
route vk2abc

22.3.3. Running ax25ipd

Create your /etc/ax25/axports entry:

# /etc/ax25/axports
axip	VK2KTJ-13	9600	256	AXIP port

Run the kissattach command to create that port:

/usr/sbin/kissattach /dev/ptyq0 axip

Run the ax25ipd program:

/usr/sbin/ax25ipd &

Test the AXIP link:

call axip vk5xxx

22.3.4. Some notes about the routes and route flags

The "route" command is where you specify where you want your AX.25 packets encapsulated and sent to. When the ax25ipd daemon receives a packet from its interface, it compares the destination callsign with each of the callsigns in its routing table. If if finds a match then the ax.25 packet is encapsulated in an IP datagram and then transmitted to the host at the specified IP address.

There are two flags you can add to any of the route commands in the ax25ipd.conf file. The two flags are:


traffic with a destination address matching any of those on the list defined by the "broadcast" keyword should be transmitted via this route.


any packets not matching any route should be transmitted via this route.

The broadcast flag is very useful, as it enables informations that is normally destined for all stations to a number of AXIP destinations. Normally axip routes are point-to-point and unable to handle 'broadcast' packets.

22.4. Linking NOS and Linux using a pipe device

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 via NOS.

Brandon S. Allbery, KF8NH, contributed the following information to explain how to interconnect the NOS running on a Linux machine with the kernel code using the Linux pipe device.

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 choose a pipe device to use. You can find one by looking in your /dev directory. The master end of the pipes are named: ptyq[1-f] and the slave end of the pipes are known as: ttyq[1-f]. Remember they come in pairs, so if you select /dev/ptyqf as your master end then you must use /dev/ttyqf 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/ptyqf &
# /sbin/ifconfig sl0 broadcast pointopoint /
	mtu 1536
# /sbin/route add sl0
# /sbin/route add -net netmask gw

In this example the Linux kernel has been given IP address and the NOS program is using IP address 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 ttyqf - slip linux 1024 1024 38400
route addprivate 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.