mirror of https://github.com/tLDP/LDP
3539 lines
141 KiB
Plaintext
3539 lines
141 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<!-- This is the Linux AX25-HOWTO. It describes how to install and configure
|
|
AX.25 networking support for Linux. Any comments or feedback should
|
|
be directed to the author terry@perf.no.itg.telstra.com.au
|
|
-->
|
|
|
|
<article>
|
|
|
|
<title>Linux AX25-HOWTO, Amateur Radio.
|
|
<author>Terry Dawson, VK2KTJ, <tt>terry@perf.no.itg.telstra.com.au</tt>
|
|
<date>v1.5, 17 October 1997
|
|
|
|
<abstract>
|
|
The Linux Operating System is perhaps the only operating system in the world
|
|
that can boast native and standard support for the AX.25 packet radio protocol
|
|
utilised by Amateur Radio Operators worldwide. This document aims to describe
|
|
how to install and configure this support.
|
|
</abstract>
|
|
|
|
<!-- Table of contents -->
|
|
<toc>
|
|
|
|
<!-- Begin the document -->
|
|
|
|
<sect><heading>Introduction.
|
|
<p>
|
|
This document was originally an appendix to the HAM-HOWTO, but grew too large
|
|
to be reasonably managed in that fashion. This document describes how to
|
|
install and configure the native AX.25, NetRom and Rose support for Linux. A
|
|
few typical configurations are described that could be used as models to work
|
|
from.
|
|
<p>
|
|
The Linux implementation of the amateur radio protocols is very flexible.
|
|
To people relatively unfamiliar with the Linux operating system the
|
|
configuration process may look daunting and complicated. It will take you a
|
|
little time to come to understand how the whole thing fits together. You
|
|
will find configuration very difficult if you have not properly prepared
|
|
yourself by learning about Linux in general. You cannot expect to switch
|
|
from some other environment to Linux without learning about Linux itself.
|
|
|
|
<sect1><heading>Changes from the previous version
|
|
<p>
|
|
<verb>
|
|
Additions:
|
|
Joerg Reuters Web Page
|
|
"More Information" section
|
|
ax25ipd configuration.
|
|
|
|
Corrections/Updates:
|
|
Changed pty's to a safer range to prevent possible conflicts
|
|
Updated module and ax25-utils versions.
|
|
|
|
ToDo:
|
|
Fix up the SCC section, this is probably wrong.
|
|
Expand on the programming section.
|
|
</verb>
|
|
|
|
|
|
<sect1><heading>Where to obtain new versions of this document.
|
|
<p>
|
|
The best place to obtain the latest version of this document is from a
|
|
Linux Documentation Project archive. The Linux Documentation Project runs
|
|
a Web Server and this document appears there as
|
|
<url url="http://sunsite.unc.edu/LDP/HOWTO/AX25-HOWTO.html"
|
|
name="the AX25-HOWTO">. This document is also available in various
|
|
formats from <url url="ftp://sunsite.unc.edu/pub/Linux/docs/howto/"
|
|
name="the sunsite.unc.edu ftp archive">.
|
|
<p>
|
|
You can always contact me, but I pass new
|
|
versions of the document directly to the LDP HOWTO coordinator, so if it
|
|
isn't there then chances are I haven't finished it.
|
|
|
|
<sect1><heading>Other related documentation.
|
|
<p>
|
|
There is a lot of related documentation. There are many documents that relate
|
|
to Linux networking in more general ways and I strongly recommend you also
|
|
read these as they will assist you in your efforts and provide you with
|
|
stronger insight into other possible configurations.
|
|
|
|
They are:
|
|
|
|
<url url="http://sunsite.unc.edu/LDP/HOWTO/HAM-HOWTO.html"
|
|
name="The HAM-HOWTO">,
|
|
|
|
<url url="http://sunsite.unc.edu/LDP/HOWTO/NET-3-HOWTO.html"
|
|
name="the NET-3-HOWTO">,
|
|
|
|
<url url="http://sunsite.unc.edu/LDP/HOWTO/Ethernet-HOWTO.html"
|
|
name="the Ethernet-HOWTO">,
|
|
|
|
and:
|
|
|
|
<url url="http://sunsite.unc.edu/LDP/HOWTO/Firewall-HOWTO.html"
|
|
name="the Firewall-HOWTO">
|
|
<p>
|
|
More general Linux information may be found by reference to other
|
|
<url url="http://sunsite.unc.edu/LDP/HOWTO/" name="Linux HOWTO">
|
|
documents.
|
|
|
|
<sect><heading>The Packet Radio Protocols and Linux.
|
|
<p>
|
|
The <em>AX.25</em> 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.
|
|
<p>
|
|
It is similar to X.25 level 2 in structure, with some extensions to make it
|
|
more useful in the amateur radio environment.
|
|
<p>
|
|
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. The NetRom protocol features dynamic routing and
|
|
node aliases.
|
|
<p>
|
|
The Rose protocol was conceived and first implemented by Tom Moulton W2VY and
|
|
is an implementation of the X.25 packet layer protocol and is designed to
|
|
operate with AX.25 as its datalink layer protocol. It too provides a network
|
|
layer. Rose addresses take the form of 10 digit numbers. The first four digits
|
|
are called the Data Network Identification Code (DNIC) and are taken from
|
|
Appendix B of the CCITT X.121 recommendation. More information on the Rose
|
|
protocol may be ontained from the
|
|
<url url="http://www.rats.org/" name="RATS Web server">.
|
|
<p>
|
|
Alan Cox developed some early kernel based AX.25 software support for Linux.
|
|
Jonathon Naylor <tt><g4klx@g4klx.demon.co.uk></tt> has taken up ongoing
|
|
development of the code, has added NetRom and Rose support and is now the
|
|
developer of the AX.25 related kernel code. DAMA support was developed by
|
|
Joerg, DL1BKE, <tt/jreuter@poboxes.com/. Baycom and SoundModem support
|
|
were added by Thomas Sailer, <tt><sailer@ife.ee.ethz.ch></tt>. The AX.25
|
|
utility software is now maintained by me.
|
|
<p>
|
|
The Linux code supports KISS based TNC's (Terminal Node Controllers),
|
|
the Ottawa PI card, the Gracilis PacketTwin card and other Z8530 SCC based
|
|
cards with the generic SCC driver and both the Parallel and Serial port Baycom
|
|
modems. Thomas's new soundmodem driver supports Soundblaster and soundcards
|
|
based on the Crystal chipset.
|
|
<p>
|
|
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.
|
|
|
|
<sect1><heading>How it all fits together.
|
|
<p>
|
|
The Linux AX.25 implementation is a brand new implementation. While in many
|
|
ways it may looks similar to NOS, or BPQ or other AX.25 implementations, it
|
|
is none of these and is not identical to any of them. The Linux AX.25
|
|
implementation is capable of being configured to behave almost identically
|
|
to other implementations, but the configuration process is very different.
|
|
<p>
|
|
To assist you in understanding how you need to think when configuring this
|
|
section describes some of the structural features of the AX.25 implementation
|
|
and how it fits into the context of the overall Linux structure.
|
|
|
|
<bf><em>Simplified Protocol Layering Diagram</em></bf>
|
|
<tscreen><verb>
|
|
-----------------------------------------------
|
|
| AF_AX25 | AF_NETROM | AF_INET | AF_ROSE |
|
|
|=========|===========|=============|=========|
|
|
| | | | |
|
|
| | | TCP/IP | |
|
|
| | ---------- | |
|
|
| | NetRom | | Rose |
|
|
| -------------------------------------
|
|
| AX.25 |
|
|
-----------------------------------------------
|
|
</verb></tscreen>
|
|
|
|
This diagram simply illustrates that NetRom, Rose and TCP/IP all run directly
|
|
on top of AX.25, but that each of these protocols is treated as a seperate
|
|
protocol at the programming interface. The `<tt>AF_</tt>' names are
|
|
simply the names given to the `<em>Address Family</em>' of each of these
|
|
protocols when writing programs to use them. The important thing to note here
|
|
is the implicit dependence on the configuration of your AX.25 devices before
|
|
you can configure your NetRom, Rose or TCP/IP devices.
|
|
|
|
<p>
|
|
<bf><em>Software module diagram of Linux Network Implementation</em></bf>
|
|
<verb>
|
|
----------------------------------------------------------------------------
|
|
User | Programs | call node || Daemons | ax25d mheardd
|
|
| | pms mheard || | inetd netromd
|
|
----------------------------------------------------------------------------
|
|
| Sockets | open(), close(), listen(), read(), write(), connect()
|
|
| |------------------------------------------------------
|
|
| | AF_AX25 | AF_NETROM | AF_ROSE | AF_INET
|
|
|------------------------------------------------------------------
|
|
Kernel | Protocols | AX.25 | NetRom | Rose | IP/TCP/UDP
|
|
|------------------------------------------------------------------
|
|
| Devices | ax0,ax1 | nr0,nr1 | rose0,rose1 | eth0,ppp0
|
|
|------------------------------------------------------------------
|
|
| Drivers | Kiss PI2 PacketTwin SCC BPQ | slip ppp
|
|
| | Soundmodem Baycom | ethernet
|
|
----------------------------------------------------------------------------
|
|
Hardware | PI2 Card, PacketTwin Card, SCC card, Serial port, Ethernet Card
|
|
----------------------------------------------------------------------------
|
|
</verb>
|
|
This diagram is a little more general than the first. This diagram attempts to
|
|
show the relationship between user applications, the kernel and the hardware.
|
|
It also shows the relationship between the Socket application programming
|
|
interface, the actual protocol modules, the kernel networking devices and the
|
|
device drivers. Anything in this diagram is dependent on anything underneath
|
|
it, and in general you must configure from the bottom of the diagram upwards.
|
|
So for example, if you want to run the <em>call</em> program you must also
|
|
configure the Hardware, then ensure that the kernel has the appropriate device
|
|
driver, that you create the appropriate network device, that the kernel
|
|
includes the desired protocol that presents a programming interface that the
|
|
<em>call</em> program can use. I have attempted to lay out this document in
|
|
roughly that order.
|
|
|
|
<sect><heading>The AX.25/NetRom/Rose software components.
|
|
<p>
|
|
The AX.25 software is comprised of three components, the kernel source, the
|
|
network configuration tools and the utility programs.
|
|
|
|
The version 2.0.xx Linux kernels include the AX.25, NetRom, Z8530 SCC,
|
|
PI card and PacketTwin drivers by default. These have been significantly
|
|
enhanced in the 2.1.* kernels. Unfortunately, the rest of the 2.1.*
|
|
kernels makes them fairly unstable at the moment and not a good choice
|
|
for a production system. To solve this problem Jonathon Naylor has prepared
|
|
a patch kit which will bring the amateur radio protocol support in a 2.0.28
|
|
kernel up to the standard of the 2.1.* kernels. This is very simple to apply,
|
|
and provides a range of facilities not present in the standard kernel such
|
|
as Rose support.
|
|
|
|
<sect1><heading>Finding the kernel, tools and utility packages.
|
|
<p>
|
|
|
|
<sect2><heading>The kernel source:
|
|
<p>
|
|
The kernel source can be found in its usual place at:
|
|
<bf>ftp.kernel.org</bf>
|
|
<tscreen><verb>
|
|
/pub/linux/kernel/v2.0/linux-2.0.31.tar.gz
|
|
</verb></tscreen>
|
|
|
|
The current version of the AX25 upgrade patch is available at:
|
|
<bf>ftp.pspt.fi</bf>
|
|
<tscreen<verb>
|
|
/pub/linux/ham/ax25/ax25-module-14e.tar.gz
|
|
</verb></tscreen>
|
|
|
|
<sect2><heading>The network tools:
|
|
<p>
|
|
The latest alpha release of the standard Linux network tools support
|
|
AX.25 and NetRom and can be found at:
|
|
<bf>ftp.inka.de</bf>
|
|
<tscreen><verb>
|
|
/pub/comp/Linux/networking/net-tools/net-tools-1.33.tar.gz
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
The latest ipfwadm package can be found at:
|
|
<bf>ftp.xos.nl</bf>
|
|
<tscreen><verb>
|
|
/pub/linux/ipfwadm/
|
|
</verb></tscreen>
|
|
|
|
<sect2><heading>The AX25 utilities:
|
|
<p>
|
|
There are two different families of AX25-utilities. One is for the
|
|
<tt>2.0.*</tt> kernels and the other will work with either the <tt>2.1.*</tt>
|
|
kernels or the <tt>2.0.*+moduleXX</tt> kernels. The ax25-utils version number
|
|
indicates the oldest version of kernel that they will work with. Please choose
|
|
a version of the ax25-utils appropriate to your kernel. The following are
|
|
working combinations. You <bf>must</bf> use one of the following combinations,
|
|
any other combination will not work, or will not work well.
|
|
|
|
<tscreen><verb>
|
|
Linux Kernel AX25 Utility set
|
|
---------------------- -------------------------
|
|
linux-2.0.29 ax25-utils-2.0.12c.tar.gz **
|
|
linux-2.0.28+module12 ax25-utils-2.1.22b.tar.gz **
|
|
linux-2.0.30+module14c ax25-utils-2.1.42a.tar.gz
|
|
linux-2.0.31+module14d ax25-utils-2.1.42a.tar.gz
|
|
linux-2.1.22 ++ ax25-utils-2.1.22b.tar.gz
|
|
linux-2.1.42 ++ ax25-utils-2.1.42a.tar.gz
|
|
</verb></tscreen>
|
|
|
|
<bf>Note</bf>: the <tt>ax25-utils-2.0.*</tt> series (marked above with
|
|
the '<tt>**</tt>' symbol) is now obsolete and is no longer supported. This
|
|
document covers configuration using the versions of software recommended
|
|
above the table. While there are differences between the releases, most of
|
|
the information will be relevant to earlier releases of code.
|
|
|
|
The AX.25 utility programs can be found at:
|
|
<url url="ftp://ftp.pspt.fi/pub/linux/ham/ax25/" name="ftp.pspt.fi">
|
|
|
|
or at:
|
|
<url url="ftp://sunsite.unc.edu/pub/Linux/apps/ham/" name="sunsite.unc.edu">
|
|
|
|
<sect><heading>Installing the AX.25/NetRom/Rose software.
|
|
<p>
|
|
To successfully install AX.25 support on your linux system you must configure
|
|
and install an appropriate kernel and then install the AX.25 utilities.
|
|
|
|
<sect1><heading>Compiling the kernel.
|
|
<p>
|
|
If you are already familiar with the process of compiling the Linux Kernel
|
|
then you can skip this section, just be sure to select the appropriate options
|
|
when compiling the kernel. If you are not, then read on.
|
|
<p>
|
|
The normal place for the kernel source to be unpacked to is the
|
|
<tt>/usr/src</tt> directory into a subdirectory called <tt>linux</tt>.
|
|
To do this you should be logged in as <tt>root</tt> and execute a series
|
|
of commands similar to the following:
|
|
|
|
<tscreen><verb>
|
|
# mv linux linux.old
|
|
# cd /usr/src
|
|
# tar xvfz linux-2.0.31.tar.gz
|
|
# tar xvfz /pub/net/ax25/ax25-module-14e.tar.gz
|
|
# patch -p0 &etago;usr/src/ax25-module-14/ax25-2.0.31-2.1.47-2.diff
|
|
# cd linux
|
|
</verb></tscreen>
|
|
|
|
After you have unpacked the kernel source and applied the upgrade, you need
|
|
to run the configuration script and choose the options that suit your hardware
|
|
configuration and the options that you wish built into your kernel.
|
|
You do this by using the command:
|
|
|
|
<tscreen><verb>
|
|
# make menuconfig
|
|
</verb></tscreen>
|
|
|
|
You might also try:
|
|
|
|
<tscreen><verb>
|
|
# make config
|
|
</verb></tscreen>
|
|
|
|
I'm going to describe the full screen method (menuconfig) because it is easier
|
|
to move around, but you use whichever you are most comfortable with.
|
|
|
|
In either case you will be offered a range of options at which you must
|
|
answer `Y' or `N'. (Note you may also answer `M' if you are using modules.
|
|
For the sake of simplicity I will assume you are not, please make appropriate
|
|
modifications if you are).
|
|
|
|
The options most relevant to an AX.25 configuration are:
|
|
|
|
<verb>
|
|
Code maturity level options --->
|
|
...
|
|
[*] Prompt for development and/or incomplete code/drivers
|
|
...
|
|
General setup --->
|
|
...
|
|
[*] Networking support
|
|
...
|
|
Networking options --->
|
|
...
|
|
[*] TCP/IP networking
|
|
[?] IP: forwarding/gatewaying
|
|
...
|
|
[?] IP: tunneling
|
|
...
|
|
[?] IP: Allow large windows (not recommended if <16Mb of memory)
|
|
...
|
|
[*] Amateur Radio AX.25 Level 2
|
|
[?] Amateur Radio NET/ROM
|
|
[?] Amateur Radio X.25 PLP (Rose)
|
|
...
|
|
Network device support --->
|
|
[*] Network device support
|
|
...
|
|
[*] Radio network interfaces
|
|
[?] BAYCOM ser12 and par96 driver for AX.25
|
|
[?] Soundcard modem driver for AX.25
|
|
[?] Soundmodem support for Soundblaster and compatible cards
|
|
[?] Soundmodem support for WSS and Crystal cards
|
|
[?] Soundmodem support for 1200 baud AFSK modulation
|
|
[?] Soundmodem support for 4800 baud HAPN-1 modulation
|
|
[?] Soundmodem support for 9600 baud FSK G3RUH modulation
|
|
[?] Serial port KISS driver for AX.25
|
|
[?] BPQ Ethernet driver for AX.25
|
|
[?] Gracilis PackeTwin support for AX.25
|
|
[?] Ottawa PI and PI/2 support for AX.25
|
|
[?] Z8530 SCC KISS emulation driver for AX.25
|
|
...
|
|
</verb>
|
|
|
|
The options I have flagged with a `<tt/*/' are those that you <bf/must/ must
|
|
answer `Y' to. The rest are dependent on what hardware you have and what
|
|
other options you want to include. Some of these options are described in more
|
|
detail later on, so if you don't know what you want yet, then read ahead
|
|
and come back to this step later.
|
|
<p>
|
|
After you have completed the kernel configuration you should be able to
|
|
cleanly compile your new kernel:
|
|
|
|
<tscreen><verb>
|
|
# make dep
|
|
# make clean
|
|
# make zImage
|
|
</verb></tscreen>
|
|
|
|
maake sure you move your <tt>arch/i386/boot/zImage</tt> file wherever you
|
|
want it and then edit your <tt>/etc/lilo.conf</tt> file and rerun <em>lilo</em>
|
|
to ensure that you actually boot from it.
|
|
<p>
|
|
<sect2>A word about Kernel modules
|
|
<p>
|
|
I recommend that you <bf>don't</bf> compile any of the drivers as modules. In
|
|
nearly all installations you gain nothing but additional complexity. Many
|
|
people have problems trying to get the modularised components working, not
|
|
because the software is faulty but because modules are more complicated to
|
|
install and configure.
|
|
<p>
|
|
If you've chosen to compile any of the components as modules, then you'll
|
|
also need to use:
|
|
|
|
<tscreen><verb>
|
|
# make modules
|
|
# make modules_install
|
|
</verb></tscreen>
|
|
to install your modules in the appropriate location.
|
|
<p>
|
|
You will also need to add some entries into your <tt>/etc/conf.modules</tt>
|
|
file that will ensure that the <em/kerneld/ program knows how to handle the
|
|
kernel modules. You should add/modify the following:
|
|
|
|
<tscreen><verb>
|
|
alias net-pf-3 ax25
|
|
alias net-pf-6 netrom
|
|
alias net-pf-11 rose
|
|
alias tty-ldisc-1 slip
|
|
alias tty-ldisc-3 ppp
|
|
alias tty-ldisc-5 mkiss
|
|
alias bc0 baycom
|
|
alias nr0 netrom
|
|
alias pi0a pi2
|
|
alias pt0a pt
|
|
alias scc0 optoscc (or one of the other scc drivers)
|
|
alias sm0 soundmodem
|
|
alias tunl0 newtunnel
|
|
alias char-major-4 serial
|
|
alias char-major-5 serial
|
|
alias char-major-6 lp
|
|
</verb></tscreen>
|
|
|
|
<sect2>What's new in 2.0.*+ModuleXX or 2.1.* Kernels ?
|
|
<p>
|
|
The <tt/2.1.*/ kernels have enhanced versions of nearly all of the protocols
|
|
and drivers. The most significant of the enhancements are:
|
|
<descrip>
|
|
<tag>modularised</tag>the protocols and drivers have all been modularised so
|
|
that you can <em/insmod/ and <em/rmmod/ them whenever you wish. This reduces
|
|
the kernel memory requirements for infrequently used modules and makes
|
|
development and bug hunting much simpler. That being said, it also makes
|
|
configuration slightly more difficult.
|
|
<tag>All drivers are now network drivers</tag>all of the network devices such
|
|
as Baycom, SCC, PI, Packettwin etc now present a normal network interface, that
|
|
is they now look like the ethernet driver does, they no longer look like KISS
|
|
TNC's. A new utility called <em/net2kiss/ allows you to build a kiss interface
|
|
to these devices if you wish.
|
|
<tag>bug fixed</tag>there have been many bug fixes and new features added to
|
|
the drivers and protocols. The Rose protocol is one important addition.
|
|
</descrip>
|
|
|
|
<sect1><heading>The network configuration tools.
|
|
<p>
|
|
Now that you have compiled the kernel you should compile the new network
|
|
configuration tools. These tools allow you to modify the configuration of
|
|
network devices and to add routes to the routing table.
|
|
<p>
|
|
The new alpha release of the standard <tt>net-tools</tt> package includes
|
|
support for AX.25 and NetRom support. I've tested this and it seems to
|
|
work well for me.
|
|
|
|
<sect2><heading>A patch kit that adds Rose support and fixes some bugs.
|
|
<p>
|
|
The standard net-tools-1.33.tar.gz package has some small bugs that affect
|
|
the AX.25 and NetRom support. I've made a small patch kit that corrects these
|
|
and adds Rose support to the tools as well.
|
|
<p>
|
|
You can get the patch from:
|
|
<url url="ftp://zone.pspt.fi/pub/linux/ham/ax25/net-tools-1.33.rose.tjd.diff.gz"
|
|
name="zone.pspt.fi">.
|
|
|
|
|
|
<sect2><heading>Building the standard net-tools release.
|
|
<p>
|
|
Don't forget to read the <tt>Release</tt> file and follow any instructions
|
|
there. The steps I used to compile the tools were:
|
|
|
|
<tscreen><verb>
|
|
# cd /usr/src
|
|
# tar xvfz net-tools-1.33.tar.gz
|
|
# zcat net-tools-1.33.rose.tjd.diff.gz | patch -p0
|
|
# cd net-tools-1.33
|
|
# make config
|
|
</verb></tscreen>
|
|
|
|
At this stage you will be presented with a series of configuration questions,
|
|
similar to the kernel configuration questions. Be sure to include support for
|
|
all of the protocols and network devices types that you intend to use. If you
|
|
do not know how to answer a particular question then answer `Y'.
|
|
<p>
|
|
When the compilation is complete, you should use the:
|
|
|
|
<tscreen><verb>
|
|
# make install
|
|
</verb></tscreen>
|
|
|
|
command to install the programs in their proper place.
|
|
|
|
<p>
|
|
If you wish to use the IP firewall facilities then you will need the latest
|
|
firewall administration tool <tt>ipfwadm</tt>. This tool replaces the older
|
|
<tt>ipfw</tt> tool which will not work with new kernels.
|
|
<p>
|
|
I compiled the <tt>ipfwadm</tt> utility with the following commands:
|
|
<tscreen><verb>
|
|
# cd /usr/src
|
|
# tar xvfz ipfwadm-2.0beta2.tar.gz
|
|
# cd ipfwadm-2.0beta2
|
|
# make install
|
|
# cp ipfwadm.8 /usr/man/man8
|
|
# cp ipfw.4 /usr/man/man4
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading>The AX.25 user and utility programs.
|
|
<p>
|
|
After you have successfully compiled and booted your new kernel, you need to
|
|
compile the user programs. To compile and install the user programs you should
|
|
use a series of commands similar to the following:
|
|
|
|
<tscreen><verb>
|
|
# cd /usr/src
|
|
# tax xvfz ax25-utils-2.1.42a.tar.gz
|
|
# cd ax25-utils-2.1.42a
|
|
# make config
|
|
# make
|
|
# make install
|
|
</verb></tscreen>
|
|
|
|
The files will be installed under the <tt>/usr</tt> directory by default
|
|
in subdirectories: <tt/bin/, <tt/sbin/, <tt/etc/ and <tt/man/.
|
|
<p>
|
|
If this is a first time installation, that is you've never installed any
|
|
ax25 utilities on your machine before you should also use the:
|
|
<tscreen><verb>
|
|
# make installconf
|
|
</verb></tscreen>
|
|
|
|
command to install some sample configuration files into the <tt>/etc/ax25/</tt>
|
|
directory from which to work.
|
|
|
|
<p>
|
|
If you get messages something like:
|
|
<verb>
|
|
gcc -Wall -Wstrict-prototypes -O2 -I../lib -c call.c
|
|
call.c: In function `statline':
|
|
call.c:268: warning: implicit declaration of function `attron'
|
|
call.c:268: `A_REVERSE' undeclared (first use this function)
|
|
call.c:268: (Each undeclared identifier is reported only once
|
|
call.c:268: for each function it appears in.)
|
|
</verb>
|
|
|
|
then you should double check that you have the <em>ncurses</em> package
|
|
properly installed on your system. The configuration script attempts
|
|
to locate your ncurses packages in the common locations, but
|
|
some installations have ncurses badly installed and it is unable
|
|
to locate them.
|
|
|
|
<sect><heading>A note on callsigns, addresses and things before we start.
|
|
<p>
|
|
Each AX.25 and NetRom port on your system must have a callsign/ssid allocated
|
|
to it. These are configured in the configuration files that will be described
|
|
in detail later on.
|
|
<p>
|
|
Some AX.25 implementations such as NOS and BPQ will allow you to configure
|
|
the same callsign/ssid on each AX.25 and NetRom port. For somewhat complicated
|
|
technical reasons Linux does not allow this. This isn't as big a problem in
|
|
practise as it might seem.
|
|
<p>
|
|
This means that there are things you should be aware of and take into
|
|
consideration when doing your configurations.
|
|
<p>
|
|
<enum>
|
|
<item>Each AX.25 and NetRom port must be configured with a unique callsign/ssid.
|
|
<item>TCP/IP will use the callsign/ssid of the AX.25 port it is being
|
|
transmitted or received by, ie the one you configured for the AX.25 interface
|
|
in point 1.
|
|
<item>NetRom will use the callsign/ssid specified for it in its configuration
|
|
file, but this callsign is only used when your NetRom is speaking to another
|
|
NetRom, this is <bf/not/ the callsign/ssid that AX.25 users who wish to use
|
|
your NetRom `node' will use. More on this later.
|
|
<item>Rose will, by default, use the callsign/ssid of the AX.25 port, unless
|
|
the Rose callsign has been specifically set using the `<em/rsparms/' command.
|
|
If you set a callsign/ssid using the `<em/rsparms/' command then Rose will
|
|
use this callsign/ssid on all ports.
|
|
<item>Other programs, such as the `<em/ax25d/' program can listen using
|
|
any callsign/ssid that they wish and these may be duplicated across different
|
|
ports.
|
|
<item>If you are careful with routing you can configure the same IP address on
|
|
all ports if you wish.
|
|
</enum>
|
|
|
|
<sect1><heading>What are all those T1, T2, N2 and things ?
|
|
<p>
|
|
Not every AX.25 implementation is a TNC2. Linux uses nomenclature that
|
|
differs in some respects from that you will be used to if your sole
|
|
experience with packet is a TNC. The following table should help you
|
|
interpret what each of the configurable items are, so that when you come
|
|
across them later in this text you'll understand what they mean.
|
|
|
|
<tscreen><verb>
|
|
-------------------------------------------------------------------
|
|
Linux | TAPR TNC | Description
|
|
-------------------------------------------------------------------
|
|
T1 | FRACK | How long to wait before retransmitting an
|
|
| | unacknowledged frame.
|
|
-------------------------------------------------------------------
|
|
T2 | RESPTIME | The minimum amount of time to wait for another
|
|
| | frame to be received before transmitting
|
|
| | an acknowledgement.
|
|
-------------------------------------------------------------------
|
|
T3 | CHECK | The period of time we wait between sending
|
|
| | a check that the link is still active.
|
|
-------------------------------------------------------------------
|
|
N2 | RETRY | How many times to retransmit a frame before
|
|
| | assuming the connection has failed.
|
|
-------------------------------------------------------------------
|
|
Idle | | The period of time a connection can be idle
|
|
| | before we close it down.
|
|
-------------------------------------------------------------------
|
|
Window | MAXFRAME | The maximum number of unacknowledged
|
|
| | transmitted frames.
|
|
-------------------------------------------------------------------
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading>Run time configurable parameters
|
|
<p>
|
|
The <tt/2.1.*/ and <tt/2.0.* +moduleXX/ kernels have a new feature that allows
|
|
you to change many previously unchangable parameters at run time. If you take a
|
|
careful look at the <tt>/proc/sys/net/</tt> directory structure you will see
|
|
many files with useful names that describe various parameters for the network
|
|
configuration. The files in the <tt>/proc/sys/net/ax25/</tt> directory each
|
|
represents one configured AX.25 port. The name of the file relates to the
|
|
name of the port.
|
|
|
|
The structure of the files in <tt>/proc/sys/net/ax25/<portname>/</tt>
|
|
is as follows:
|
|
<verb>
|
|
FileName Meaning Values Default
|
|
ip_default_mode IP Default Mode 0=DG 1=VC 0
|
|
ax25_default_mode AX.25 Default Mode 0=Normal 1=Extended 0
|
|
backoff_type Backoff 0=Linear 1=Exponential 1
|
|
connect_mode Connected Mode 0=No 1=Yes 1
|
|
standard_window_size Standard Window 1 <= N <= 7 2
|
|
extended_window_size Extended Window 1 <= N <= 63 32
|
|
t1_timeout T1 Timeout 1s <= N <= 30s 10s
|
|
t2_timeout T2 Timeout 1s <= N <= 20s 3s
|
|
t3_timeout T3 Timeout 0s <= N <= 3600s 300s
|
|
idle_timeout Idle Timeout 0m <= N 20m
|
|
maximum_retry_count N2 1 <= N <= 31 10
|
|
maximum_packet_length AX.25 Frame Length 1 <= N <= 512 256
|
|
</verb>
|
|
In the table T1, T2 and T3 are given in seconds, and the Idle Timeout
|
|
is given in minutes. But please note that the values used in the sysctl
|
|
interface are given in internal units where the time in seconds is
|
|
multiplied by 10, this allows resolution down to 1/10 of a second. With
|
|
timers that are allowed to be zero, eg T3 and Idle, a zero value indicates
|
|
that the timer is disabled.
|
|
|
|
<p>
|
|
The structure of the files in <tt>/proc/sys/net/netrom/</tt>
|
|
is as follows:
|
|
<verb>
|
|
FileName Values Default
|
|
default_path_quality 10
|
|
link_fails_count 2
|
|
network_ttl_initialiser 16
|
|
obsolescence_count_initialiser 6
|
|
routing_control 1
|
|
transport_acknowledge_delay 50
|
|
transport_busy_delay 1800
|
|
transport_maximum_tries 3
|
|
transport_requested_window_size 4
|
|
transport_timeout 1200
|
|
</verb>
|
|
|
|
<p>
|
|
The structure of the files in <tt>/proc/sys/net/rose/</tt>
|
|
is as follows:
|
|
<verb>
|
|
FileName Values Default
|
|
acknowledge_hold_back_timeout 50
|
|
call_request_timeout 2000
|
|
clear_request_timeout 1800
|
|
link_fail_timeout 1200
|
|
maximum_virtual_circuits 50
|
|
reset_request_timeout 1800
|
|
restart_request_timeout 1800
|
|
routing_control 1
|
|
window_size 3
|
|
</verb>
|
|
|
|
<p>
|
|
To set a parameter all you need to do is write the desired value to the file
|
|
itself, for example to check and set the Rose window size you'd use something
|
|
like:
|
|
<tscreen><verb>
|
|
# cat /proc/sys/net/rose/window_size
|
|
3
|
|
# echo 4 >/proc/sys/net/rose/window_size
|
|
# cat /proc/sys/net/rose/window_size
|
|
4
|
|
</verb></tscreen>
|
|
|
|
<sect><heading>Configuring an AX.25 port.
|
|
<p>
|
|
Each of the AX.25 applications read a particular configuration file to obtain
|
|
the parameters for the various AX.25 ports configured on your Linux machine.
|
|
For AX.25 ports the file that is read is the <tt>/etc/ax25/axport</tt> file.
|
|
You must have an entry in this file for each AX.25 port you want on your
|
|
system.
|
|
|
|
<sect1><heading>Creating the AX.25 network device.
|
|
<p>
|
|
The network device is what is listed when you use the `<em/ifconfig/'
|
|
command. This is the object that the Linux kernel sends and receives network
|
|
data from. Nearly always the network device has a physical port associated
|
|
with it, but there are occasions where this isn't necessary. The network
|
|
device does relate directly to a device driver.
|
|
<p>
|
|
In the Linux AX.25 code there are a number of device drivers. The most common
|
|
is probably the KISS driver, but others are the SCC driver(s), the Baycom
|
|
driver and the SoundModem driver.
|
|
<p>
|
|
Each of these device drivers will create a network device when it is started.
|
|
|
|
<sect2><heading>Creating a KISS device.
|
|
<p>
|
|
<bf/Kernel Compile Options/:
|
|
<tscreen><verb>
|
|
General setup --->
|
|
[*] Networking support
|
|
Network device support --->
|
|
[*] Network device support
|
|
...
|
|
[*] Radio network interfaces
|
|
[*] Serial port KISS driver for AX.25
|
|
</verb></tscreen>
|
|
|
|
Probably the most common configuration will be for a KISS TNC on a serial port.
|
|
You will need to have the TNC preconfigured and connected to your serial port.
|
|
You can use a communications program like <em>minicom</em> or <em>seyon</em>
|
|
to configure the TNC into kiss mode.
|
|
<p>
|
|
To create a KISS device you use the <em/kissattach/ program. In it simplest
|
|
form you can use the <em/kissattach/ program as follows:
|
|
|
|
<tscreen><verb>
|
|
# /usr/sbin/kissattach /dev/ttyS0 radio
|
|
# kissparms -p radio -t 100 -s 100 -r 25
|
|
</verb></tscreen>
|
|
|
|
The <em/kissattach/ command will create a KISS network device. These devices
|
|
are called `<tt/ax[0-9]/'. The first time you use the <em/kissattach/ command
|
|
it creates `<tt/ax0/', the second time it creates `<tt/ax1/' etc. Each KISS
|
|
device has an associated serial port.
|
|
<p>
|
|
The <em/kissparms/ command allows you to set various KISS parameters on a KISS
|
|
device.
|
|
<p>
|
|
Specifically the example presented would create a KISS network device using
|
|
the serial device `<tt>/dev/ttyS0</tt>' and the entry from the
|
|
<tt>/etc/ax25/axports</tt> with a port name of `<tt/radio/'. It then configures
|
|
it with a <em/txdelay/ and <em/slottime/ of 100 milliseconds and a <em/ppersist/
|
|
value of 25.
|
|
<p>
|
|
Please refer to the <em/man/ pages for more information.
|
|
|
|
<sect3><heading>Configuring for Dual Port TNC's
|
|
<p>
|
|
The <em/mkiss/ utility included in the ax25-utils distribution allows you to
|
|
make use of both modems on a dual port TNC. Configuration is fairly
|
|
simple. It works by taking a single serial device connected to a single
|
|
multiport TNC and making it look like a number of devices each connected to
|
|
a single port TNC. You do this <bf/before/ you do any of the AX.25
|
|
configuration. The devices that you then do the AX.25 configuration on
|
|
are pseudo-TTY interfaces, (<tt>/dev/ttyq*</tt>), and not the actual
|
|
serial device. Pseudo-TTY devices create a kind of pipe through which
|
|
programs designed to talk to tty devices can talk to other programs designed
|
|
to talk to tty devices. Each pipe has a master and a slave end. The master
|
|
end is generally called `<tt>/dev/ptyq*</tt>' and the slave ends are called
|
|
`<tt>/dev/ttyq*</tt>'. There is a one to one relationship between masters and
|
|
slaves, so <tt>/dev/ptyq0</tt> is the master end of a pipe with
|
|
<tt>/dev/ttyq0</tt> as its slave. You must open the master end of a pipe
|
|
before opening the slave end. <em/mkiss/ exploits this mechanism to split
|
|
a single serial device into seperate devices.
|
|
|
|
<p>
|
|
Example: if you have a dual port tnc and it is connected to your
|
|
<tt>/dev/ttyS0</tt> serial device at 9600 bps, the command:
|
|
|
|
<tscreen><verb>
|
|
# /usr/sbin/mkiss -s 9600 /dev/ttyS0 /dev/ptyq0 /dev/ptyq1
|
|
# /usr/sbin/kissattach /dev/ttyq0 port1
|
|
# /usr/sbin/kissattach /dev/ttyq1 port2
|
|
</verb></tscreen>
|
|
|
|
would create two pseudo-tty devices that each look like a normal single port
|
|
TNC. You would then treat <tt>/dev/ttyq0</tt> and <tt>/dev/ttyq1</tt> just as
|
|
you would a conventional serial device with TNC connected. This means you'd
|
|
then use the <em/kissattach/ command as described above, on each of those,
|
|
in the example for AX.25 ports called <tt/port1/ and <tt/port2/. You shouldn't
|
|
use <em/kissattach/ on the actual serial device as the <em/mkiss/ program uses
|
|
it.
|
|
<p>
|
|
The <em/mkiss/ command has a number of optional arguments that you may wish
|
|
to use. They are summarised as follows:
|
|
<descrip>
|
|
<tag>-c</tag>enables the addition of a one byte checksum to each KISS frame.
|
|
This is not supported by most KISS implementation, it is supported by the
|
|
G8BPG KISS rom.
|
|
<tag>-s <speed></tag>sets the speed of the serial port.
|
|
<tag>-h</tag>enables hardware handshaking on the serial port, it is off by
|
|
default. Most KISS implementation do not support this, but some do.
|
|
<tag>-l</tag>enables logging of information to the <em/syslog/ logfile.
|
|
</descrip>
|
|
|
|
<sect2><heading>Creating a Baycom device.
|
|
<p>
|
|
<bf/Kernel Compile Options/:
|
|
<tscreen><verb>
|
|
Code maturity level options --->
|
|
[*] Prompt for development and/or incomplete code/drivers
|
|
General setup --->
|
|
[*] Networking support
|
|
Network device support --->
|
|
[*] Network device support
|
|
...
|
|
[*] Radio network interfaces
|
|
[*] BAYCOM ser12 and par96 driver for AX.25
|
|
</verb></tscreen>
|
|
|
|
Thomas Sailer, <tt><sailer@ife.ee.ethz.ch></tt>, despite the popularly
|
|
held belief that it would not work very well, has developed Linux support for
|
|
Baycom modems. His driver supports the <tt>Ser12</tt> serial port,
|
|
<tt>Par96</tt> and the enhanced <tt>PicPar</tt> parallel port modems.
|
|
Further information about the modems themselves may be obtained from the
|
|
<url url="http://www.baycom.de/" name="Baycom Web site">.
|
|
<p>
|
|
Your first step should be to determine the i/o and addresses of the
|
|
serial or parallel port(s) you have Baycom modem(s) connected to.
|
|
When you have these you must configure the Baycom driver with them.
|
|
<p>
|
|
The BayCom driver creates network devices called:
|
|
<tt/bc0/, <tt/bc1/, <tt/bc2/ etc. when it is configured.
|
|
<p>
|
|
The <em/sethdlc/ utility allows you to configure the driver with these
|
|
parameters, or, if you have only one Baycom modem installed you may specify
|
|
the parameters on the <em/insmod/ commmand line when you load the
|
|
Baycom module.
|
|
<p>
|
|
For example, a simple configuration.
|
|
Disable the serial driver for COM1: then configure the Baycom driver for a
|
|
Ser12 serial port modem on COM1: with the software DCD option enabled:
|
|
<tscreen><verb>
|
|
# setserial /dev/ttyS0 uart none
|
|
# insmod hdlcdrv
|
|
# insmod baycom mode="ser12*" iobase=0x3f8 irq=4
|
|
</verb></tscreen>
|
|
|
|
Par96 parallel port type modem on LPT1: using hardware DCD detection:
|
|
<tscreen><verb>
|
|
# insmod hdlcdrv
|
|
# insmod baycom mode="par96" iobase=0x378 irq=7 options=0
|
|
</verb></tscreen>
|
|
|
|
This is not really the preferred way to do it. The <em/sethdlc/ utility
|
|
works just as easily with one device as with many.
|
|
<p>
|
|
The <em/sethdlc/ <em/man/ page has the full details, but a couple of examples
|
|
will illustrate the most important aspects of this configuration. The
|
|
following examples assume you have already loaded the Baycom module
|
|
using:
|
|
<tscreen><verb>
|
|
# insmod hdlcdrv
|
|
# insmod baycom
|
|
</verb></tscreen>
|
|
or that you compiled the kernel with the driver inbuilt.
|
|
<p>
|
|
Configure the <tt/bc0/ device driver as a Parallel port Baycom modem on LPT1:
|
|
with software DCD:
|
|
<tscreen><verb>
|
|
# sethdlc -p -i bc0 mode par96 io 0x378 irq 7
|
|
</verb></tscreen>
|
|
|
|
Configure the <tt/bc1/ device driver as a Serial port Baycom modem on COM1:
|
|
<tscreen><verb>
|
|
# sethdlc -p -i bc1 mode "ser12*" io 0x3f8 irq 4
|
|
</verb></tscreen>
|
|
|
|
<sect2><heading>Configuring the AX.25 channel access parameters.
|
|
<p>
|
|
The AX.25 channel access parameters are the equivalent of the KISS ppersist,
|
|
txdelay and slottime type parameters. Again you use the <em/sethdlc/ utility
|
|
for this.
|
|
<p>
|
|
Again the <em/sethdlc/ man page is the source of the most complete information
|
|
but another example of two won't hurt:
|
|
<p>
|
|
Configure the <tt/bc0/ device with TxDelay of 200 mS, SlotTime of 100 mS,
|
|
PPersist of 40 and half duplex:
|
|
<tscreen><verb>
|
|
# sethdlc -i bc0 -a txd 200 slot 100 ppersist 40 half
|
|
</verb></tscreen>
|
|
Note that the timing values are in milliseconds.
|
|
|
|
<sect3><heading>Configuring the Kernel AX.25 to use the BayCom device
|
|
<p>
|
|
The BayCom driver creates standard network devices that the AX.25
|
|
Kernel code can use. Configuration is much the same as that for a PI
|
|
or PacketTwin card.
|
|
<p>
|
|
The first step is to configure the device with an AX.25 callsign. The
|
|
<em/ifconfig/ utility may be used to perform this.
|
|
<tscreen><verb>
|
|
# /sbin/ifconfig bc0 hw ax25 VK2KTJ-15 up
|
|
</verb></tscreen>
|
|
will assign the BayCom device <tt/bc0/ the AX.25 callsign <tt/VK2KTJ-15/.
|
|
Alternatively you can use the <em/axparms/ command, you'll still need to
|
|
use the <em/ifconfig/ command to bring the device up though:
|
|
<tscreen><verb>
|
|
# ifconfig bc0 up
|
|
# axparms -setcall bc0 vk2ktj-15
|
|
</verb></tscreen>
|
|
<p>
|
|
The next step is to create an entry in the <tt>/etc/ax25/axports</tt> file
|
|
as you would for any other device. The entry in the <tt/axports/ file is
|
|
associated with the network device you've configured by the callsign you
|
|
configure. The entry in the <tt/axports/ file that has the callsign that
|
|
you configured the BayCom device with is the one that will be used to
|
|
refer to it.
|
|
<p>
|
|
You may then treat the new AX.25 device as you would any other. You can
|
|
configure it for TCP/IP, add it to ax25d and run NetRom or Rose over it
|
|
as you please.
|
|
|
|
<sect2><heading>Creating a SoundModem device.
|
|
<p>
|
|
<bf/Kernel Compile Options/:
|
|
<tscreen><verb>
|
|
Code maturity level options --->
|
|
[*] Prompt for development and/or incomplete code/drivers
|
|
General setup --->
|
|
[*] Networking support
|
|
Network device support --->
|
|
[*] Network device support
|
|
...
|
|
[*] Radio network interfaces
|
|
[*] Soundcard modem driver for AX.25
|
|
[?] Soundmodem support for Soundblaster and compatible cards
|
|
[?] Soundmodem support for WSS and Crystal cards
|
|
[?] Soundmodem support for 1200 baud AFSK modulation
|
|
[?] Soundmodem support for 4800 baud HAPN-1 modulation
|
|
[?] Soundmodem support for 9600 baud FSK G3RUH modulation
|
|
</verb></tscreen>
|
|
|
|
Thomas Sailer has built a new driver for the kernel that allows you to
|
|
use your soundcard as a modem. Connect your radio directly to your
|
|
soundcard to play packet! Thomas recommends at least a 486DX2/66 if you
|
|
want to use this software as all of the digital signal processing is done
|
|
by the main CPU.
|
|
<p>
|
|
The driver currently emulates 1200 bps AFSK, 4800 HAPN and 9600 FSK (G3RUH
|
|
compatible) modem types. The only sound cards currently supported are
|
|
SoundBlaster and WindowsSoundSystem Compatible models. The sound cards require
|
|
some circuitry to help them drive the Push-To-Talk circuitry, and information
|
|
on this is available from
|
|
<url url="http://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html"
|
|
name="Thomas's SoundModem PTT circuit web page">. There are quite
|
|
a few possible options, they are: detect the sound output from the soundcard,
|
|
or use output from a parallel port, serial port or midi port. Circuit examples
|
|
for each of these are on Thomas's site.
|
|
<p>
|
|
The SoundModem driver creates network devices called:
|
|
<tt/sm0/, <tt/sm1/, <tt/sm2/ etc when it is configured.
|
|
<p>
|
|
<bf>Note</bf>: the SoundModem driver competes for the same resources as the
|
|
Linux sound driver. So if you wish to use the SoundModem driver you must
|
|
ensure that the Linux sound driver is not installed. You can of course
|
|
compile them both as modules and insert and remove them as you wish.
|
|
|
|
<sect3><heading>Configuring the sound card.
|
|
<p>
|
|
The SoundModem driver does not initialise the sound card. The ax25-utils
|
|
package includes a utility to do this called `<em/setcrystal/' that may
|
|
be used for SoundCards based on the Crystal chipset. If you have some other
|
|
card then you will have to use some other software to initialise it.
|
|
Its syntax is fairly straightforward:
|
|
<tscreen><verb>
|
|
setcrystal [-w wssio] [-s sbio] [-f synthio] [-i irq] [-d dma] [-c dma2]
|
|
</verb></tscreen>
|
|
So, for example, if you wished to configure a soundblaster card at i/o
|
|
base address 0x388, irq 10 and DMA 1 you would use:
|
|
<tscreen><verb>
|
|
# setcrystal -s 0x388 -i 10 -d 1
|
|
</verb></tscreen>
|
|
To configure a WindowSoundSystem card at i/o base address 0x534, irq 5, DMA 3
|
|
you would use:
|
|
<tscreen><verb>
|
|
# setcrystal -w 0x534 -i 5 -d 3
|
|
</verb></tscreen>
|
|
|
|
The <tt/[-f synthio]/ parameter is the set the synthesiser address, and the
|
|
<tt/[-c dma2]/ parameter is to set the second DMA channel to allow full duplex
|
|
operation.
|
|
|
|
<sect3><heading>Configuring the SoundModem driver.
|
|
<p>
|
|
When you have configured the soundcard you need to configure the driver
|
|
telling it where the sound card is located and what sort of modem you wish
|
|
it to emulate.
|
|
<p>
|
|
The <em/sethdlc/ utility allows you to configure the driver with these
|
|
parameters, or, if you have only one soundcard installed you may specify
|
|
the parameters on the <em/insmod/ commmand line when you load the
|
|
SoundModem module.
|
|
<p>
|
|
For example, a simple configuration, with one SoundBlaster soundcard
|
|
configured as described above emulating a 1200 bps modem:
|
|
<tscreen><verb>
|
|
# insmod hdlcdrv
|
|
# insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1
|
|
</verb></tscreen>
|
|
This is not really the preferred way to do it. The <em/sethdlc/ utility
|
|
works just as easily with one device as with many.
|
|
<p>
|
|
The <em/sethdlc/ man page has the full details, but a couple of examples
|
|
will illustrate the most important aspects of this configuration. The
|
|
following examples assume you have already loaded the SoundModem modules
|
|
using:
|
|
<tscreen><verb>
|
|
# insmod hdlcdrv
|
|
# insmod soundmodem
|
|
</verb></tscreen>
|
|
or that you compiled the kernel with the driver inbuilt.
|
|
<p>
|
|
Configure the driver to support the WindowsSoundSystem card we configured
|
|
above to emulate a G3RUH 9600 compatible modem as device <tt/sm0/ using a
|
|
parallel port at 0x378 to key the Push-To-Talk:
|
|
<tscreen><verb>
|
|
# sethdlc -p -i sm0 mode wss:fsk9600 io 0x534 irq 5 dma 3 pario 0x378
|
|
</verb></tscreen>
|
|
Configure the driver to support the SoundBlaster card we configured above
|
|
to emulate a 4800 bps HAPN modem as device <tt/sm1/ using the serial port
|
|
located at 0x2f8 to key the Push-To-Talk:
|
|
<tscreen><verb>
|
|
# sethdlc -p -i sm1 mode sbc:hapn4800 io 0x388 irq 10 dma 1 serio 0x2f8
|
|
</verb></tscreen>
|
|
Configure the driver to support the SoundBlaster card we configured above
|
|
to emulate a 1200 bps AFSK modem as device <tt/sm1/ using the serial port
|
|
located at 0x2f8 to key the Push-To-Talk:
|
|
<tscreen><verb>
|
|
# sethdlc -p -i sm1 mode sbc:afsk1200 io 0x388 irq 10 dma 1 serio 0x2f8
|
|
</verb></tscreen>
|
|
|
|
<sect3><heading>Configuring the AX.25 channel access parameters.
|
|
<p>
|
|
The AX.25 channel access parameters are the equivalent of the KISS ppersist,
|
|
txdelay and slottime type parameters. You use the <em/sethdlc/ utility for
|
|
this as well.
|
|
<p>
|
|
Again the <em/sethdlc/ man page is the source of the most complete information
|
|
but another example of two won't hurt:
|
|
<p>
|
|
Configure the <tt/sm0/ device with TxDelay of 100 mS, SlotTime of 50mS,
|
|
PPersist of 128 and full duplex:
|
|
<tscreen><verb>
|
|
# sethdlc -i sm0 -a txd 100 slot 50 ppersist 128 full
|
|
</verb></tscreen>
|
|
Note that the timing values are in milliseconds.
|
|
|
|
<sect3><heading>Setting the audio levels and tuning the driver.
|
|
<p>
|
|
It is very important that the audio levels be set correctly for any radio
|
|
based modem to work. This is equally true of the SoundModem.
|
|
Thomas has developed some utility programs that make this task easier.
|
|
They are called <em/smdiag/ and <em/smmixer/.
|
|
<p>
|
|
<descrip>
|
|
<tag><em/smdiag/</tag>provides two types of display, either an oscilloscope
|
|
type display or an eye pattern type display.
|
|
<tag><em/smmixer/</tag>allows you to actually adjust the transmit and
|
|
receive audio levels.
|
|
</descrip>
|
|
To start the <em/smdiag/ utility in 'eye' mode for the SoundModem device
|
|
<tt/sm0/ you would use:
|
|
<tscreen><verb>
|
|
# smdiag -i sm0 -e
|
|
</verb></tscreen>
|
|
|
|
To start the <em/smmixer/ utility for the SoundModem device <tt/sm0/ you would
|
|
use:
|
|
<tscreen><verb>
|
|
# smmixer -i sm0
|
|
</verb></tscreen>
|
|
|
|
<sect3><heading>Configuring the Kernel AX.25 to use the SoundModem
|
|
<p>
|
|
The SoundModem driver creates standard network devices that the AX.25
|
|
Kernel code can use. Configuration is much the same as that for a PI
|
|
or PacketTwin card.
|
|
<p>
|
|
The first step is to configure the device with an AX.25 callsign.
|
|
The <em/ifconfig/ utility may be used to perform this.
|
|
<tscreen><verb>
|
|
# /sbin/ifconfig sm0 hw ax25 VK2KTJ-15 up
|
|
</verb></tscreen>
|
|
will assign the SoundModem device <tt/sm0/ the AX.25 callsign <tt/VK2KTJ-15/.
|
|
Alternatively you can use the <em/axparms/ command, but you still need the
|
|
<em/ifconfig/ utility to bring the device up:
|
|
<tscreen><verb>
|
|
# ifconfig sm0 up
|
|
# axparms -setcall sm0 vk2ktj-15
|
|
</verb></tscreen>
|
|
<p>
|
|
The next step is to create an entry in the <tt>/etc/ax25/axports</tt> file
|
|
as you would for any other device. The entry in the <tt/axports/ file is
|
|
associated with the network device you've configured by the callsign you
|
|
configure. The entry in the <tt/axports/ file that has the callsign that
|
|
you configured the SoundModem device with is the one that will be used to
|
|
refer to it.
|
|
<p>
|
|
You may then treat the new AX.25 device as you would any other. You can
|
|
configure it for TCP/IP, add it to ax25d and run NetRom or Rose over it
|
|
as you please.
|
|
|
|
<sect2><heading>Creating a PI card device.
|
|
<p>
|
|
<bf/Kernel Compile Options/:
|
|
<tscreen><verb>
|
|
General setup --->
|
|
[*] Networking support
|
|
Network device support --->
|
|
[*] Network device support
|
|
...
|
|
[*] Radio network interfaces
|
|
[*] Ottawa PI and PI/2 support for AX.25
|
|
</verb></tscreen>
|
|
|
|
The PI card device driver creates devices named `<tt/pi[0-9][ab]/'. The
|
|
first PI card detected will be allocated `<tt/pi0/', the second `<tt/pi1/'
|
|
etc. The `<tt/a/' and `<tt/b/' refer to the first and second physical interface
|
|
on the PI card. If you have built your kernel to include the PI card driver,
|
|
and the card has been properly detected then you can use the following
|
|
command to configure the network device:
|
|
|
|
<tscreen><verb>
|
|
# /sbin/ifconfig pi0a hw ax25 VK2KTJ-15 up
|
|
</verb></tscreen>
|
|
|
|
This command would configure the first port on the first PI card detected
|
|
with the callsign <tt/VK2KTJ-15/ and make it active. To use the device all
|
|
you now need to do is to configure an entry into your <tt>/etc/ax25/axports</tt>
|
|
file with a matching callsign/ssid and you will be ready to continue on.
|
|
|
|
<p>
|
|
The PI card driver was written by
|
|
<tt>David Perry, <dp@hydra.carleton.edu></tt>
|
|
|
|
<sect2><heading>Creating a PacketTwin device.
|
|
<p>
|
|
<bf/Kernel Compile Options/:
|
|
<tscreen><verb>
|
|
General setup --->
|
|
[*] Networking support
|
|
Network device support --->
|
|
[*] Network device support
|
|
...
|
|
[*] Radio network interfaces
|
|
[*] Gracilis PackeTwin support for AX.25
|
|
</verb></tscreen>
|
|
|
|
The PacketTwin card device driver creates devices named `<tt/pt[0-9][ab]/'.
|
|
The first PacketTwin card detected will be allocated `<tt/pt0/', the second
|
|
`<tt/pt1/' etc. The `<tt/a/' and `<tt/b/' refer to the first and second
|
|
physical interface on the PacketTwin card. If you have built your kernel to
|
|
include the PacketTwin card driver, and the card has been properly detected
|
|
then you can use the following command to configure the network device:
|
|
|
|
<tscreen><verb>
|
|
# /sbin/ifconfig pt0a hw ax25 VK2KTJ-15 up
|
|
</verb></tscreen>
|
|
|
|
This command would configure the first port on the first PacketTwin card
|
|
detected with the callsign <tt/VK2KTJ-15/ and make it active. To use the
|
|
device all you now need to do is to configure an entry into your
|
|
<tt>/etc/ax25/axports</tt> file with a matching callsign/ssid and you will
|
|
be ready to continue on.
|
|
<p>
|
|
The PacketTwin card driver was written by
|
|
<tt>Craig Small VK2XLZ, <csmall@triode.apana.org.au></tt>.
|
|
|
|
<sect2><heading>Creating a generic SCC device.
|
|
<p>
|
|
<bf/Kernel Compile Options/:
|
|
<tscreen><verb>
|
|
General setup --->
|
|
[*] Networking support
|
|
Network device support --->
|
|
[*] Network device support
|
|
...
|
|
[*] Radio network interfaces
|
|
[*] Z8530 SCC KISS emulation driver for AX.25
|
|
</verb></tscreen>
|
|
|
|
Joerg Reuter, DL1BKE, <tt/jreuter@poboxes.com/ has developed generic
|
|
support for Z8530 SCC based cards. His driver is configurable to support a
|
|
range of different types of cards and present an interface that looks like a
|
|
KISS TNC so you can treat it as though it were a KISS TNC.
|
|
|
|
<sect3><heading>Obtaining and building the configuration tool package.
|
|
<p>
|
|
While the kernel driver is included in the standard kernel distribution,
|
|
Joerg distributes more recent versions of his driver with the suite of
|
|
configuration tools that you will need to obtain as well.
|
|
<p>
|
|
You can obtain the configuration tools package from:
|
|
|
|
<url name="Joerg's web page" url="http://www.rat.de/jr/">
|
|
|
|
or:
|
|
|
|
<bf>db0bm.automation.fh-aachen.de</bf>
|
|
<tscreen><verb>
|
|
/incoming/dl1bke/
|
|
</verb></tscreen>
|
|
|
|
or:
|
|
|
|
<bf>insl1.etec.uni-karlsruhe.de</bf>
|
|
<tscreen><verb>
|
|
/pub/hamradio/linux/z8530/
|
|
</verb></tscreen>
|
|
|
|
or:
|
|
|
|
<bf>ftp.ucsd.edu</bf>
|
|
<tscreen><verb>
|
|
/hamradio/packet/tcpip/linux
|
|
/hamradio/packet/tcpip/incoming/
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
You will find multiple versions, choose the one that best suits the
|
|
kernel you intend to use:
|
|
|
|
<verb>
|
|
z8530drv-2.4a.dl1bke.tar.gz 2.0.*
|
|
z8530drv-utils-3.0.tar.gz 2.1.6 or greater
|
|
</verb>
|
|
|
|
<p>
|
|
The following commands were what I used to compile and install the package
|
|
for kernel version 2.0.30:
|
|
<tscreen><verb>
|
|
# cd /usr/src
|
|
# gzip -dc z8530drv-2.4a.dl1bke.tar.gz | tar xvpofz -
|
|
# cd z8530drv
|
|
# make clean
|
|
# make dep
|
|
# make module # If you want to build the driver as a module
|
|
# make for_kernel # If you want the driver to built into your kernel
|
|
# make install
|
|
</verb></tscreen>
|
|
<p>
|
|
After the above is complete you should have three new programs installed
|
|
in your <tt>/sbin</tt> directory: <em>gencfg</em>, <em>sccinit</em> and
|
|
<em>sccstat</em>. It is these programs that you will use to configure the
|
|
driver for your card.
|
|
<p>
|
|
You will also have a group of new special device files created in your
|
|
<tt>/dev</tt> called <tt>scc0</tt>-<tt>scc7</tt>. These will be used
|
|
later and will be the `KISS' devices you will end up using.
|
|
<p>
|
|
If you chose to 'make for_kernel' then you will need to recompile your
|
|
kernel. To ensure that you include support for the z8530 driver you must be
|
|
sure to answer `<tt>Y</tt>' to:
|
|
`<tt>Z8530 SCC kiss emulation driver for AX.25</tt>' when asked during a
|
|
kernel `<tt>make config</tt>'.
|
|
<p>
|
|
If you chose to 'make module' then the new <tt/scc.o/ will have been
|
|
installed in the appropriate <tt>/lib/modules</tt> directory and you do
|
|
not need to recompile your kernel. Remember to use the <em/insmod/ command
|
|
to load the module before your try and configure it.
|
|
|
|
<sect3><heading>Configuring the driver for your card.
|
|
<p>
|
|
The z8530 SCC driver has been designed to be as flexible as possible so as
|
|
to support as many different types of cards as possible. With this flexibility
|
|
has come some cost in configuration.
|
|
<p>
|
|
There is more comprehensive documentation in the package and you should
|
|
read this if you have any problems. You should particularly look at
|
|
<tt>doc/scc_eng.doc</tt> or <tt>doc/scc_ger.doc</tt> for more detailed
|
|
information. I've paraphrased the important details, but as a result there
|
|
is a lot of lower level detail that I have not included.
|
|
<p>
|
|
The main configuration file is read by the <em>sccinit</em> program and is
|
|
called <tt>/etc/z8530drv.conf</tt>. This file is broken into two main stages:
|
|
Configuration of the hardware parameters and channel configuration. After
|
|
you have configured this file you need only add:
|
|
|
|
<tscreen><verb>
|
|
# sccinit
|
|
</verb></tscreen>
|
|
|
|
into the <tt>rc</tt> file that configures your network and the driver will
|
|
be initialised according to the contents of the configuration file. You must
|
|
do this before you attempt to use the driver.
|
|
|
|
|
|
<sect4><heading>Configuration of the hardware parameters.
|
|
<p>
|
|
The first section is broken into stanzas, each stanza representing an 8530
|
|
chip. Each stanza is a list of keywords with arguments. You may specify up
|
|
to four SCC chips in this file by default. The <tt>#define MAXSCC 4</tt> in
|
|
<tt>scc.c</tt> can be increased if you require support for more.
|
|
<p>
|
|
The allowable keywords and arguments are:
|
|
|
|
<descrip>
|
|
<tag>chip</tag>the <tt>chip</tt> keyword is used to separate stanzas. It will
|
|
take anything as an argument. The arguments are not used.
|
|
<tag>data_a</tag>this keyword is used to specify the address of the data
|
|
port for the z8530 channel `A'. The argument is a hexadecimal number
|
|
e.g. 0x300
|
|
<tag>ctrl_a</tag>this keyword is used to specify the address of the control
|
|
port for the z8530 channel `A'. The arguments is a hexadecimal number
|
|
e.g. 0x304
|
|
<tag>data_b</tag>this keyword is used to specify the address of the data
|
|
port for the z8530 channel `B'. The argument is a hexadecimal number
|
|
e.g. 0x301
|
|
<tag>ctrl_b</tag>this keyword is used to specify the address of the control
|
|
port for the z8530 channel `B'. The arguments is a hexadecimal number
|
|
e.g. 0x305
|
|
<tag>irq</tag>this keyword is used to specify the IRQ used by the 8530 SCC
|
|
described in this stanza. The argument is an integer e.g. 5
|
|
<tag>pclock</tag>this keyword is used to specify the frequency of the clock
|
|
at the PCLK pin of the 8530. The argument is an integer frequency in Hz which
|
|
defaults to 4915200 if the keyword is not supplied.
|
|
<tag>board</tag>the type of board supporting this 8530 SCC. The argument is
|
|
a character string. The allowed values are:
|
|
<descrip>
|
|
<tag>PA0HZP</tag>the PA0HZP SCC Card
|
|
<tag>EAGLE</tag>the Eagle card
|
|
<tag>PC100</tag>the DRSI PC100 SCC card
|
|
<tag>PRIMUS</tag>the PRIMUS-PC (DG9BL) card
|
|
<tag>BAYCOM</tag>BayCom (U)SCC card
|
|
</descrip>
|
|
<tag>escc</tag>this keyword is optional and is used to enable support for the
|
|
Extended SCC chips (ESCC) such as the 8580, 85180, or the 85280. The argument
|
|
is a character string with allowed values of `yes' or `no'. The default is
|
|
`no'.
|
|
<tag>vector</tag>this keyword is optional and specifies the address of the
|
|
vector latch (also known as "intack port") for PA0HZP cards. There can be only
|
|
one vector latch for all chips. The default is 0.
|
|
<tag>special</tag>this keyword is optional and specifies the address of the
|
|
special function register on several cards. The default is 0.
|
|
<tag>option</tag>this keyword is optional and defaults to 0.
|
|
</descrip>
|
|
|
|
Some example configurations for the more popular cards are as follows:
|
|
|
|
<descrip>
|
|
<tag>BayCom USCC</tag><tscreen><verb>
|
|
chip 1
|
|
data_a 0x300
|
|
ctrl_a 0x304
|
|
data_b 0x301
|
|
ctrl_b 0x305
|
|
irq 5
|
|
board BAYCOM
|
|
#
|
|
# SCC chip 2
|
|
#
|
|
chip 2
|
|
data_a 0x302
|
|
ctrl_a 0x306
|
|
data_b 0x303
|
|
ctrl_b 0x307
|
|
board BAYCOM
|
|
</verb></tscreen>
|
|
<tag>PA0HZP SCC card</tag><tscreen><verb>
|
|
chip 1
|
|
data_a 0x153
|
|
data_b 0x151
|
|
ctrl_a 0x152
|
|
ctrl_b 0x150
|
|
irq 9
|
|
pclock 4915200
|
|
board PA0HZP
|
|
vector 0x168
|
|
escc no
|
|
#
|
|
#
|
|
#
|
|
chip 2
|
|
data_a 0x157
|
|
data_b 0x155
|
|
ctrl_a 0x156
|
|
ctrl_b 0x154
|
|
irq 9
|
|
pclock 4915200
|
|
board PA0HZP
|
|
vector 0x168
|
|
escc no
|
|
</verb></tscreen>
|
|
<tag>DRSI SCC card</tag><tscreen><verb>
|
|
chip 1
|
|
data_a 0x303
|
|
data_b 0x301
|
|
ctrl_a 0x302
|
|
ctrl_b 0x300
|
|
irq 7
|
|
pclock 4915200
|
|
board DRSI
|
|
escc no
|
|
</verb></tscreen>
|
|
</descrip>
|
|
|
|
If you already have a working configuration for your card under NOS, then
|
|
you can use the <em>gencfg</em> command to convert the PE1CHL NOS driver
|
|
commands into a form suitable for use in the z8530 driver configuration
|
|
file.
|
|
<p>
|
|
To use <em>gencfg</em> you simply invoke it with the same parameters as you
|
|
used for the PE1CHL driver in NET/NOS. For example:
|
|
<tscreen><verb>
|
|
# gencfg 2 0x150 4 2 0 1 0x168 9 4915200
|
|
</verb></tscreen>
|
|
will generate a skeleton configuration for the OptoSCC card.
|
|
|
|
<sect3><heading>Channel Configuration
|
|
<p>
|
|
The Channel Configuration section is where you specify all of the other
|
|
parameters associated with the port you are configuring. Again this
|
|
section is broken into stanzas. One stanza represents one logical port, and
|
|
therefore there would be two of these for each one of the hardware parameters
|
|
stanzas as each 8530 SCC supports two ports.
|
|
<p>
|
|
These keywords and arguments are also written to the <tt>/etc/z8530drv.conf</tt>
|
|
file and must appear <bf>after</bf> the hardware parameters section.
|
|
<p>
|
|
Sequence is very important in this section, but if you stick with the suggested
|
|
sequence it should work ok. The keywords and arguments are:
|
|
<descrip>
|
|
<tag>device</tag>this keyword must be the first line of a port definition and
|
|
specifies the name of the special device file that the rest of the
|
|
configuration applies to. e.g. <tt>/dev/scc0</tt>
|
|
<tag>speed</tag>this keyword specifies the speed in bits per second of the
|
|
interface. The argument is an integer: e.g. <tt>1200</tt>
|
|
<tag>clock</tag>this keyword specifies where the clock for the data will
|
|
be sourced. Allowable values are:
|
|
<descrip>
|
|
<tag>dpll</tag>normal halfduplex operation
|
|
<tag>external</tag>MODEM supplies its own Rx/Tx clock
|
|
<tag>divider</tag>use fullduplex divider if installed.
|
|
</descrip>
|
|
<tag>mode</tag>this keyword specifies the data coding to be used. Allowable
|
|
arguments are: <tt>nrzi</tt> or <tt>nrz</tt>
|
|
<tag>rxbuffers</tag>this keyword specifies the number of receive buffers to
|
|
allocate memory for. The argument is an integer, e.g. 8.
|
|
<tag>txbuffers</tag>this keyword specifies the number of transmit buffers to
|
|
allocate memory for. The argument is an integer, e.g. 8.
|
|
<tag>bufsize</tag>this keyword specifies the size of the receive and transmit
|
|
buffers. The arguments is in bytes and represents the total length of the
|
|
frame, so it must also take into account the AX.25 headers and not just the
|
|
length of the data field. This keyword is optional and default to <tt>384</tt>
|
|
<tag>txdelay</tag>the KISS transmit delay value, the argument is an integer in mS.
|
|
<tag>persist</tag>the KISS persist value, the argument is an integer.
|
|
<tag>slot</tag>the KISS slot time value, the argument is an integer in mS.
|
|
<tag>tail</tag>the KISS transmit tail value, the argument is an integer in mS.
|
|
<tag>fulldup</tag>the KISS full duplex flag, the argument is an integer.
|
|
<tt>1</tt>==Full Duplex, <tt>0</tt>==Half Duplex.
|
|
<tag>wait</tag>the KISS wait value, the argument is an integer in mS.
|
|
<tag>min</tag>the KISS min value, the argument is an integer in S.
|
|
<tag>maxkey</tag>the KISS maximum keyup time, the argument is an integer in S.
|
|
<tag>idle</tag>the KISS idle timer value, the argument is an integer in S.
|
|
<tag>maxdef</tag>the KISS maxdef value, the argument is an integer.
|
|
<tag>group</tag>the KISS group value, the argument is an integer.
|
|
<tag>txoff</tag>the KISS txoff value, the argument is an integer in mS.
|
|
<tag>softdcd</tag>the KISS softdcd value, the argument is an integer.
|
|
<tag>slip</tag>the KISS slip flag, the argument is an integer.
|
|
</descrip>
|
|
|
|
<sect3><heading>Using the driver.
|
|
<p>
|
|
To use the driver you simply treat the <tt>/dev/scc*</tt> devices just as
|
|
you would a serial tty device with a KISS TNC connected to it. For example,
|
|
to configure Linux Kernel networking to use your SCC card you could use
|
|
something like:
|
|
<tscreen><verb>
|
|
# kissattach -s 4800 /dev/scc0 VK2KTJ
|
|
</verb></tscreen>
|
|
|
|
You can also use NOS to attach to it in precisely the same way. From JNOS
|
|
for example you would use something like:
|
|
|
|
<tscreen><verb>
|
|
attach asy scc0 0 ax25 scc0 256 256 4800
|
|
</verb></tscreen>
|
|
|
|
<sect3><heading>The <em>sccstat</em> and <em>sccparam</em> tools.
|
|
<p>
|
|
To assist in the diagnosis of problems you can use the <em>sccstat</em>
|
|
program to display the current configuration of an SCC device. To use it
|
|
try:
|
|
|
|
<tscreen><verb>
|
|
# sccstat /dev/scc0
|
|
</verb></tscreen>
|
|
|
|
you will displayed a very large amount of information relating to the
|
|
configuration and health of the <tt>/dev/scc0</tt> SCC port.
|
|
|
|
<p>
|
|
The <em>sccparam</em> command allows you to change or modify a configuration
|
|
after you have booted. Its syntax is very similar to the NOS <tt>param</tt>
|
|
command, so to set the <tt>txtail</tt> setting of a device to 100mS you
|
|
would use:
|
|
|
|
<tscreen><verb>
|
|
# sccparam /dev/scc0 txtail 0x8
|
|
</verb></tscreen>
|
|
|
|
<sect2><heading>Creating a BPQ ethernet device.
|
|
<p>
|
|
<bf/Kernel Compile Options/:
|
|
<tscreen><verb>
|
|
General setup --->
|
|
[*] Networking support
|
|
Network device support --->
|
|
[*] Network device support
|
|
...
|
|
[*] Radio network interfaces
|
|
[*] BPQ Ethernet driver for AX.25
|
|
</verb></tscreen>
|
|
|
|
Linux supports BPQ Ethernet compatibility. This enables you to run the AX.25
|
|
protocol over your Ethernet LAN and to interwork your linux machine with
|
|
other BPQ machines on the LAN.
|
|
<p>
|
|
The BPQ network devices are named `<tt/bpq[0-9]/'. The `<tt/bpq0/' device
|
|
is associated with the `<tt/eth0/' device, the `<tt/bpq1/' device with the
|
|
`<tt/eth1/' device etc.
|
|
<p>
|
|
Configuration is quite straightforward. You firstly must have configured
|
|
a standard Ethernet device. This means you will have compiled your kernel
|
|
to support your Ethernet card and tested that this works. Refer to the
|
|
<url url="Ethernet-HOWTO.html" name="Ethernet-HOWTO"> for more information
|
|
on how to do this.
|
|
<p>
|
|
To configure the BPQ support you need to configure the Ethernet device with
|
|
an AX.25 callsign. The following command will do this for you:
|
|
|
|
<tscreen><verb>
|
|
# /sbin/ifconfig bpq0 hw ax25 vk2ktj-14 up
|
|
</verb></tscreen>
|
|
|
|
Again, remember that the callsign you specify should match the entry in the
|
|
<tt>/etc/ax25/axports</tt> file that you wish to use for this port.
|
|
|
|
<sect2><heading>Configuring the BPQ Node to talk to the Linux AX.25 support.
|
|
<p>
|
|
BPQ Ethernet normally uses a multicast address. The Linux implementation does
|
|
not, and instead it uses the normal Ethernet broadcast address. The NET.CFG
|
|
file for the BPQ ODI driver should therefore be modifified to look similar to
|
|
this:
|
|
|
|
<tscreen><verb>
|
|
LINK SUPPORT
|
|
|
|
MAX STACKS 1
|
|
MAX BOARDS 1
|
|
|
|
LINK DRIVER E2000 ; or other MLID to suit your card
|
|
|
|
INT 10 ;
|
|
PORT 300 ; to suit your card
|
|
|
|
FRAME ETHERNET_II
|
|
|
|
PROTOCOL BPQ 8FF ETHERNET_II ; required for BPQ - can change PID
|
|
|
|
BPQPARAMS ; optional - only needed if you want
|
|
; to override the default target addr
|
|
|
|
ETH_ADDR FF:FF:FF:FF:FF:FF ; Target address
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading>Creating the <tt>/etc/ax25/axports</tt> file.
|
|
<p>
|
|
The <tt>/etc/ax25/axports</tt> is a simple text file that you create with
|
|
a text editor. The format of the <tt>/etc/ax25/axports</tt> file is as follows:
|
|
|
|
<tscreen><verb>
|
|
portname callsign baudrate paclen window description
|
|
</verb></tscreen>
|
|
|
|
where:
|
|
|
|
<descrip>
|
|
<tag>portname</tag>is a text name that you will refer to the port by.
|
|
<tag>callsign</tag>is the AX.25 callsign you want to assign to the port.
|
|
<tag>baudrate</tag>is the speed at which you wish the port to communicate with
|
|
your TNC.
|
|
<tag>paclen</tag>is the maximum packet length you want to configure the port
|
|
to use for AX.25 connected mode connections.
|
|
<tag>window</tag>is the AX.25 window (K) parameter. This is the same as the
|
|
<tt>MAXFRAME</tt> setting of many tnc's.
|
|
<tag>description</tag>is a textual description of the port.
|
|
</descrip>
|
|
|
|
In my case, mine looks like:
|
|
|
|
<tscreen><verb>
|
|
radio VK2KTJ-15 4800 256 2 4800bps 144.800 MHz
|
|
ether VK2KTJ-14 10000000 256 2 BPQ/ethernet device
|
|
</verb></tscreen>
|
|
|
|
Remember, you must assign unique callsign/ssid to each AX.25 port you create.
|
|
Create one entry for each AX.25 device you want to use, this includes KISS,
|
|
Baycom, SCC, PI, PT and SoundModem ports. Each entry here will describe exactly
|
|
one AX.25 network device. The entries in this file are associated with the
|
|
network devices by the callsign/ssid. This is at least one good reason for
|
|
requiring unique callsign/ssid.
|
|
|
|
<sect1><heading>Configuring AX.25 routing.
|
|
<p>
|
|
You may wish to configure default digipeaters paths for specific hosts.
|
|
This is useful for both normal AX.25 connections and also IP based connections.
|
|
The <em/axparms/ command enables you to do this. Again, the <em/man/ page
|
|
offers a complete description, but a simple example might be:
|
|
<tscreen><verb>
|
|
# /usr/sbin/axparms -route add radio VK2XLZ VK2SUT
|
|
</verb></tscreen>
|
|
|
|
This command would set a digipeater entry for <tt/VK2XLZ/ via <tt/VK2SUT/ on
|
|
the AX.25 port named <tt/radio/.
|
|
|
|
<sect><heading>Configuring an AX.25 interface for TCP/IP.
|
|
<p>
|
|
It is very simple to configure an AX.25 port to carry TCP/IP.
|
|
If you have KISS interfaces then there are two methods for configuring an
|
|
IP address. The <em>kissattach</em> command has an option that allows you to
|
|
do specify an IP address. The more conventional method using the <em/ifconfig/
|
|
command will work on all interface types.
|
|
<p>
|
|
So, modifying the previous KISS example:
|
|
<tscreen><verb>
|
|
# /usr/sbin/kissattach -i 44.136.8.5 -m 512 /dev/ttyS0 radio
|
|
# /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 ax0
|
|
# /sbin/route add default ax0
|
|
</verb></tscreen>
|
|
|
|
to create the AX.25 interface with an IP address of <tt>44.136.8.5</tt> and
|
|
an <tt>MTU</tt> of <tt>512</tt> bytes. You should still use the
|
|
<em>ifconfig</em> to configure the other parameters if necessary.
|
|
<p>
|
|
If you have any other interface type then you use the <em>ifconfig</em> program
|
|
to configure the ip address and netmask details for the port and add a route
|
|
via the port, just as you would for any other TCP/IP interface. The following
|
|
example is for a PI card device, but would work equally well for any other
|
|
AX.25 network device:
|
|
|
|
<tscreen><verb>
|
|
# /sbin/ifconfig pi0a 44.136.8.5 netmask 255.255.255.0 up
|
|
# /sbin/ifconfig pi0a broadcast 44.136.8.255 mtu 512
|
|
# /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 pi0a
|
|
# /sbin/route add default pi0a
|
|
</verb></tscreen>
|
|
|
|
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 that the default route might not be required
|
|
in your configuration if you have some other network device configured.
|
|
<p>
|
|
To test it out, try a ping or a telnet to a local host.
|
|
|
|
<tscreen><verb>
|
|
# ping -i 5 44.136.8.58
|
|
</verb></tscreen>
|
|
|
|
Note the use of the `<tt>-i 5</tt>' arguments to <em>ping</em> to tell it to
|
|
send pings every 5 seconds instead of its default of 1 second.
|
|
|
|
<sect><heading>Configuring a NetRom port.
|
|
<p>
|
|
The NetRom protocol relies on, and uses the AX.25 ports you have created.
|
|
The NetRom protocol rides on top of the AX.25 protocol. To configure NetRom
|
|
on an AX.25 interface you must configure two files. One file describes the
|
|
Netrom interfaces, and the other file describes which of the AX.25 ports
|
|
will carry NetRom. You can configure multiple NetRom ports, each with its
|
|
own callsign and alias, the same procedure applies for each.
|
|
|
|
<sect1><heading>Configuring <tt>/etc/ax25/nrports</tt>
|
|
<p>
|
|
The first is the <tt>/etc/ax25/nrports</tt> file. This file describes
|
|
the NetRom ports in much the same way as the <tt>/etc/ax25/axports</tt>
|
|
file describes the AX.25 ports. Each NetRom device you wish to create
|
|
must have an entry in the <tt>/etc/ax25/nrports</tt> file. Normally
|
|
a Linux machine would have only one NetRom device configured that would
|
|
use a number of the AX.25 ports defined. In some situations you might
|
|
wish a special service such as a BBS to have a seperate NetRom alias and
|
|
so you would create more than one.
|
|
<p>
|
|
This file is formatted as follows:
|
|
|
|
<tscreen><verb>
|
|
name callsign alias paclen description
|
|
</verb></tscreen>
|
|
|
|
Where:
|
|
<descrip>
|
|
<tag>name</tag>is the text name that you wish to refer to the port by.
|
|
<tag>callsign</tag>is the callsign that the NetRom traffic from this port
|
|
will use. Note, this is <bf/not/ that address that users should connect
|
|
to to get access to a <em/node/ style interface. (The node program is covered
|
|
later). This callsign/ssid should be unique and should not appear elsewhere
|
|
in either of the <tt>/etc/ax25/axports</tt> or the <tt>/etc/ax25/nrports</tt>
|
|
files.
|
|
<tag>alias</tag>is the NetRom alias this port will have assigned to it.
|
|
<tag>paclen</tag>is the maximum size of NetRom frames transmitted by this port.
|
|
<tag>description</tag>is a free text description of the port.
|
|
</descrip>
|
|
|
|
An example would look something like the following:
|
|
|
|
<tscreen><verb>
|
|
netrom VK2KTJ-9 LINUX 236 Linux Switch Port
|
|
</verb></tscreen>
|
|
|
|
This example creates a NetRom port known to the rest of the NetRom network
|
|
as `<tt/LINUX:VK2KTJ-9/'.
|
|
<p>
|
|
This file is used by programs such as the <em/call/ program.
|
|
|
|
<sect1><heading>Configuring <tt>/etc/ax25/nrbroadcast</tt>
|
|
<p>
|
|
The second file is the <tt>/etc/ax25/nrbroadcast</tt> file. This file may
|
|
contain a number of entries. There would normally be one entry for each
|
|
AX.25 port that you wish to allow NetRom traffic on.
|
|
<p>
|
|
This file is formatted as follows:
|
|
|
|
<tscreen><verb>
|
|
axport min_obs def_qual worst_qual verbose
|
|
</verb></tscreen>
|
|
|
|
Where:
|
|
<descrip>
|
|
<tag>axport</tag>is the port name obtained from the
|
|
<tt>/etc/ax25/axports</tt> file. If you do not have an entry in
|
|
<tt>/etc/ax25/nrbroadcasts</tt> for a port then this means that no NetRom
|
|
routing will occur and any received NetRom broadcasts will be ignored for that
|
|
port.
|
|
<tag>min_obs</tag>is the minimum obselesence value for the port.
|
|
<tag>def_qual</tag>is the default quality for the port.
|
|
<tag>worst_qual</tag>is the worst quality value for the port, any routes under
|
|
this quality will be ignored.
|
|
<tag>verbose</tag>is a flag determining whether full NetRom routing broadcasts
|
|
will occur from this port or only a routing broadcast advertising the node
|
|
itself.
|
|
</descrip>
|
|
|
|
An example would look something like the following:
|
|
|
|
<tscreen><verb>
|
|
radio 1 200 100 1
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading>Creating the NetRom Network device
|
|
<p>
|
|
When you have the two configuration files completed you must create the
|
|
NetRom device in much the same way as you did for the AX.25 devices.
|
|
This time you use the <em/nrattach/ command. The <em/nrattach/ works in
|
|
just the same way as the <em/axattach/ command except that it creates
|
|
NetRom network devices called `<tt/nr[0-9]/'. Again, the first time you
|
|
use the <em/nrattach/ command it creates the `<tt/nr0/' device, the second
|
|
time it creates the `<tt/nr1/' network devices etc. To create the network
|
|
device for the NetRom port we've defined we would use:
|
|
|
|
<tscreen><verb>
|
|
# nrattach netrom
|
|
</verb></tscreen>
|
|
|
|
This command would start the NetRom device (<tt>nr0</tt>) named <tt>netrom</tt>
|
|
configured with the details specified in the <tt>/etc/ax25/nrports</tt>
|
|
file.
|
|
|
|
<sect1><heading>Starting the NetRom daemon
|
|
<p>
|
|
The Linux kernel does all of the NetRom protocol and switching, but does not
|
|
manage some functions. The NetRom daemon manages the NetRom routing tables
|
|
and generates the NetRom routing broadcasts. You start NetRom daemon with
|
|
the command:
|
|
|
|
<tscreen><verb>
|
|
# /usr/sbin/netromd -i
|
|
</verb></tscreen>
|
|
|
|
You should soon see the <tt>/proc/net/nr_neigh</tt> file filling up with
|
|
information about your NetRom neighbours.
|
|
<p>
|
|
Remember to put the <tt>/usr/sbin/netromd</tt> command in your
|
|
<em>rc</em> files so that it is started automatically each time you reboot.
|
|
|
|
<sect1><heading>Configuring NetRom routing.
|
|
<p>
|
|
You may wish to configure static NetRom routes for specific hosts.
|
|
The <em/nrparms/ command enables you to do this. Again, the <em/man/ page
|
|
offers a complete description, but a simple example might be:
|
|
<tscreen><verb>
|
|
# /usr/sbin/nrparms -nodes VK2XLZ-10 + #MINTO 120 5 radio VK2SUT-9
|
|
</verb></tscreen>
|
|
|
|
This command would set a NetRom route to <tt/#MINTO:VK2XLZ-10/ via a neighbour
|
|
<tt/VK2SUT-9/ on my AX.25 port called `<tt/radio/'.
|
|
|
|
<p>
|
|
You can manually create entries for new neighbours using the <em/nrparms/
|
|
command as well. For example:
|
|
|
|
<tscreen><verb>
|
|
# /usr/sbin/nrparms -routes radio VK2SUT-9 + 120
|
|
</verb></tscreen>
|
|
|
|
This command would create <tt/VK2SUT-9/ as a NetRom neighbour with a quality
|
|
of <tt/120/ and this will be locked and will not be deleted automatically.
|
|
|
|
<sect><heading>Configuring a NetRom interface for TCP/IP.
|
|
<p>
|
|
Configuring a NetRom interface for TCP/IP is almost identical to configuring
|
|
an AX.25 interface for TCP/IP.
|
|
<p>
|
|
Again you can either specify the ip address and mtu on the <em>nrattach</em>
|
|
command line, or use the <em>ifconfig</em> and <em>route</em> commands, but
|
|
you need to manually add <em>arp</em> entries for hosts you wish to route to
|
|
because there is no mechanism available for your machine to learn what
|
|
NetRom address it should use to reach a particular IP host.
|
|
<p>
|
|
So, to create an <tt>nr0</tt> device with an IP address of <tt>44.136.8.5</tt>,
|
|
an mtu of <tt>512</tt> and configured with the details from the
|
|
<tt>/etc/ax25/nrports</tt> file for a NetRom port named <tt>netrom</tt>
|
|
you would use:
|
|
|
|
<tscreen><verb>
|
|
# /usr/sbin/nrattach -i 44.136.8.5 -m 512 netrom
|
|
# route add 44.136.8.5 nr0
|
|
</verb></tscreen>
|
|
|
|
or you could use something like the following commands manually:
|
|
|
|
<tscreen><verb>
|
|
# /usr/sbin/nrattach netrom
|
|
# ifconfig nr0 44.136.8.5 netmask 255.255.255.0 hw netrom VK2KTJ-9
|
|
# route add 44.136.8.5 nr0
|
|
</verb></tscreen>
|
|
|
|
Then for each IP host you wish to reach via NetRom you need to set route and
|
|
arp entries. To reach a destination host with an IP address of
|
|
<tt>44.136.80.4</tt> at NetRom address <tt>BBS:VK3BBS</tt> via a NetRom
|
|
neighbour with callsign <tt>VK2SUT-0</tt> you would use commands as follows:
|
|
|
|
<tscreen><verb>
|
|
# route add 44.136.80.4 nr0
|
|
# arp -t netrom -s 44.136.80.4 vk2sut-0
|
|
# nrparms -nodes vk3bbs + BBS 120 6 sl0 vk2sut-0
|
|
</verb></tscreen>
|
|
|
|
The `<tt>120</tt>' and `<tt>6</tt>' arguments to the <em>nrparms</em> command
|
|
are the NetRom <em>quality</em> and <em>obsolescence count</em> values for the
|
|
route.
|
|
|
|
<sect><heading>Configuring a Rose port.
|
|
<p>
|
|
The Rose packet layer protocol is similar to layer three of the X.25
|
|
specification. The kernel based Rose support is a <bf/modified/ version of the
|
|
<url url="http://fpac.lmi.ecp.fr/f1oat/f1oat.html"
|
|
name="FPAC Rose implementation">.
|
|
<p>
|
|
The Rose packet layer protocol protocol relies on, and uses the AX.25 ports
|
|
you have created. The Rose protocol rides on top of the AX.25 protocol.
|
|
To configure Rose you must create a configuration file that describes the
|
|
Rose ports you want. You can create multiple Rose ports if you wish, the same
|
|
procedure applies for each.
|
|
|
|
<sect1><heading>Configuring <tt>/etc/ax25/rsports</tt>
|
|
<p>
|
|
The file where you configure your Rose interfaces is the
|
|
<tt>/etc/ax25/rsports</tt> file. This file describes the Rose port in much
|
|
the same way as the <tt>/etc/ax25/axports</tt> file describes the AX.25 ports.
|
|
<p>
|
|
This file is formatted as follows:
|
|
|
|
<tscreen><verb>
|
|
name addresss description
|
|
</verb></tscreen>
|
|
|
|
Where:
|
|
<descrip>
|
|
<tag>name</tag>is the text name that you wish to refer to the port by.
|
|
<tag>address</tag>is the 10 digit Rose address you wish to assign to this port.
|
|
<tag>description</tag>is a free text description of the port.
|
|
</descrip>
|
|
|
|
An example would look something like the following:
|
|
|
|
<tscreen><verb>
|
|
rose 5050294760 Rose Port
|
|
</verb></tscreen>
|
|
|
|
Note that Rose will use the default callsign/ssid configured on each
|
|
AX.25 port unless you specify otherwise.
|
|
<p>
|
|
To configure a seperate callsign/ssid for Rose to use on each port you
|
|
use the <em/rsparms/ command as follows:
|
|
|
|
<tscreen><verb>
|
|
# /usr/sbin/rsprams -call VK2KTJ-10
|
|
</verb></tscreen>
|
|
|
|
This example would make Linux listen for and use the callsign/ssid
|
|
<tt/VK2KTJ-10/ on all of the configured AX.25 ports for Rose calls.
|
|
|
|
<sect1><heading>Creating the Rose Network device.
|
|
<p>
|
|
When you have created the <tt>/etc/ax25/rsports</tt> file you may create the
|
|
Rose device in much the same way as you did for the AX.25 devices.
|
|
This time you use the <em/rsattach/ command. The <em/rsattach/ command creates
|
|
network devices named `<tt/rose[0-5]/'. The first time you use the
|
|
<em/rsattach/ command it create the `<tt/rose0/' device, the second time
|
|
it creates the `<tt/rose1/' device etc. For example:
|
|
|
|
<tscreen><verb>
|
|
# rsattach rose
|
|
</verb></tscreen>
|
|
|
|
This command would start the Rose device (<tt/rose0/) configured with the
|
|
details specified in the <tt>/etc/ax25/rsports</tt> file for the entry
|
|
named `<tt/rose/'.
|
|
|
|
<sect1><heading>Configuring Rose Routing
|
|
<p>
|
|
The Rose protocol currently supports only static routing. The <em/rsparms/
|
|
utility allows you to configure your Rose routing table under Linux.
|
|
<p>
|
|
For example:
|
|
<tscreen><verb>
|
|
# rsparms -nodes add 5050295502 radio vk2xlz
|
|
</verb></tscreen>
|
|
would add a route to Rose node <tt/5050295502/ via an AX.25 port named
|
|
`<tt/radio/' in your <tt>/etc/ax25/axports</tt> file to a neighbour
|
|
with the callsign <tt/VK2XLZ/.
|
|
<p>
|
|
You may specify a route with a mask to capture a number of Rose destinations
|
|
into a single routing entry. The syntax looks like:
|
|
<tscreen><verb>
|
|
# rsparms -nodes add 5050295502/4 radio vk2xlz
|
|
</verb></tscreen>
|
|
which would be identical to the previous example except that it would match
|
|
any destination address that matched the first four digits supplied, in this
|
|
case any address commencing with the digits <tt/5050/. An alternate form
|
|
for this command is:
|
|
<tscreen><verb>
|
|
# rsparms -nodes add 5050/4 radio vk2xlz
|
|
</verb></tscreen>
|
|
which is probably the less ambiguous form.
|
|
|
|
<sect><heading>Making AX.25/NetRom/Rose calls.
|
|
<p>
|
|
Now that you have all of your AX.25, NetRom and Rose interfaces configured
|
|
and active, you should be able to make test calls.
|
|
<p>
|
|
The AX25 Utilities package includes a program called `<em/call/' which
|
|
is a splitscreen terminal program for AX.25, NetRom and Rose.
|
|
<p>
|
|
A simple AX.25 call would look like:
|
|
<tscreen><verb>
|
|
/usr/bin/call radio VK2DAY via VK2SUT
|
|
</verb></tscreen>
|
|
|
|
A simple NetRom call to a node with an alias of <tt/SUNBBS/ would look like:
|
|
<tscreen><verb>
|
|
/usr/bin/call netrom SUNBBS
|
|
</verb></tscreen>
|
|
|
|
A simple Rose call to <tt/HEARD/ at node <tt/5050882960/ would look like:
|
|
<tscreen><verb>
|
|
/usr/bin/call rose HEARD 5050882960
|
|
</verb></tscreen>
|
|
|
|
Note: you must tell call which port you wish to make the call on,
|
|
as the same destination node might be reachable on any of the ports you have
|
|
configured.
|
|
<p>
|
|
The <em>call</em> program is a linemode terminal program for making
|
|
AX.25 calls. It recognises lines that start with `<tt>~</tt>' as command lines.
|
|
The `<tt>~.</tt>' command will close the connection.
|
|
<p>
|
|
Please refer to the man page in <tt>/usr/man</tt> for more information.
|
|
|
|
<sect><heading>Configuring Linux to accept Packet connections.
|
|
<p>
|
|
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 <em/pms/ program
|
|
included in the AX25 utilities, a more complex example is the <em/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.
|
|
<p>
|
|
The <em/ax25d/ program is similar to the <em/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.
|
|
|
|
<sect1><heading>Creating the <tt>/etc/ax25/ax25d.conf</tt> file.
|
|
<p>
|
|
This file is the configuration file for the <em>ax25d</em> AX.25 daemon which
|
|
handles incoming AX.25, NetRom and Rose connections.
|
|
<p>
|
|
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.
|
|
<p>
|
|
The general format of the <tt>ax25d.conf</tt> file is as follows:
|
|
|
|
<tscreen><verb>
|
|
# 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>
|
|
</verb></tscreen>
|
|
|
|
Where:
|
|
<descrip>
|
|
<tag>#</tag>at the start of a line marks a comment and is completely ignored
|
|
by the <em>ax25d</em> program.
|
|
<tag><port_name></tag>is the name of the AX.25, NetRom or Rose
|
|
port as specified in the <tt>/etc/ax25/axports</tt>, <tt>/etc/ax25/nrports</tt>
|
|
and <tt>/etc/ax25/rsports</tt> files. The name of the port is surrounded
|
|
by the `<tt/[]/' brackets if it is an AX.25 port, the `<tt/<>/' brackets
|
|
if it is a NetRom port, or the `<tt/{}/' brackets if it is a Rose port.
|
|
There is an alternate form for this field, and that is use prefix the port name
|
|
with `<tt>callsign/ssid via</tt>' to indicate that you wish accept calls to the
|
|
callsign/ssid via this interface. The example should more clearly illustrate
|
|
this.
|
|
<tag><peer></tag>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.
|
|
<tag>window</tag>is the AX.25 Window parameter (K) or MAXFRAME parameter for
|
|
this configuration.
|
|
<tag>T1</tag>is the Frame retransmission (T1) timer in half second units.
|
|
<tag>T2</tag>is the amount of time the AX.25 software will wait for another
|
|
incoming frame before preparing a response in 1 second units.
|
|
<tag>T3</tag>is the amount of time of inactivity before the AX.25 software
|
|
will disconnect the session in 1 second units.
|
|
<tag>idle</tag>is the idle timer value in seconds.
|
|
<tag>N2</tag>is the number of consecutive retransmissions that will occur
|
|
before the connection is closed.
|
|
<tag><mode></tag>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.
|
|
<descrip>
|
|
<tag>u/U</tag>UTMP - currently unsupported.
|
|
<tag>v/V</tag>Validate call - currently unsupported.
|
|
<tag>q/Q</tag>Quiet - Don't log connection
|
|
<tag>n/N</tag>check NetRom Neighbour - currently unsupported.
|
|
<tag>d/D</tag>Disallow Digipeaters - Connections must be direct, not digipeated.
|
|
<tag>l/L</tag>Lockout - Don't allow connection.
|
|
<tag>*/0</tag>marker - place marker, no mode set.
|
|
</descrip>
|
|
<tag><uid></tag>is the userid that the program to be run to support the
|
|
connection should be run as.
|
|
<tag><cmd></tag>is the full pathname of the command to be run, with no
|
|
arguments specified.
|
|
<tag><cmd-name></tag>is the text that should appear in a <em>ps</em> as
|
|
the command name running (normally the same as <cmd> except without the
|
|
directory path information.
|
|
<tag><arguments></tag>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:
|
|
<descrip>
|
|
<tag>%d</tag>Name of the port the connection was received on.
|
|
<tag>%U</tag>AX.25 callsign of the connected party without the SSID, in
|
|
uppercase.
|
|
<tag>%u</tag>AX.25 callsign of the connected party without the SSID, in
|
|
lowercase.
|
|
<tag>%S</tag>AX.25 callsign of the connected party with the SSID, in
|
|
uppercase.
|
|
<tag>%s</tag>AX.25 callsign of the connected party with the SSID, in
|
|
lowercase.
|
|
<tag>%P</tag>AX.25 callsign of the remote node that the connection came
|
|
in from without the SSID, in uppercase.
|
|
<tag>%p</tag>AX.25 callsign of the remote node that the connection came
|
|
in from without the SSID, in lowercase.
|
|
<tag>%R</tag>AX.25 callsign of the remote node that the connection came
|
|
in from with the SSID, in uppercase.
|
|
<tag>%r</tag>AX.25 callsign of the remote node that the connection came
|
|
in from with the SSID, in lowercase.
|
|
</descrip>
|
|
</descrip>
|
|
|
|
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.
|
|
<p>
|
|
There are two special lines in the paragraph, one starts with the string
|
|
`<tt>parameters</tt>' and the other starts with the string `<tt>default</tt>'
|
|
(yes there is a difference). These lines serve special functions.
|
|
<p>
|
|
The `<tt>default</tt>' 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 `<tt>default</tt>'
|
|
rule. If you don't have a `<tt>default</tt>' rule, then any connections not
|
|
matching any specific rule will be disconnected immediately without notice.
|
|
<p>
|
|
The `<tt>parameters</tt>' 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
|
|
`<tt>parameters</tt>' 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 `<tt>parameters</tt>' entry. The trap is that the these defaults
|
|
apply <bf>only</bf> to those rules <bf>below</bf> the `<tt>parameters</tt>'
|
|
line, not to those above. You may have more than one `<tt>parameters</tt>' rule
|
|
per interface definition, and in this way you may create groups of default
|
|
configurations. It is important to note that the `<tt>parameters</tt>' rule
|
|
does not allow you to set the `<tt/uid/' or `<tt/command/' fields.
|
|
|
|
<sect1><heading>A simple example <tt>ax25d.conf</tt> file.
|
|
<p>
|
|
Ok, an illustrative example:
|
|
|
|
<tscreen><verb>
|
|
# 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
|
|
</verb></tscreen>
|
|
|
|
This example says that anybody attempting to connect to the callsign
|
|
`<tt/VK2KTJ-0/' heard on the AX.25 port called `<tt/radio/' will have
|
|
the following rules applied:
|
|
<p>
|
|
Anyone whose callsign is set to `NOCALL' should be locked out, note the
|
|
use of mode `L'.
|
|
<p>
|
|
The <tt/parameters/ line changes two parameters from the kernel defaults
|
|
(Window and T1) and will run the <em>/usr/sbin/axspawn</em> program for
|
|
them. Any copies of <em>/usr/sbin/axspawn</em> run this way will appear
|
|
as <em/axspawn/ in a <em/ps/ listing for convenience. The next two
|
|
lines provide definitions for two stations who will receive those permissions.
|
|
<p>
|
|
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
|
|
<em/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
|
|
<tt/VK2KTJ/. (See the `Configuring the PMS' section below for more details).
|
|
<p>
|
|
The next configuration accepts calls to <tt/VK2KTJ-1/ via the <tt/radio/
|
|
port. It runs the <em/node/ program for everybody that connects to it.
|
|
<p>
|
|
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 `<tt/netrom/' will
|
|
have the <em/node/ program run for them, unless they have a callsign of
|
|
`<tt/NOCALL/' in which case they will be locked out.
|
|
<p>
|
|
The last two configurations are for incoming Rose connections. The first
|
|
for people who have placed calls to `<tt/vk2ktj-0/' and the second for
|
|
`<tt/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.
|
|
<p>
|
|
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 <tt/ax25d.conf/ <em/man/ page. A more detailed
|
|
example is included in the <tt>ax25-utils</tt> package that might be useful
|
|
to you too.
|
|
|
|
<sect1><heading>Starting <em>ax25d</em>
|
|
<p>
|
|
When you have the two configuration files completed you start <em>ax25d</em>
|
|
with the command:
|
|
|
|
<tscreen><verb>
|
|
# /usr/sbin/ax25d
|
|
</verb></tscreen>
|
|
|
|
When this is run people should be able to make AX.25 connections to your
|
|
Linux machine. Remember to put the <tt>ax25d</tt> command in your <em>rc</em>
|
|
files so that it is started automatically when you reboot each time.
|
|
|
|
<sect><heading>Configuring the <em>node</em> software.
|
|
<p>
|
|
The <em>node</em> software was developed by Tomi Manninen
|
|
<tt><tomi.manninen@hut.fi></tt> and was based on the original PMS program.
|
|
It provides a fairly complete and flexible node capability that is easily
|
|
configured. It allows users once they are connected to make Telnet, NetRom,
|
|
Rose, and AX.25 connections out and to obtain various sorts of information such
|
|
as Finger, Nodes and Heard lists etc. You can configure the node to execute
|
|
any Linux command you wish fairly simply.
|
|
<p>
|
|
The node would normally be invoked from the <em>ax25d</em> program although
|
|
it is also capable of being invoked from the TCP/IP <em>inetd</em> program to
|
|
allow users to telnet to your machine and obtain access to it, or by running
|
|
it from the command line.
|
|
|
|
<sect1><heading>Creating the <tt>/etc/ax25/node.conf</tt> file.
|
|
<p>
|
|
The <tt>node.conf</tt> file is where the main configuration of the node
|
|
takes place. It is a simple text file and its format is as follows:
|
|
|
|
<tscreen><verb>
|
|
# /etc/ax25/node.conf
|
|
# configuration file for the node(8) program.
|
|
#
|
|
# Lines beginning with '#' are comments and are ignored.
|
|
|
|
# Hostname
|
|
# Specifies the hostname of the node machine
|
|
hostname radio.gw.vk2ktj.ampr.org
|
|
|
|
# Local Network
|
|
# allows you to specify what is consider 'local' for the
|
|
# purposes of permission checking using nodes.perms.
|
|
localnet 44.136.8.96/29
|
|
|
|
# Hide Ports
|
|
# If specified allows you to make ports invisible to users. The
|
|
# listed ports will not be listed by the (P)orts command.
|
|
hiddenports rose netrom
|
|
|
|
# Node Identification.
|
|
# this will appear in the node prompt
|
|
NodeId LINUX:VK2KTJ-9
|
|
|
|
# NetRom port
|
|
# This is the name of the netrom port that will be used for
|
|
# outgoing NetRom connections from the node.
|
|
NrPort netrom
|
|
|
|
# Node Idle Timeout
|
|
# Specifies the idle time for connections to this node in seconds.
|
|
idletimout 1800
|
|
|
|
# Connection Idle Timeout
|
|
# Specifies the idle timer for connections made via this node in
|
|
# seconds.
|
|
conntimeout 1800
|
|
|
|
# Reconnect
|
|
# Specifies whether users should be reconnected to the node
|
|
# when their remote connections disconnect, or whether they
|
|
# should be disconnected complete.
|
|
reconnect on
|
|
|
|
# Command Aliases
|
|
# Provide a way of making complex node commands simple.
|
|
alias CONV "telnet vk1xwt.ampr.org 3600"
|
|
alias BBS "connect radio vk2xsb"
|
|
|
|
# Externam Command Aliases
|
|
# Provide a means of executing external commands under the node.
|
|
# extcmd <cmdname> <flag> <userid> <command>
|
|
# Flag == 1 is the only implemented function.
|
|
# <command> is formatted as per ax25d.conf
|
|
extcmd PMS 1 root /usr/sbin/pms pms -u %U -o VK2KTJ
|
|
|
|
# Logging
|
|
# Set logging to the system log. 3 is the noisiest, 0 is disabled.
|
|
loglevel 3
|
|
|
|
# The escape character
|
|
# 20 = (Control-T)
|
|
EscapeChar 20
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading>Creating the <tt>/etc/ax25/node.perms</tt> file.
|
|
<p>
|
|
The <em>node</em> allows you to assign permissions to users. These permissions
|
|
allow you to determine which users should be allowed to make use of options
|
|
such as the (T)elnet, and (C)onnect commands, for example, and which
|
|
shouldn't. The <tt>node.perms</tt> file is where this information is stored
|
|
and contains five key fields. For all fields an asterisk `*'
|
|
character matches anything. This is useful for building default rules.
|
|
<p>
|
|
<descrip>
|
|
<tag>user</tag>
|
|
The first field is the callsign or user to which the permissions should apply.
|
|
Any SSID value is ignored, so you should just place the base callsign here.
|
|
<tag>method</tag>
|
|
Each protocol or access method is also given permissions. For example you
|
|
might allow users who have connected via AX.25 or NetRom to use the (C)onnect
|
|
option, but prevent others, such as those who are telnet connected from a
|
|
non-local node from having access to it. The second field therefore allows
|
|
you to select which access method this permissions rule should apply to.
|
|
The access methods allowed are:
|
|
<tscreen><verb>
|
|
method description
|
|
------ -----------------------------------------------------------
|
|
ampr User is telnet connected from an amprnet address (44.0.0.0)
|
|
ax25 User connected by AX.25
|
|
host User started node from command line
|
|
inet user is telnet connected from a non-loca, non-ampr address.
|
|
local User is telnet connected from a 'local' host
|
|
netrom User connected by NetRom
|
|
rose User connected by Rose
|
|
* User connected by any means.
|
|
</verb></tscreen>
|
|
<tag>port</tag>
|
|
For AX.25 users you can control permissions on a port by port basis too if you
|
|
choose. This allows you to determine what AX.25 are allowed to do based on
|
|
which of your ports they have connected to. The third field contains the port
|
|
name if you are using this facility. This is useful only for AX.25 connections.
|
|
<tag>password</tag>
|
|
You may optionally configure the node so that it prompts users to enter a
|
|
password when they connect. This might be useful to help protect specially
|
|
configured users who have high authority levels. If the fourth field is
|
|
set then its value will be the password that will be accepted.
|
|
<tag>permissions</tag>
|
|
The permissions field is the final field in each entry in the file.
|
|
The permissions field is coded as a bit field, with each facility having a bit
|
|
value which if set allows the option to be used and if not set prevents the
|
|
facility being used. The list of controllable facilities and their
|
|
corresponding bit values are:
|
|
|
|
<tscreen><verb>
|
|
value description
|
|
----- -------------------------------------------------
|
|
1 Login allowed.
|
|
2 AX25 (C)onnects allowed.
|
|
4 NetRom (C)onnects allowed.
|
|
8 (T)elnet to local hosts allowed.
|
|
16 (T)elnet to amprnet (44.0.0.0) hosts allowed.
|
|
32 (T)elnet to non-local, non-amprnet hosts allowed.
|
|
64 Hidden ports allowed for AX.25 (C)onnects.
|
|
128 Rose (C)onnects allowed.
|
|
</verb></tscreen>
|
|
To code the permissions value for a rule, simply take each of the permissions
|
|
you want that user to have and add their values together. The resulting number
|
|
is what you place in field five.
|
|
</descrip>
|
|
<p>
|
|
A sample <tt>nodes.perms</tt> might look like:
|
|
|
|
<tscreen><verb>
|
|
# /etc/ax25/node.perms
|
|
#
|
|
# The node operator is VK2KTJ, has a password of 'secret' and
|
|
# is allowed all permissions by all connection methods
|
|
vk2ktj * * secret 255
|
|
|
|
# The following users are banned from connecting
|
|
NOCALL * * * 0
|
|
PK232 * * * 0
|
|
PMS * * * 0
|
|
|
|
# INET users are banned from connecting.
|
|
* inet * * 0
|
|
|
|
# AX.25, NetRom, Local, Host and AMPR users may (C)onnect and (T)elnet
|
|
# to local and ampr hosts but not to other IP addresses.
|
|
* ax25 * * 159
|
|
* netrom * * 159
|
|
* local * * 159
|
|
* host * * 159
|
|
* ampr * * 159
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading>Configuring <em>node</em> to run from <em>ax25d</em>
|
|
<p>
|
|
The <em>node</em> program would normally be run by the <em>ax25d</em> program.
|
|
To do this you need to add appropriate rules to the
|
|
<tt>/etc/ax25/ax25d.conf</tt> file. In my configuration I wanted users
|
|
to have a choice of either connecting to the <em>node</em> or connecting to
|
|
other services. <em>ax25d</em> allows you to do this by cleverly creating
|
|
creating port aliases. For example, given the <em>ax25d</em> configuration
|
|
presented above, I want to configure <em>node</em> so that all users who connect
|
|
to <tt>VK2KTJ-1</tt> are given the node. To do this I add the following to
|
|
my <tt>/etc/ax25/ax25d.conf</tt> file:
|
|
<tscreen><verb>
|
|
[vk2ktj-1 via radio]
|
|
default * * * * * 0 root /usr/sbin/node node
|
|
</verb></tscreen>
|
|
This says that the Linux kernel code will answer any connection requests for
|
|
the callsign `<tt/VK2KTJ-1/' heard on the AX.25 port named `<tt/radio/', and
|
|
will cause the <em>node</em> program to be run.
|
|
|
|
<sect1><heading>Configuring <em>node</em> to run from <em>inetd</em>
|
|
<p>
|
|
If you want users to be able to telnet a port on your machine and obtain
|
|
access to the <em>node</em> you can go this fairly easily. The first thing
|
|
to decide is what port users should connect to. In this example I've
|
|
arbitrarily chosen port 4000, though Tomi gives details on how you could
|
|
replace the normal telnet daemon with the <em>node</em> in his documentation.
|
|
<p>
|
|
You need to modify two files.<p>
|
|
To <tt>/etc/services</tt> you should add:
|
|
<tscreen><verb>
|
|
node 3694/tcp #OH2BNS's node software
|
|
</verb></tscreen>
|
|
and to <tt>/etc/inetd.conf</tt> you should add:
|
|
<tscreen><verb>
|
|
node stream tcp nowait root /usr/sbin/node node
|
|
</verb></tscreen>
|
|
When this is done, and you have restarted the <em>inetd</em> program any user
|
|
who telnet connects to port 3694 of your machine will be prompted to login
|
|
and if configured, their password and then they will be connected to the
|
|
<em>node</em>.
|
|
|
|
<sect><heading>Configuring <em>axspawn</em>.
|
|
<p>
|
|
The <em/axspawn/ program is a simple program that allows AX.25 stations
|
|
who connect to be logged in to your machine. It may be invoked from the
|
|
<em/ax25d/ program as described above in a manner similar to the <em/node/
|
|
program. To allow a user to log in to your
|
|
machine you should add a line similar to the following into your
|
|
<tt>/etc/ax25/ax25d.conf</tt> file:
|
|
<tscreen><verb>
|
|
default * * * * * 1 root /usr/sbin/axspawn axspawn %u
|
|
</verb></tscreen>
|
|
If the line ends in the <tt/+/ character then the connecting user must
|
|
hit return before they will be allowed to login. The default is to not wait.
|
|
Any individual host configurations that follow this line will have the
|
|
<em/axspawn/ program run when they connect. When <em/axspawn/ is
|
|
run it first checks that the command line argument it is supplied is a legal
|
|
callsign, strips the SSID, then it checks that <tt>/etc/passwd</tt> file to
|
|
see if that user has an account configured. If there is an account, and the
|
|
password is either <tt/""/ (null) or <tt/+/ then the user is logged
|
|
in, if there is anything in the password field the user is prompted to enter
|
|
a password. If there is not an existing account in the <tt>/etc/passwd</tt>
|
|
file then <em/axspawn/ may be configured to automatically create one.
|
|
|
|
<sect1><heading>Creating the <tt>/etc/ax25/axspawn.conf</tt> file.
|
|
<p>
|
|
You can alter the behaviour of <em/axspawn/ in various ways by use of
|
|
the <tt>/etc/ax25/axspawn.conf</tt> file. This file is formatted as
|
|
follows:
|
|
<tscreen><verb>
|
|
# /etc/ax25/axspawn.conf
|
|
#
|
|
# allow automatic creation of user accounts
|
|
create yes
|
|
#
|
|
# guest user if above is 'no' or everything else fails. Disable with "no"
|
|
guest no
|
|
#
|
|
# group id or name for autoaccount
|
|
group ax25
|
|
#
|
|
# first user id to use
|
|
first_uid 2001
|
|
#
|
|
# maximum user id
|
|
max_uid 3000
|
|
#
|
|
# where to add the home directory for the new users
|
|
home /home/ax25
|
|
#
|
|
# user shell
|
|
shell /bin/bash
|
|
#
|
|
# bind user id to callsign for outgoing connects.
|
|
associate yes
|
|
</verb></tscreen>
|
|
|
|
The eight configurable characteristics of <em/axspawn/ are as follows:
|
|
|
|
<descrip>
|
|
<tag>#</tag>indicates a comment.
|
|
<tag>create</tag>if this field is set to <tt>yes</tt> then <em>axspawn</em>
|
|
will attempt to automatically create a user account for any user who connects
|
|
and does not already have an entry in the <tt>/etc/passwd</tt> file.
|
|
<tag>guest</tag>this field names the login name of the account that will
|
|
be used for people who connect who do not already have accounts if
|
|
<em>create</em> is set to <tt>no</tt>. This is usually <tt>ax25</tt> or
|
|
<tt>guest</tt>.
|
|
<tag>group</tag>this field names the group name that will be used for any
|
|
users who connect and do not already have an entry in the <tt>/etc/passwd</tt>
|
|
file.
|
|
<tag>first_uid</tag>this is the number of the first userid that will be
|
|
automatically created for new users.
|
|
<tag>max_uid</tag>this is the maximum number that will be used for the userid
|
|
of new users.
|
|
<tag>home</tag>this is the home (login) directory of new users.
|
|
<tag>shell</tag>this is the login shell of any new users.
|
|
<tag>associate</tag>this flag indicates whether outgoing AX.25 connections
|
|
made by this user after they login will use their own callsign, or your
|
|
stations callsign.
|
|
</descrip>
|
|
|
|
<sect><heading>Configuring the <em>pms</em>
|
|
<p>
|
|
The <em>pms</em> program is an implementation of a simple personal message
|
|
system. It was originally written by Alan Cox. Dave Brown, N2RJT,
|
|
<tt><dcb@vectorbd.com></tt> has taken on further development of it.
|
|
At present it is still very simple, supporting only the ability to send
|
|
mail to the owner of the system and to obtain some limited system information
|
|
but Dave is working to expand its capability to make it more useful.
|
|
<p>
|
|
After that is done there are a couple of simple files that you should create
|
|
that give users some information about the system and then you need to add
|
|
appropriate entries into the <tt/ax25d.conf/ file so that connected users
|
|
are presented with the PMS.
|
|
<p>
|
|
|
|
<sect1><heading>Create the <tt>/etc/ax25/pms.motd</tt> file.
|
|
<p>
|
|
The <tt>/etc/ax25/pms.motd</tt> file contains the `message of the day' that
|
|
users will be presented with after they connect and receive the usual BBS
|
|
id header. The file is a simple text file, any text you include in this file
|
|
will be sent to users.
|
|
|
|
<sect1><heading>Create the <tt>/etc/ax25/pms.info</tt> file.
|
|
<p>
|
|
The <tt>/etc/ax25/pms.info</tt> file is also a simple text file in which
|
|
you would put more detailed information about your station or configuration.
|
|
This file is presented to users in response to their issuing of the
|
|
<tt>Info</tt> command from the <tt>PMS></tt> prompt.
|
|
|
|
<sect1><heading>Associate AX.25 callsigns with system users.
|
|
<p>
|
|
When a connected user sends mail to an AX.25 callsign, the <em>pms</em> expects
|
|
that callsign to be mapped, or associated with a real system user on your
|
|
machine. This is described in a section of its own.
|
|
|
|
<sect1><heading>Add the PMS to the <tt>/etc/ax25/ax25d.conf</tt> file.
|
|
<p>
|
|
Adding the <em>pms</em> to your <tt>ax25d.conf</tt> file is very simple.
|
|
There is one small thing you need to think about though. Dave has added command
|
|
line arguments to the PMS to allow it to handle a number of different text
|
|
end-of-line conventions. AX.25 and NetRom by convention expect the end-of-line
|
|
to be <em>carriage return, linefeed</em> while the standard unix end-of-line is
|
|
just <em>newline</em>. So, for example, if you wanted to add an entry that
|
|
meant that the default action for a connection received on an AX.25 port is
|
|
to start the PMS then you would add a line that looked something like:
|
|
|
|
<tscreen><verb>
|
|
default 1 10 5 100 5 0 root /usr/sbin/pms pms -a -o vk2ktj
|
|
</verb></tscreen>
|
|
|
|
This simply runs the <em>pms</em> program, telling it that it is an AX.25
|
|
connection it is connected to and that the PMS owner is <tt>vk2ktj</tt>.
|
|
Check the <em>man</em> page for what you should specify for other connection
|
|
methods.
|
|
|
|
<sect1><heading>Test the PMS.
|
|
<p>
|
|
To test the PMS, you can try the following command from the command line:
|
|
<verb>
|
|
# /usr/sbin/pms -u vk2ktj -o vk2ktj
|
|
</verb>
|
|
Substitute your own callsign for mine and this will run the pms, telling it
|
|
that it is to use the unix end-of-line convention, and that user logging in
|
|
is <tt>vk2ktj</tt>. You can do all the things connected users can.
|
|
<p>
|
|
Additionally you might try getting some other node to connect to you to
|
|
confirm that your <tt>ax25d.conf</tt> configuration works.
|
|
|
|
<sect><heading>Configuring the <em>user_call</em> programs.
|
|
<p>
|
|
The `<em/user_call/' programs are really called: <em/ax25_call/ and
|
|
<em/netrom_call/. They are very simple programs designed to be called from
|
|
<em/ax25d/ to automate network connections to remote hosts. They may of
|
|
course be called from a number of other places such as shell scripts or
|
|
other daemons such as the <em/node/ program.
|
|
<p>
|
|
They are like a very simple <em/call/ program. They don't do any meddling
|
|
with the data at all, so the end of line handling you'll have to worry about
|
|
yourself.
|
|
<p>
|
|
Let's start with an example of how you might use them. Imagine you have
|
|
a small network at home and that you have one linux machine acting as your
|
|
Linux radio gateway and another machine, lets say a BPQ node connected to it
|
|
via an ethernet connection.
|
|
<p>
|
|
Normally if you wanted radio users to be able to connect
|
|
to the BPQ node they would either have to digipeat through your linux node,
|
|
or connect to the node program on your linux node and then connect from it.
|
|
The <em/ax25_call/ program can simplify this if it is called from the
|
|
<em/ax25d/ program.
|
|
<p>
|
|
Imagine the BPQ node has the callsign <tt/VK2KTJ-9/ and that the linux
|
|
machine has the AX.25/ethernet port named `<tt/bpq/'. Let us also imagine
|
|
the Linux gateway machine has a radio port called `<tt/radio/'.
|
|
<p>
|
|
An entry in the <tt>/etc/ax25/ax25d.conf</tt> that looked like:
|
|
<tscreen><verb>
|
|
[VK2KTJ-1 via radio]
|
|
default * * * * * * *
|
|
root /usr/sbin/ax25_call ax25_call bpq %u vk2ktj-9
|
|
</verb></tscreen>
|
|
would enable users to connect direct to `<tt/VK2KTJ-1/' which would actually
|
|
be the Linux <em/ax25d/ daemon and then be automatically switched to an AX.25
|
|
connection to `<tt/VK2KTJ-9/' via the `<tt/bpq/' interface.
|
|
<p>
|
|
There are all sorts of other possible configurations that you might try.
|
|
The `<em/netrom_call/' and `<em/rose_call/' utilities work in
|
|
similar ways. One amateur has used this utility to make connections to a
|
|
remote BBS easier. Normally the users would have to manually enter a long
|
|
connection string to make the call so he created an entry that made the BBS
|
|
appear as though it were on the local network by having his <em/ax25d/ proxy
|
|
the connection to the remote machine.
|
|
|
|
<sect><heading>Configuring the Rose Uplink and Downlink commands
|
|
<p>
|
|
If you are familiar with the ROM based Rose implementation you will be
|
|
familiar with the method by which AX.25 users make calls across a Rose
|
|
network. If a users local Rose node has the callsign <tt/VK2KTJ-5/ and
|
|
the AX.25 user wants to connect to <tt/VK5XXX/ at remote Rose node
|
|
<tt/5050882960/ then they would issue the command:
|
|
|
|
<tscreen><verb>
|
|
c vk5xxx v vk2ktj-5 5050 882960
|
|
</verb></tscreen>
|
|
|
|
At the remote node, <tt/VK5XXX/ would see an incoming connection with the
|
|
local AX.25 users callsign and being digipeated via the remote Rose nodes
|
|
callsign.
|
|
<p>
|
|
The Linux Rose implementation does not support this capability in the kernel,
|
|
but there are two application programs called <em/rsuplnk/ and <em/rsdwnlnk/
|
|
which perform this function.
|
|
|
|
<sect1><heading>Configuring a Rose downlink
|
|
<p>
|
|
To configure your Linux machine to accept a Rose connection and establish an
|
|
AX.25 connection to any destination callsign that is not being listened for
|
|
on your machine you need to add an entry to your <tt>/etc/ax25/ax25d.conf</tt>
|
|
file. Normally you would configure this entry to be the default behaviour for
|
|
incoming Rose connections. For example you might have Rose listeners operating
|
|
for destinations like <tt/NODE-0/ or <tt/HEARD-0/ that you wish to handle
|
|
locally, but for all other destination calls you may want to pass them to
|
|
the <em/rsdwnlink/ command and assume they are AX.25 users.
|
|
<p>
|
|
A typical configuration would look like:
|
|
|
|
<tscreen><verb>
|
|
#
|
|
{* via rose}
|
|
NOCALL * * * * * * L
|
|
default * * * * * * - root /usr/sbin/rsdwnlnk rsdwnlnk 4800 vk2ktj-5
|
|
#
|
|
</verb></tscreen>
|
|
|
|
With this configuration any user who established a Rose connection to your
|
|
Linux nodes address with a destination call of something that you were not
|
|
specifically listening for would be converted into an AX.25 connection on the
|
|
AX.25 port named <tt/4800/ with a digipeater path of <tt/VK2KTJ-5/.
|
|
|
|
<sect1><heading>Configuring a Rose uplink
|
|
<p>
|
|
To configure your Linux machine to accept AX.25 connections in the same way
|
|
that a ROM Rose node would you must add an entry into your
|
|
<tt>/etc/ax25/ax25d.conf</tt> file that looks similar to the following:
|
|
|
|
<tscreen><verb>
|
|
#
|
|
[VK2KTJ-5* via 4800]
|
|
NOCALL * * * * * * L
|
|
default * * * * * * - root /usr/sbin/rsuplnk rsuplnk rose
|
|
#
|
|
</verb></tscreen>
|
|
|
|
Note the special syntax for the local callsign. The `<tt/*/' character
|
|
indicates that the application should be invoked if the callsign is heard in
|
|
the digipeater path of a connection.
|
|
<p>
|
|
This configuration would allow an AX.25 user to establish Rose calls using the
|
|
example connect sequence presented in the introduction. Anybody attempting to
|
|
digipeat via <tt/VK2KTJ-5/ on the AX.25 port named <tt/4800/ would be handled
|
|
by the <em/rsuplnk/ command.
|
|
|
|
<sect><heading>Associating AX.25 callsigns with Linux users.
|
|
<p>
|
|
There are a number of situations where it is highly desirable to associate
|
|
a callsign with a linux user account. One example might be where a number of
|
|
amateur radio operators share the same linux machine and wish to use their
|
|
own callsign when making calls. Another is the case of PMS users wanting to
|
|
talk to a particular user on your machine.
|
|
<p>
|
|
The AX.25 software provides a means of managing this association of linux
|
|
user account names with callsigns. We've mentioned it once already in the PMS
|
|
section, but I'm spelling it out here to be sure you don't miss it.
|
|
<p>
|
|
You make the association with the <em>axparms</em> command. An example looks
|
|
like:
|
|
<tscreen><verb>
|
|
# axparms -assoc vk2ktj terry
|
|
</verb></tscreen>
|
|
This command associates that AX.25 callsign <tt>vk2ktj</tt> with the user
|
|
<tt>terry</tt> on the machine. So, for example, any mail for <tt>vk2ktj</tt>
|
|
on the <em>pms</em> will be sent to Linux account <tt>terry</tt>.
|
|
<p>
|
|
Remember to put these associations into your <em>rc</em> file so that they
|
|
are available each time your reboot.
|
|
<p>
|
|
<bf/Note/ you should never associate a callsign with the <tt/root/
|
|
account as this can cause configuration problems in other programs.
|
|
|
|
<sect><heading>The <tt>/proc/</tt> file system entries.
|
|
<p>
|
|
The <tt>/proc</tt> filesystem contains a number of files specifically
|
|
related to the AX25 and NetRom kernel software. These files are normally
|
|
used by the AX52 utilities, but they are plainly formatted so you may
|
|
be interested in reading them. The format is fairly easily understood so
|
|
I don't think much explanation will be necessary.
|
|
|
|
<descrip>
|
|
<tag>/proc/net/arp</tag>contains the list of Address Resolution Protocol
|
|
mappings of IP addresses to MAC layer protocol addresses. These can can AX.25,
|
|
ethernet or some other MAC layer protocol.
|
|
<tag>/proc/net/ax25</tag>contains a list of AX.25 sockets opened. These might
|
|
be listening for a connection, or active sessions.
|
|
<tag>/proc/net/ax25_bpqether</tag>contains the AX25 over ethernet BPQ
|
|
style callsign mappings.
|
|
<tag>/proc/net/ax25_calls</tag>contains the linux userid to callsign
|
|
mappings set my the <em/axparms -assoc/ command.
|
|
<tag>/proc/net/ax25_route</tag>contains AX.25 digipeater path
|
|
information.
|
|
<tag>/proc/net/nr</tag>contains a list of NetRom sockets opened. These might
|
|
be listening for a connection, or active sessions.
|
|
<tag>/proc/net/nr_neigh</tag>contains information about the NetRom
|
|
neighbours known to the NetRom software.
|
|
<tag>/proc/net/nr_nodes</tag>contains information about the NetRom
|
|
nodes known to the NetRom software.
|
|
<tag>/proc/net/rose</tag>contains a list of Rose sockets opened. These might
|
|
be listening for a connection, or active sessions.
|
|
<tag>/proc/net/rose_nodes</tag>contains a mapping of Rose destinations
|
|
to Rose neighbours.
|
|
<tag>/proc/net/rose_neigh</tag>contains a list of known Rose neighbours.
|
|
<tag>/proc/net/rose_routes</tag>contains a list of all established Rose
|
|
connections.
|
|
</descrip>
|
|
|
|
<sect><heading>AX.25, NetRom, Rose network programming.
|
|
<p>
|
|
Probably the biggest advantage of using the kernel based implementations of
|
|
the amateur packet radio protocols is the ease with which you can develop
|
|
applications and programs to use them.
|
|
<p>
|
|
While the subject of Unix Network Programming is outside the scope of this
|
|
document I will describe the elementary details of how you can make use of
|
|
the AX.25, NetRom and Rose protocols within your software.
|
|
<p>
|
|
<sect1><heading>The address families.
|
|
<p>
|
|
Network programming for AX.25, NetRom and Rose is quite similar to programming
|
|
for TCP/IP under Linux. The major differences being the address families used,
|
|
and the address structures that need to be mangled into place.
|
|
<p>
|
|
The address family names for AX.25, NetRom and Rose are <tt/AF_AX25/,
|
|
<tt/AF_NETROM/ and <tt/AF_ROSE/ respectively.
|
|
|
|
<sect1><heading>The header files.
|
|
<p>
|
|
You must always include the `<tt/ax25.h/' header file, and also the
|
|
`<tt/netrom.h/' or `<tt/rose.h/' header files if you are dealing with those
|
|
protocols. Simple top level skeletons would look something like the following:
|
|
<p>
|
|
For AX.25:
|
|
<tscreen><verb>
|
|
#include <ax25.h>
|
|
int s, addrlen = sizeof(struct full_sockaddr_ax25);
|
|
struct full_sockaddr_ax25 sockaddr;
|
|
sockaddr.fsa_ax25.sax25_family = AF_AX25
|
|
</verb></tscreen>
|
|
|
|
For NetRom:
|
|
<tscreen><verb>
|
|
#include <ax25.h>
|
|
#include <netrom.h>
|
|
int s, addrlen = sizeof(struct full_sockaddr_ax25);
|
|
struct full_sockaddr_ax25 sockaddr;
|
|
sockaddr.fsa_ax25.sax25_family = AF_NETROM;
|
|
</verb></tscreen>
|
|
|
|
For Rose:
|
|
<tscreen><verb>
|
|
#include <ax25.h>
|
|
#include <rose.h>
|
|
int s, addrlen = sizeof(struct sockaddr_rose);
|
|
struct sockaddr_rose sockaddr;
|
|
sockaddr.srose_family = AF_ROSE;
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading>Callsign mangling and examples.
|
|
<p>
|
|
There are routines within the <tt>lib/ax25.a</tt> library built in the
|
|
AX25 utilities package that manage the callsign conversions for you. You can
|
|
write your own of course if you wish.
|
|
<p>
|
|
The <em/user_call/ utilities are excellent examples from which to
|
|
work. The source code for them is included in the AX25 utilities package.
|
|
If you spend a little time working with those you will soon see that
|
|
ninety percent of the work is involved in just getting ready to open the
|
|
socket. Actually making the connection is easy, the preparation takes time.
|
|
<p>
|
|
The example are simple enough to not be very confusing. If you have any
|
|
questions, you should feel to direct them to the <tt/linux-hams/ mailing
|
|
list and someone there will be sure to help you.
|
|
|
|
<sect><heading>Some sample configurations.
|
|
<p>
|
|
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.
|
|
|
|
<sect1><heading>Small Ethernet LAN with Linux as a router to Radio LAN
|
|
<p>
|
|
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:
|
|
|
|
<tscreen><verb>
|
|
. . . . . .
|
|
--- .
|
|
| Network /---------\ . Network
|
|
| 44.136.8.96/29| | . 44.136.8/24 \ | /
|
|
| | Linux | . \|/
|
|
| | | . |
|
|
| eth0 | Router | . /-----\ /----------\ |
|
|
|---------------| |-----| TNC |----| Radio |---/
|
|
| 44.136.8.97 | and | . \-----/ \----------/
|
|
| | | sl0
|
|
| | Server | 44.136.8.5
|
|
| | | .
|
|
| | | .
|
|
| \_________/ .
|
|
--- . . . . . .
|
|
</verb></tscreen>
|
|
<tscreen><verb>
|
|
#!/bin/sh
|
|
# /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 127.0.0.1
|
|
/sbin/route add 127.0.0.1
|
|
echo " done."
|
|
|
|
echo -n " ethernet:"
|
|
/sbin/ifconfig eth0 44.136.8.97 netmask 255.255.255.248 \
|
|
broadcast 44.136.8.103 up
|
|
/sbin/route add 44.136.8.97 eth0
|
|
/sbin/route add -net 44.136.8.96 netmask 255.255.255.248 eth0
|
|
echo " done."
|
|
|
|
echo -n " AX.25: "
|
|
kissattach -i 44.136.8.5 -m 512 /dev/ttyS1 4800
|
|
ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.8.255
|
|
route add -host 44.136.8.5 sl0
|
|
route add -net 44.136.8.0 window 1024 sl0
|
|
|
|
echo -n " Netrom: "
|
|
nrattach -i 44.136.8.5 netrom
|
|
|
|
echo " Routing:"
|
|
/sbin/route add default gw 44.136.8.68 window 1024 sl0
|
|
echo " default route."
|
|
echo done.
|
|
|
|
# end
|
|
</verb></tscreen>
|
|
|
|
<tt>/etc/ax25/axports</tt>
|
|
<tscreen><verb>
|
|
# name callsign speed paclen window description
|
|
4800 VK2KTJ-0 4800 256 2 144.800 MHz
|
|
</verb></tscreen>
|
|
|
|
<tt>/etc/ax25/nrports</tt>
|
|
<tscreen><verb>
|
|
# name callsign alias paclen description
|
|
netrom VK2KTJ-9 LINUX 235 Linux Switch Port
|
|
</verb></tscreen>
|
|
|
|
<tt>/etc/ax25/nrbroadcast</tt>
|
|
<tscreen><verb>
|
|
# ax25_name min_obs def_qual worst_qual verbose
|
|
4800 1 120 10 1
|
|
</verb></tscreen>
|
|
|
|
<itemize>
|
|
<item>You must have IP_FORWARDING enabled in your kernel.
|
|
<item>The AX.25 configuration files are pretty much those used as examples
|
|
in the earlier sections, refer to those where necessary.
|
|
<item>I've chosen to use an IP address for my radio port that is not within
|
|
my home network block. I needn't have done so, I could have easily used
|
|
<tt>44.136.8.97</tt> for that port too.
|
|
<item><tt>44.136.8.68</tt> is my local IPIP encapsulated gateway and hence
|
|
is where I point my default route.
|
|
<item>Each of the machines on my Ethernet network have a route:
|
|
<tscreen><verb>
|
|
route add -net 44.0.0.0 netmask 255.0.0.0 \
|
|
gw 44.136.8.97 window 512 mss 512 eth0
|
|
</verb></tscreen>
|
|
The use of the <em>mss</em> and <em>window</em> parameters means that I can
|
|
get optimum performance from both local Ethernet and radio based connections.
|
|
<item>I also run my smail, http, ftp and other daemons on the router machine
|
|
so that it needs to be the only machine to provide others with facilities.
|
|
<item>The router machine is a lowly 386DX20 with a 20Mb harddrive and a very
|
|
minimal linux configuration.
|
|
</itemize>
|
|
|
|
<sect1><heading>IPIP encapsulated gateway configuration.
|
|
<p>
|
|
Linux is now very commonly used for TCP/IP encapsulated gateways around
|
|
the world. The new tunnel driver supports multiple encapsulated routes
|
|
and makes the older <em>ipip</em> daemon obsolete.
|
|
<p>
|
|
A typical configuration would look similar to the following.
|
|
|
|
<tscreen><verb>
|
|
. . . . . .
|
|
--- .
|
|
| Network /---------\ . Network
|
|
| 154.27.3/24 | | . 44.136.16/24 \ | /
|
|
| | Linux | . \|/
|
|
| | | . |
|
|
| eth0 | IPIP | . /-----\ /----------\ |
|
|
---|---------------| |-----| TNC |----| Radio |---/
|
|
| 154.27.3.20 | Gateway | . \-----/ \----------/
|
|
| | | sl0
|
|
| | | 44.136.16.1
|
|
| | | .
|
|
| | | .
|
|
| \_________/ .
|
|
--- . . . . . .
|
|
</verb></tscreen>
|
|
|
|
The configuration files of interest are:
|
|
|
|
<tscreen><verb>
|
|
# /etc/rc.net
|
|
# This file is a simple configuration that provides one KISS AX.25
|
|
# radio port, one Ethernet device, and utilises the kernel tunnel driver
|
|
# to perform the IPIP encapsulation/decapsulation
|
|
#
|
|
echo "/etc/rc.net"
|
|
echo " Configuring:"
|
|
#
|
|
echo -n " loopback:"
|
|
/sbin/ifconfig lo 127.0.0.1
|
|
/sbin/route add 127.0.0.1
|
|
echo " done."
|
|
#
|
|
echo -n " ethernet:"
|
|
/sbin/ifconfig eth0 154.27.3.20 netmask 255.255.255.0 \
|
|
broadcast 154.27.3.255 up
|
|
/sbin/route add 154.27.3.20 eth0
|
|
/sbin/route add -net 154.27.3.0 netmask 255.255.255.0 eth0
|
|
echo " done."
|
|
#
|
|
echo -n " AX.25: "
|
|
kissattach -i 44.136.16.1 -m 512 /dev/ttyS1 4800
|
|
/sbin/ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.16.255
|
|
/sbin/route add -host 44.136.16.1 sl0
|
|
/sbin/route add -net 44.136.16.0 netmask 255.255.255.0 window 1024 sl0
|
|
#
|
|
echo -n " tunnel:"
|
|
/sbin/ifconfig tunl0 44.136.16.1 mtu 512 up
|
|
#
|
|
echo done.
|
|
#
|
|
echo -n "Routing ... "
|
|
source /etc/ipip.routes
|
|
echo done.
|
|
#
|
|
# end.
|
|
</verb></tscreen>
|
|
|
|
and:
|
|
|
|
<tscreen><verb>
|
|
# /etc/ipip.routes
|
|
# This file is generated using the munge script
|
|
#
|
|
/sbin/route add -net 44.134.8.0 netmask 255.255.255.0 tunl0 gw 134.43.26.1
|
|
/sbin/route add -net 44.34.9.0 netmask 255.255.255.0 tunl0 gw 174.84.6.17
|
|
/sbin/route add -net 44.13.28.0 netmask 255.255.255.0 tunl0 gw 212.37.126.3
|
|
...
|
|
...
|
|
...
|
|
</verb></tscreen>
|
|
|
|
<tt>/etc/ax25/axports</tt>
|
|
<tscreen><verb>
|
|
# name callsign speed paclen window description
|
|
4800 VK2KTJ-0 4800 256 2 144.800 MHz
|
|
</verb></tscreen>
|
|
|
|
Some points to note here are:
|
|
|
|
<itemize>
|
|
<item>The new tunnel driver uses the <em>gw</em> field in the routing table
|
|
in place of the <em>pointopoint</em> parameter to specify the address of
|
|
the remote IPIP gateway. This is why it now supports multiple routes per
|
|
interface.
|
|
<item>You <bf>can</bf> configure two network devices with the same address.
|
|
In this example both the <tt>sl0</tt> and the <tt>tunl0</tt> devices have
|
|
been configured with the IP address of the radio port. This is done so that
|
|
the remote gateway sees the correct address from your gateway in encapsulated
|
|
datagrams sent to it.
|
|
<item>The route commands used to specify the encapsulated routes can be
|
|
automatically generated by a modified version of the <em>munge</em> script.
|
|
This is included below. The route commands would then be written to a separate
|
|
file and read in using the <em>bash</em> <tt>source /etc/ipip.routes</tt>
|
|
command (assuming you called the file with the routing commands
|
|
<tt>/etc/ipip.routes</tt>) as illustrated. The source file must be in the
|
|
NOS route command format.
|
|
<item>Note the use of the <em>window</em> argument on the <em>route</em>
|
|
command. Setting this parameter to an appropriate value improves the
|
|
performance of your radio link.
|
|
</itemize>
|
|
|
|
<p>
|
|
The new tunnel-munge script:
|
|
|
|
<tscreen><verb>
|
|
#!/bin/sh
|
|
#
|
|
# From: Ron Atkinson <n8fow@hamgate.cc.wayne.edu>
|
|
#
|
|
# This script is basically the 'munge' script written by Bdale N3EUA
|
|
# for the IPIP daemon and is modified by Ron Atkinson N8FOW. It's
|
|
# purpose is to convert a KA9Q NOS format gateways route file
|
|
# (usually called 'encap.txt') into a Linux routing table format
|
|
# for the IP tunnel driver.
|
|
#
|
|
# Usage: Gateway file on stdin, Linux route format file on stdout.
|
|
# eg. tunnel-munge < encap.txt > ampr-routes
|
|
#
|
|
# NOTE: Before you use this script be sure to check or change the
|
|
# following items:
|
|
#
|
|
# 1) Change the 'Local routes' and 'Misc user routes' sections
|
|
# to routes that apply to your own area (remove mine please!)
|
|
# 2) On the fgrep line be sure to change the IP address to YOUR
|
|
# gateway Internet address. Failure to do so will cause serious
|
|
# routing loops.
|
|
# 3) The default interface name is 'tunl0'. Make sure this is
|
|
# correct for your system.
|
|
|
|
echo "#"
|
|
echo "# IP tunnel route table built by $LOGNAME on `date`"
|
|
echo "# by tunnel-munge script v960307."
|
|
echo "#"
|
|
echo "# Local routes"
|
|
echo "route add -net 44.xxx.xxx.xxx netmask 255.mmm.mmm.mmm dev sl0"
|
|
echo "#"
|
|
echo "# Misc user routes"
|
|
echo "#"
|
|
echo "# remote routes"
|
|
|
|
fgrep encap | grep "^route" | grep -v " XXX.XXX.XXX.XXX" | \
|
|
awk '{
|
|
split($3, s, "/")
|
|
split(s[1], n,".")
|
|
if (n[1] == "") n[1]="0"
|
|
if (n[2] == "") n[2]="0"
|
|
if (n[3] == "") n[3]="0"
|
|
if (n[4] == "") n[4]="0"
|
|
if (s[2] == "1") mask="128.0.0.0"
|
|
else if (s[2] == "2") mask="192.0.0.0"
|
|
else if (s[2] == "3") mask="224.0.0.0"
|
|
else if (s[2] == "4") mask="240.0.0.0"
|
|
else if (s[2] == "5") mask="248.0.0.0"
|
|
else if (s[2] == "6") mask="252.0.0.0"
|
|
else if (s[2] == "7") mask="254.0.0.0"
|
|
else if (s[2] == "8") mask="255.0.0.0"
|
|
else if (s[2] == "9") mask="255.128.0.0"
|
|
else if (s[2] == "10") mask="255.192.0.0"
|
|
else if (s[2] == "11") mask="255.224.0.0"
|
|
else if (s[2] == "12") mask="255.240.0.0"
|
|
else if (s[2] == "13") mask="255.248.0.0"
|
|
else if (s[2] == "14") mask="255.252.0.0"
|
|
else if (s[2] == "15") mask="255.254.0.0"
|
|
else if (s[2] == "16") mask="255.255.0.0"
|
|
else if (s[2] == "17") mask="255.255.128.0"
|
|
else if (s[2] == "18") mask="255.255.192.0"
|
|
else if (s[2] == "19") mask="255.255.224.0"
|
|
else if (s[2] == "20") mask="255.255.240.0"
|
|
else if (s[2] == "21") mask="255.255.248.0"
|
|
else if (s[2] == "22") mask="255.255.252.0"
|
|
else if (s[2] == "23") mask="255.255.254.0"
|
|
else if (s[2] == "24") mask="255.255.255.0"
|
|
else if (s[2] == "25") mask="255.255.255.128"
|
|
else if (s[2] == "26") mask="255.255.255.192"
|
|
else if (s[2] == "27") mask="255.255.255.224"
|
|
else if (s[2] == "28") mask="255.255.255.240"
|
|
else if (s[2] == "29") mask="255.255.255.248"
|
|
else if (s[2] == "30") mask="255.255.255.252"
|
|
else if (s[2] == "31") mask="255.255.255.254"
|
|
else mask="255.255.255.255"
|
|
|
|
if (mask == "255.255.255.255")
|
|
printf "route add -host %s.%s.%s.%s gw %s dev tunl0\n"\
|
|
,n[1],n[2],n[3],n[4],$5
|
|
else
|
|
printf "route add -net %s.%s.%s.%s gw %s netmask %s dev tunl0\n"\
|
|
,n[1],n[2],n[3],n[4],$5,mask
|
|
}'
|
|
|
|
echo "#"
|
|
echo "# default the rest of amprnet via mirrorshades.ucsd.edu"
|
|
echo "route add -net 44.0.0.0 gw 128.54.16.18 netmask 255.0.0.0 dev tunl0"
|
|
echo "#"
|
|
echo "# the end"
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading>AXIP encapsulated gateway configuration
|
|
<p>
|
|
Many Amateur Radio Internet gateways encapsulate AX.25, NetRom 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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
The <em/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 <tt>/etc/ax25/ax25ipd.conf</tt>.
|
|
|
|
<sect2><heading>AXIP configuration options.
|
|
<p>
|
|
The <em/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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
Other options that are configured here are
|
|
<list>
|
|
<item>the tty that the <em/ax25ipd/ daemon will open and its speed (usually
|
|
one end of a pipe)
|
|
<item>what callsign you want to use in "digipeater" mode
|
|
<item>beacon interval and text
|
|
<item>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.
|
|
</list>
|
|
|
|
<sect2><heading>A typical <tt>/etc/ax25/ax25ipd.conf</tt> file.
|
|
<p>
|
|
<tscreen><verb>
|
|
#
|
|
# 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 AX25 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 44.136.8.68 b
|
|
route vk5xxx 44.136.188.221 b
|
|
route vk2abc 44.1.1.1
|
|
#
|
|
#
|
|
</verb></tscreen>
|
|
|
|
<sect2><heading>Running <em/ax25ipd/
|
|
<p>
|
|
<descrip>
|
|
<tag>Create your <tt>/etc/ax25/axports</tt> entry:
|
|
<tscreen><verb>
|
|
# /etc/ax25/axports
|
|
#
|
|
axip VK2KTJ-13 9600 256 AXIP port
|
|
#
|
|
</verb></tscreen>
|
|
|
|
<tag>Run the <em/kissattach/ command to create that port:</tag>
|
|
<tscreen><verb>
|
|
/usr/sbin/kissattach /dev/ptyq0 axip
|
|
</verb></tscreen>
|
|
|
|
<tag>Run the <em/ax25ipd/ program:</tag>
|
|
<tscreen><verb>
|
|
/usr/sbin/ax25ipd &
|
|
</verb></tscreen>
|
|
|
|
<tag>Test the AXIP link:</tag>
|
|
<tscreen><verb>
|
|
call axip vk5xxx
|
|
</verb></tscreen>
|
|
</descrip>
|
|
|
|
<sect2><heading>Some notes about the routes and route flags
|
|
<p>
|
|
The "<tt/route/" command is where you specify where you want your AX.25
|
|
packets encapsulated and sent to. When the <em/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.
|
|
<p>
|
|
There are two flags you can add to any of the route commands in the
|
|
<tt/ax25ipd.conf/ file. The two flags are:
|
|
<descrip>
|
|
<tag>b</tag>traffic with a destination address matching any of those on
|
|
the list defined by the "<tt/broadcast/" keyword should be transmitted via
|
|
this route.
|
|
<tag>d</tag>any packets not matching any route should be transmitted via
|
|
this route.
|
|
</descrip>
|
|
<p>
|
|
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.
|
|
|
|
<sect1><heading>Linking NOS and Linux using a pipe device
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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 <bf>master</bf>
|
|
end of the pipe, and the open then the second program can open the
|
|
<bf>slave</bf> 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.
|
|
<p>
|
|
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 <tt>/dev</tt> directory. The master end of the pipes are
|
|
named: <tt>ptyq[1-f]</tt> and the slave end of the pipes are known as:
|
|
<tt>ttyq[1-f]</tt>. Remember they come in pairs, so if you select
|
|
<tt>/dev/ptyqf</tt> as your master end then you must use <tt>/dev/ttyqf</tt>
|
|
as the slave end.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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:
|
|
<p>
|
|
<tscreen><verb>
|
|
# /sbin/slattach -s 38400 -p slip /dev/ptyqf &
|
|
# /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 netmask 255.0.0.0 gw 44.70.248.67
|
|
</verb></tscreen>
|
|
<p>
|
|
In this example the Linux kernel has been given IP address <tt>44.70.4.88</tt>
|
|
and the NOS program is using IP address <tt>44.70.248.67</tt>. The
|
|
<em>route</em> command in the last line simply tells your linux kernel to route
|
|
all datagrams for the amprnet via the slip link created by the
|
|
<em>slattach</em> command. Normally you would put these commands into your
|
|
<tt>/etc/rc.d/rc.inet2</tt> 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 <em>cslip</em> instead of <em>slip</em>
|
|
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.
|
|
<p>
|
|
To configure the NOS end of the link you could try the following:
|
|
<p>
|
|
<tscreen><verb>
|
|
# you can call the interface anything you want; I use "linux" for convenience.
|
|
attach asy ttyqf - slip linux 1024 1024 38400
|
|
route addprivate 44.70.4.88 linux
|
|
</verb></tscreen>
|
|
<p>
|
|
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.
|
|
|
|
|
|
<sect><heading>Where do I find more information about .... ?
|
|
<p>
|
|
Since this document assumes you already have some experience with packet
|
|
radio and that this might not be the case I've collected a set of references
|
|
to other information that you might find useful.
|
|
<p>
|
|
|
|
<sect1>Packet Radio
|
|
<p>
|
|
You can get general information about Packet Radio from these sites:
|
|
<list>
|
|
<item><url name="American Radio Relay League" url="http://www.arrl.org/">,
|
|
<item><url name="Radio Amateur Teleprinter Society" url="http://www.rats.org/">
|
|
<item><url name="Tucson Amateur Packet Radio Group" url="http://www.tapr.org/">
|
|
</list>
|
|
<p>
|
|
|
|
<sect1>Protocol Documentation
|
|
<p>
|
|
<list>
|
|
<item>AX.25, NetRom - Jonathon Naylor has collated a variety of documents that
|
|
relate to the packet radio protocols themselves. This documentation has been
|
|
packaged up into
|
|
<url name="ax25-doc-1.0.tar.gz"
|
|
url="ftp://ftp.pspt.fi/pub/ham/linux/ax25/ax25-doc-1.0.tar.gz"
|
|
</list>
|
|
<p>
|
|
|
|
<sect1>Hardware Documentation
|
|
<p>
|
|
<list>
|
|
<item>Information on the <bf>PI2 Card</bf> is provided by the
|
|
<url name="Ottawa Packet Radio Group" url="http://hydra.carleton.ca/">.
|
|
<item>Information on <bf>Baycom hardware</bf> is available at the
|
|
<url name="Baycom Web Page" url="http://www.baycom.de/">.
|
|
</list>
|
|
|
|
<sect><heading>Discussion relating to Amateur Radio and Linux.
|
|
<p>
|
|
There are various places that discussion relating to Amateur Radio and Linux
|
|
take place. They take place in the <tt>comp.os.linux.*</tt> newsgroups, they
|
|
also take place on the <tt>HAMS</tt> list on <tt>vger.rutgers.edu</tt>. Other
|
|
places where they are held include the <tt>tcp-group</tt> mailing list at
|
|
<tt>ucsd.edu</tt> (the home of amateur radio TCP/IP discussions), and you
|
|
might also try the <tt>#linpeople</tt> channel on the <tt>linuxnet</tt>
|
|
irc network.
|
|
|
|
To join the Linux <bf>linux-hams</bf> channel on the mail list server, send
|
|
mail to:
|
|
<tscreen><verb>
|
|
Majordomo@vger.rutgers.edu
|
|
</verb></tscreen>
|
|
with the line:
|
|
<tscreen><verb>
|
|
subscribe linux-hams
|
|
</verb></tscreen>
|
|
in the message body. The subject line is ignored.
|
|
<p>
|
|
The <bf>linux-hams</bf> mailing list is archived at:
|
|
|
|
<url url="http://zone.pspt.fi/archive/linux-hams/"
|
|
name="zone.pspt.fi">
|
|
and
|
|
<url url="http://zone.oh7rba.ampr.org/archive/linux-hams/"
|
|
name="zone.oh7rba.ampr.org">.
|
|
Please use the archives when you are first starting, because many common
|
|
questions are answered there.
|
|
|
|
<p>
|
|
To join the <tt>tcp-group</tt> send mail to:
|
|
<tscreen><verb>
|
|
listserver@ucsd.edu
|
|
</verb></tscreen>
|
|
with the line:
|
|
<tscreen><verb>
|
|
subscribe tcp-group
|
|
</verb></tscreen>
|
|
in the body of the text.
|
|
|
|
<bf>Note:</bf> Please remember that the <tt>tcp-group</tt> is primarily for
|
|
discussion of the use of advanced protocols, of which TCP/IP is one, in
|
|
Amateur Radio. <em>Linux specific questions should not ordinarily go there.</em>
|
|
|
|
<sect><heading>Acknowledgements.
|
|
<p>
|
|
The following people have contributed to this document in one way or another,
|
|
knowingly or unknowingly. In no particular order (as I find them):
|
|
Jonathon Naylor, Thomas Sailer, Joerg Reuter, Ron Atkinson, Alan Cox, Craig
|
|
Small, John Tanner, Brandon Allbery, Hans Alblas, Klaus Kudielka, Carl Makin.
|
|
|
|
<sect><heading>Copyright.
|
|
<p>
|
|
The AX25-HOWTO, information on how to install and configure some of the more
|
|
important packages providing AX25 support for Linux.
|
|
Copyright (c) 1996 Terry Dawson.
|
|
|
|
This program is free software; you can redistribute it and/or modify it under
|
|
the terms of the GNU General Public License as published by the Free Software
|
|
Foundation; either version 2 of the License, or (at your option) any later
|
|
version.
|
|
|
|
This program is distributed in the hope that it will be useful, but WITHOUT
|
|
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
|
|
FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
|
|
|
|
You should have received a copy of the GNU General Public License along with
|
|
this program; if not, write to the:
|
|
|
|
Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
|
</article>
|