mirror of https://github.com/tLDP/LDP
6570 lines
173 KiB
Plaintext
6570 lines
173 KiB
Plaintext
<!DOCTYPE Article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
|
|
|
|
<Article>
|
|
|
|
<ArtHeader>
|
|
|
|
<Title>Linux Amateur Radio AX.25 HOWTO</Title>
|
|
<Author>
|
|
<FirstName>Jeff</FirstName>
|
|
<Surname>Tranter, VE3ICH</Surname>
|
|
<Affiliation>
|
|
<Address>
|
|
<Email>tranter@pobox.com</Email>
|
|
</Address>
|
|
</Affiliation>
|
|
</Author>
|
|
<PubDate>v2.1, 19 September 2001</PubDate>
|
|
|
|
<Abstract>
|
|
|
|
<Para>
|
|
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 utilized by Amateur Radio operators worldwide. This
|
|
document describes how to install and configure this support.
|
|
</Para>
|
|
|
|
</Abstract>
|
|
|
|
</ArtHeader>
|
|
|
|
<Sect1><Title>Introduction</Title>
|
|
|
|
<!-- TODO:
|
|
Consider reorganizing structure of document to make it more logical
|
|
and add more introductory information on packer radio and each of
|
|
the protocols.
|
|
-->
|
|
|
|
<Para>
|
|
Amateur radio is a non-profit, non-commercial activity enjoyed by
|
|
hobbyists world-wide. Radio amateurs are licensed by government
|
|
authorities to use portions of the radio spectrum allocated to them
|
|
for non-commercial, non-profit activities including personal
|
|
communication, public service, and technical experimentation. Packet
|
|
Radio is a particular digital mode of communication that makes use of
|
|
networking protocols to provide computer to computer communication.
|
|
</Para>
|
|
|
|
<Para>
|
|
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, NET/ROM and ROSE support for Linux. A
|
|
few typical configurations are described that could be used as models to work
|
|
from.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Sect2><Title>Changes from the previous version</Title>
|
|
|
|
<ItemizedList>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Updated IPIP tunnelling section to reflect iproute2 package (thanks to
|
|
Milan Kalina).
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Where to obtain new versions of this document</Title>
|
|
|
|
<Para>
|
|
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
|
|
<ULink URL="http://www.linuxdoc.org/HOWTO/AX25-HOWTO.html">the AX25-HOWTO</ULink>.
|
|
This document is also available in various formats from the
|
|
<ULink URL="http://www.linuxdoc.org">Linux Documentation Project</ULink>.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Other related documentation</Title>
|
|
|
|
<Para>
|
|
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
|
|
deeper insight into other possible configurations. They are:
|
|
</Para>
|
|
|
|
<ItemizedList>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ULink URL="http://www.linuxdoc.org/HOWTO/Net-HOWTO/index.html">Linux Networking HOWTO</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ULink URL="http://www.linuxdoc.org/HOWTO/Ethernet-HOWTO.html">Linux Ethernet HOWTO</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ULink URL="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html">Linux Firewall and Proxy Server HOWTO</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ULink URL="http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html">Linux 2.4 Advanced Routing HOWTO</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ULink URL="http://www.linuxdoc.org/HOWTO/mini/Netrom-Node.html">Netrom-Node mini-Howto</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
<Para>
|
|
You may come across references to a Linux HAM HOWTO. This document is
|
|
obsolete and has been replaced by the <ULink
|
|
URL="http://radio.linux.org.au/">Hamsoft Linux Ham Radio Applications
|
|
and Utilities Database</ULink> web site. More general Linux
|
|
information may be found by referencing other <ULink
|
|
URL="http://www.linuxdoc.org/HOWTO/HOWTO-INDEX/index.html">Linux
|
|
HOWTO</ULink> documents.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>The Packet Radio Protocols and Linux</Title>
|
|
|
|
<Para>
|
|
The <Emphasis>AX.25</Emphasis> 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 NET/ROM.
|
|
</Para>
|
|
|
|
<Para>
|
|
It is similar to X.25 level 2 in structure, with some extensions to make it
|
|
more useful in the amateur radio environment.
|
|
</Para>
|
|
|
|
<Para>
|
|
The NET/ROM 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 NET/ROM protocol features dynamic routing and
|
|
node aliases.
|
|
</Para>
|
|
|
|
<Para>
|
|
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 obtained from the
|
|
<ULink URL="http://www.rats.org/">RATS Web server</ULink>.
|
|
</Para>
|
|
|
|
<Para>
|
|
Alan Cox developed some early kernel based AX.25 software support for
|
|
Linux. <ULink URL="mailto:g4klx@g4klx.demon.co.uk">Jonathon
|
|
Naylor</ULink> has taken up ongoing development of the code, has added
|
|
NET/ROM and ROSE support and is now the developer of the AX.25 related
|
|
kernel code. DAMA support was developed by
|
|
<ULink URL="mailto:jreuter@poboxes.com">Joerg</ULink>, DL1BKE. Baycom and
|
|
Soundmodem support were added by
|
|
<ULink URL="mailto:sailer@ife.ee.ethz.ch">Thomas Sailer</ULink>.
|
|
The AX.25 software is now maintained by a small team of developers
|
|
on <ULink URL="http://www.sourceforge.net">SourceForge</ULink>.
|
|
</Para>
|
|
|
|
<Para>
|
|
The Linux code supports KISS and 6PACK 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, several
|
|
parallel and serial port Baycom modems, and serial port YAM
|
|
modems. Thomas Sailer's kernel soundmodem driver supports SoundBlaster
|
|
and sound cards based on the Crystal chip set, and his newer user-mode
|
|
soundmodem uses the standard kernel sound drivers, so it should work
|
|
with any sound card supported under Linux.
|
|
</Para>
|
|
|
|
<Para>
|
|
The user programs contain a simple PMS (Personal Message System), a
|
|
beacon facility, a line mode connect program,
|
|
<Literal>listen</Literal> (an example of how to capture all AX.25
|
|
frames at raw interface level), and programs to configure the NET/ROM
|
|
protocol. Also included are an AX.25 server style program to handle
|
|
and dispatch incoming AX.25 connections and a NET/ROM daemon which
|
|
does most of the hard work for NET/ROM support.
|
|
</Para>
|
|
|
|
<Para>
|
|
There are utility programs to support APRS, including digipeating and
|
|
gatewaying to the Internet.
|
|
</Para>
|
|
|
|
<Sect2><Title>How it all fits together</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis>Simplified Protocol Layering Diagram</Emphasis>
|
|
<Screen>
|
|
_____________________________________________
|
|
| | | | |
|
|
| AF_AX25 | AF_NETROM | AF_INET | AF_ROSE |
|
|
|=========|===========|=============|=========|
|
|
| | | | |
|
|
| | | TCP/IP | |
|
|
| | |________ | |
|
|
| | NET/ROM | | ROSE |
|
|
| |____________________|____|_________|
|
|
| AX.25 |
|
|
|_____________________________________________|
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This diagram simply illustrates that NET/ROM, ROSE and TCP/IP all run directly
|
|
on top of AX.25, but that each of these protocols is treated as a separate
|
|
protocol at the programming interface. The `<Literal>_</Literal>' names are
|
|
simply the names given to the `<Emphasis>Address Family</Emphasis>' 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 NET/ROM, ROSE or TCP/IP devices.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis>Software Module Diagram of Linux Network Implementation</Emphasis>
|
|
<Screen>
|
|
___________________________________________________________________________
|
|
| | | || | |
|
|
| 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 |
|
|
|_________|_________________________________________________________________|
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
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 <Emphasis>call</Emphasis> 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
|
|
<Emphasis>call</Emphasis> program can use. I have attempted to lay out this document in
|
|
roughly that order.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>The AX.25/NET/ROM/ROSE software components</Title>
|
|
|
|
<Para>
|
|
The AX.25 software is comprised of three components: the kernel source, the
|
|
network configuration tools and the utility programs.
|
|
</Para>
|
|
|
|
<Para>
|
|
AX.25 support in the Linux kernel has been fairly stable since the 2.2
|
|
series of kernel versions. This document assumes you are using the
|
|
most recent kernel, which as the time of writing was 2.4.9.
|
|
</Para>
|
|
|
|
<Note>
|
|
<Para>
|
|
Software versions listed in this document were the latest at the time
|
|
of writing, but are subject to change. Check for newer versions
|
|
when downloading them.
|
|
</Para>
|
|
</Note>
|
|
|
|
<Sect2><Title>Finding the kernel, tools and utility packages</Title>
|
|
|
|
<Sect3><Title>The kernel source</Title>
|
|
|
|
<Para>
|
|
The kernel source can be found at <Literal>www.kernel.org</Literal> and
|
|
<Literal>ftp.kernel.org</Literal>.
|
|
For the 2.4.9 kernel it would be downloaded from
|
|
<ULink URL="ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.9.tar.gz">
|
|
ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.9.tar.gz</ULink>.
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>The network tools</Title>
|
|
|
|
<Para>
|
|
The latest release of the standard Linux network tools support
|
|
AX.25 and NET/ROM and can be found at
|
|
<ULink URL="http://www.tazenda.demon.co.uk/phil/net-tools">
|
|
http://www.tazenda.demon.co.uk/phil/net-tools</ULink>.
|
|
</Para>
|
|
|
|
<Para>
|
|
The latest ipchains package can be found at
|
|
<ULink URL="http://netfilter.filewatcher.org/ipchains/">
|
|
http://netfilter.filewatcher.org/ipchains</ULink>.
|
|
</Para>
|
|
|
|
<Note>
|
|
<Para>
|
|
It is usually not necessary to download and install these as any
|
|
recent Linux distribution should include them.
|
|
</Para>
|
|
</Note>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>The AX.25 utilities</Title>
|
|
|
|
<Para>
|
|
The old ax25-utils used with the 2.0 and 2.1 kernels is now obsolete
|
|
and has been replaced with new packages hosted on
|
|
<ULink URL="http://sourceforge.net">SourceForge</ULink> at
|
|
<ULink URL="http://sourceforge.net/projects/hams">http://sourceforge.net/projects/hams</ULink>.
|
|
</Para>
|
|
|
|
<Para>
|
|
The software is distributed as three packages: the AX.25 library, tools, and
|
|
applications. At the time of writing the most recent versions were
|
|
the following:
|
|
</Para>
|
|
|
|
<ItemizedList>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ULink URL="ftp://hams.sourceforge.net/pub/hams/ax25/libax25-0.0.7.tar.gz">ftp://hams.sourceforge.net/pub/hams/ax25/libax25-0.0.7.tar.gz</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ULink URL="ftp://hams.sourceforge.net/pub/hams/ax25/ax25-tools-0.0.6.tar.gz">ftp://hams.sourceforge.net/pub/hams/ax25/ax25-tools-0.0.6.tar.gz</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ULink URL="ftp://hams.sourceforge.net/pub/hams/ax25/ax25-apps-0.0.4.tar.gz">ftp://hams.sourceforge.net/pub/hams/ax25/ax25-apps-0.0.4.tar.gz</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>The APRS utilities</Title>
|
|
|
|
<Para>
|
|
If you want to use APRS you can download <ULink
|
|
URL="http://sourceforge.net/projects/aprsd/">aprsd</ULink> and <ULink
|
|
URL="http://www.users.cloud9.net/~alan/ham/aprs/">aprsdigi</ULink>:
|
|
|
|
<ItemizedList>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ULink URL="http://prdownloads.sourceforge.net/aprsd/aprsd-2.1.4.tar.gz">http://prdownloads.sourceforge.net/aprsd/aprsd-2.1.4.tar.gz</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
<ULink URL="http://www.users.cloud9.net/~alan/ham/aprs/aprsdigi-2.0-pre3.tar.gz">http://www.users.cloud9.net/~alan/ham/aprs/aprsdigi-2.0-pre3.tar.gz</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Installing the AX.25/NET/ROM/ROSE software</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Tip>
|
|
<Para>
|
|
Rather than building and installing from source, you may prefer to
|
|
install prebuilt binary packages for your system. Debian and RPM
|
|
format packages are available on various archive sites including
|
|
<ULink URL="http://www.debian.org">http://www.debian.org</ULink> and
|
|
<ULink URL="http://rpmfind.net">http://rpmfind.net</ULink>; look for
|
|
"ax25". Incidently, the Debian Linux distribution is considered by
|
|
many people to be one of the more "Amateur Radio friendly"
|
|
distributions, and provides many amateur radio applications as Debian
|
|
packages (one of the founders of the project is a ham).
|
|
</Para>
|
|
</Tip>
|
|
|
|
<Sect2><Title>Compiling the kernel</Title>
|
|
|
|
<Para>
|
|
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. You may also want to
|
|
read the
|
|
<ULink URL="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">Linux Kernel HOWTO</ULink>.
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The normal place for the kernel source to be unpacked to is the
|
|
<Literal>/usr/src</Literal> directory into a subdirectory called <Literal>linux</Literal>.
|
|
To do this you should be logged in as <Literal>root</Literal> and execute a series
|
|
of commands similar to the following:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# cd /usr/src
|
|
# mv linux linux.old
|
|
# tar xzvf linux-2.4.9.tar.gz
|
|
# cd linux
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
After you have unpacked the kernel source, 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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# make menuconfig
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
If you are running X you can get a graphical interface using:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# make xconfig
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
You might also try:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# make config
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
I'm going to describe the full screen method (menuconfig) because it is easier
|
|
to move around, but use whichever you are most comfortable with.
|
|
</Para>
|
|
|
|
<Para>
|
|
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).
|
|
</Para>
|
|
|
|
<Para>
|
|
The options most relevant to an AX.25 configuration are:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
Code maturity level options --->
|
|
[*] Prompt for development and/or incomplete code/drivers
|
|
...
|
|
General setup --->
|
|
...
|
|
[*] Networking support
|
|
...
|
|
Networking options --->
|
|
<*> UNIX domain sockets
|
|
...
|
|
[*] TCP/IP networking
|
|
...
|
|
[?] IP: tunneling
|
|
...
|
|
Amateur Radio Support --->
|
|
--- Packet Radio protocols
|
|
[*] Amateur Radio AX.25 Level 2 protocol
|
|
[?] AX.25 DAMA Slave support
|
|
[?] Amateur Radio NET/ROM protocol
|
|
[?] Amateur Radio X.25 PLP (Rose)
|
|
AX.25 network device drivers --->
|
|
<?> Serial port KISS driver
|
|
<?> Serial port 6PACK driver
|
|
<?> BPQ Ethernet driver
|
|
<?> High-speed (DMA) SCC driver for AX.25
|
|
<?> Z8530 SCC driver
|
|
<?> BAYCOM ser12 fullduplex driver for AX.25
|
|
<?> BAYCOM ser12 halfduplex driver for AX.25
|
|
<?> BAYCOM picpar and par96 driver for AX.25
|
|
<?> BAYCOM epp driver for AX.25
|
|
<?> Soundcard modem driver
|
|
[?] soundmodem support for Soundblaster and compatible cards
|
|
[?] soundmodem support for WSS and Crystal cards
|
|
[?] soundmodem support for 1200 baud AFSK modulation
|
|
[?] soundmodem support for 2400 baud AFSK modulation (7.3728MHz crystal)
|
|
[?] soundmodem support for 2400 baud AFSK modulation (8MHz crystal)
|
|
[?] soundmodem support for 2666 baud AFSK modulation
|
|
[?] soundmodem support for 4800 baud HAPN-1 modulation
|
|
[?] soundmodem support for 4800 baud PSK modulation
|
|
[?] soundmodem support for 9600 baud FSK G3RUH modulation
|
|
<?> YAM driver for AX.25
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
The options I have flagged with a `<Literal>*</Literal>' are those
|
|
that you <Emphasis>must</Emphasis> 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
After you have completed the kernel configuration you should be able to
|
|
cleanly compile your new kernel:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# make dep
|
|
# make clean
|
|
# make zImage
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Make sure you move your <Literal>arch/i386/boot/zImage</Literal> file
|
|
wherever you want it and then edit your
|
|
<Literal>/etc/lilo.conf</Literal> file and rerun
|
|
<Emphasis>lilo</Emphasis> to ensure that you actually boot from it.
|
|
</Para>
|
|
|
|
<Sect3><Title>A word about kernel modules</Title>
|
|
|
|
<Para>
|
|
|
|
Compiling drivers as modules is useful if you only use AX.25
|
|
occasionally and want to be able to load and unload them on demand to
|
|
save system resources. However, some people have problems getting the
|
|
modularized drivers working because they are more complicated to
|
|
configure. If you've chosen to compile any drivers as modules, then
|
|
you'll also need to run the commands:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# make modules
|
|
# make modules_install
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
to install your modules in the appropriate location.
|
|
</Para>
|
|
|
|
<Para>
|
|
You will also need to add some entries into your <Literal>/etc/modules.conf</Literal>
|
|
file to ensure that the <Emphasis>kerneld</Emphasis> program knows how to locate the
|
|
kernel modules. You should add/modify the following:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
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
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Tip>
|
|
<Para>
|
|
On Debian-based Linux systems these entries should go into the file
|
|
<Literal>/etc/modutils/aliases</Literal> and then you need to run
|
|
<Literal>/sbin/update-mpodules</Literal>.
|
|
</Para>
|
|
</Tip>
|
|
|
|
</Sect3>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>The AX.25 library, tools, and application programs</Title>
|
|
|
|
<Para>
|
|
After you have successfully compiled and booted your new kernel you
|
|
need to compile and install the ax25 library, tools, and application
|
|
programs.
|
|
</Para>
|
|
|
|
<Para>
|
|
To compile and install libax25 you should use a series of commands
|
|
similar to the following:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# cd /usr/src
|
|
# tar xzvf libax25-0.0.7.tar.gz
|
|
# cd libax25-0.0.7
|
|
# ./configure --exec_prefix=/usr --sysconfdir=/etc --localstatedir=/var
|
|
# make
|
|
# make install
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Tip>
|
|
<Para>
|
|
The arguments to the <Literal>configure</Literal> command ensure that
|
|
the files will be installed in the "standard" places under the
|
|
directory <Literal>/usr</Literal> in subdirectories
|
|
<Literal>bin</Literal>, <Literal>sbin</Literal>,
|
|
<Literal>etc</Literal> and <Literal>man</Literal>. If you simply run
|
|
configure with no options it will default to putting all files under
|
|
<Literal>/usr/local</Literal>. This can cause the situation where you
|
|
have configuration files in both <Literal>/usr</Literal> and
|
|
<Literal>/usr/local</Literal>. If you want to ensure that this can't
|
|
happen you can make <Literal>/usr/local/etc/ax25</Literal> a symbolic
|
|
link to <Literal>/etc/ax25</Literal> at the very beginning of the
|
|
install process and then you won't have to worry about it.
|
|
</Para>
|
|
</Tip>
|
|
|
|
<Para>
|
|
If this is a first time installation, that is you've never installed any
|
|
ax25 code on your machine before, you should also use the:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# make installconf
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
command to install some sample configuration files into the <Literal>/etc/ax25/</Literal>
|
|
directory from which to work.
|
|
</Para>
|
|
|
|
<Para>
|
|
You can now build install the AX.25 tools in a similar fashion:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# cd /usr/src
|
|
# tar xzvf ax25-tools-0.0.6.tar.gz
|
|
# cd ax25-tools-0.0.6
|
|
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
|
|
# make
|
|
# make install
|
|
# make installconf (if you want to install the configuration files)
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
And finally you can install the AX.25 applications:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# cd /usr/src
|
|
# tar xzvf ax25-apps-0.0.4.tar.gz
|
|
# cd ax25-apps-0.0.4
|
|
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
|
|
# make
|
|
# make install
|
|
# make installconf (if you want to install the configuration files)
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
If you get messages something like:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
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.)
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
then you should double check that you have the
|
|
<Emphasis>ncurses</Emphasis> package properly installed on your
|
|
system. The configuration script attempts to locate your package in
|
|
the common locations, but some installations have it badly installed
|
|
and it is unable to locate them.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>A note on callsigns, addresses and things before we start</Title>
|
|
|
|
<Para>
|
|
Each AX.25 and NET/ROM 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
Some AX.25 implementations such as NOS and BPQ will allow you to configure
|
|
the same callsign/ssid on each AX.25 and NET/ROM port. For somewhat complicated
|
|
technical reasons Linux does not allow this. This isn't as big a problem in
|
|
practice as it might seem.
|
|
</Para>
|
|
|
|
<Para>
|
|
This means that there are things you should be aware of and take into
|
|
consideration when doing your configurations.
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<OrderedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Each AX.25 and NET/ROM port must be configured with a unique callsign/ssid.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
NET/ROM will use the callsign/ssid specified for it in its
|
|
configuration file, but this callsign is only used when your NET/ROM is
|
|
speaking to another NET/ROM, this is <Emphasis>not</Emphasis> the
|
|
callsign/ssid that AX.25 users who wish to use your NET/ROM `node' will
|
|
use. More on this later.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
ROSE will, by default, use the callsign/ssid of the AX.25 port, unless
|
|
the ROSE callsign has been specifically set using the
|
|
`<Emphasis>rsparms</Emphasis>' command. If you set a callsign/ssid
|
|
using the `<Emphasis>rsparms</Emphasis>' command then ROSE will use
|
|
this callsign/ssid on all ports.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Other programs, such as the `<Emphasis>ax25d</Emphasis>' program can listen using
|
|
any callsign/ssid that they wish and these may be duplicated across different
|
|
ports.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
If you are careful with routing you can configure the same IP address on
|
|
all ports if you wish.
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</OrderedList>
|
|
|
|
</Para>
|
|
|
|
<Sect2><Title>What are all those T1, T2, N2 and things ?</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
<informaltable frame=all>
|
|
<tgroup cols=3>
|
|
<thead>
|
|
<row><entry>Linux</entry><entry>TAPR TNC</entry><entry>Description</entry></row>
|
|
</thead>
|
|
<tbody>
|
|
|
|
<row>
|
|
<entry>T1</entry>
|
|
<entry>FRACK</entry>
|
|
<entry>How long to wait before retransmitting an unacknowledged frame.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>T2</entry>
|
|
<entry>RESPTIME</entry>
|
|
<entry>The minimum amount of time to wait for another frame to be received
|
|
before transmitting an acknowledgement.
|
|
</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>T3</entry>
|
|
<entry>CHECK</entry>
|
|
<entry>The period of time we wait between sending a check that the link is still active.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>N2</entry>
|
|
<entry>RETRY</entry>
|
|
<entry>How many times to retransmit a frame before assuming the connection has failed.
|
|
</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Idle</entry>
|
|
<entry></entry>
|
|
<entry>The period of time a connection can be idle before we close it down.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Window</entry>
|
|
<entry>MAXFRAME</entry>
|
|
<entry>The maximum number of unacknowledged transmitted frames.</entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Run time configurable parameters</Title>
|
|
|
|
<!-- TODO:
|
|
Check if this section is accurate and complete, and fill in
|
|
Meaning and Values columns in all the tables.
|
|
-->
|
|
|
|
<Para>
|
|
The kernel allows you to change many parameters at run time. If you
|
|
take a careful look at the <Literal>/proc/sys/net/</Literal> directory
|
|
structure you will see many files with useful names that describe
|
|
various parameters for the network configuration. The files in the
|
|
<Literal>/proc/sys/net/ax25/</Literal> directory each represent one
|
|
configured AX.25 port. The name of the file relates to the name of the
|
|
port.
|
|
</Para>
|
|
|
|
<Para>
|
|
The structure of the files in
|
|
<Literal>/proc/sys/net/ax25/<Replaceable>portname</Replaceable>/</Literal>
|
|
is as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<informaltable frame=all>
|
|
<tgroup cols=4>
|
|
<thead>
|
|
<row><entry>Filename</entry><entry>Meaning</entry><entry>Values</entry><entry>Default</entry></row>
|
|
</thead>
|
|
<tbody>
|
|
|
|
<row>
|
|
<entry>ip_default_mode</entry>
|
|
<entry>IP Default Mode</entry>
|
|
<entry>0=DG 1=VC</entry>
|
|
<entry>0</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ax25_default_mode</entry>
|
|
<entry>AX.25 Default Mode</entry>
|
|
<entry>0=Normal 1=Extended</entry>
|
|
<entry>0</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>backoff_type</entry>
|
|
<entry>Backoff</entry>
|
|
<entry>0=Linear 1=Exponential</entry>
|
|
<entry>1</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>connect_mode</entry>
|
|
<entry>Connected Mode</entry>
|
|
<entry>0=No 1=Yes</entry>
|
|
<entry>1</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>standard_window_size</entry>
|
|
<entry>Standard Window</entry>
|
|
<entry>1 .. 7</entry>
|
|
<entry>2</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>extended_window_size</entry>
|
|
<entry>Extended Window</entry>
|
|
<entry>1 .. 63</entry>
|
|
<entry>32</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>t1_timeout</entry>
|
|
<entry>T1 Timeout</entry>
|
|
<entry>1s .. 30s</entry>
|
|
<entry>10s</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>t2_timeout</entry>
|
|
<entry>T2 Timeout</entry>
|
|
<entry>1s .. 20s</entry>
|
|
<entry>3s</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>t3_timeout</entry>
|
|
<entry>T3 Timeout</entry>
|
|
<entry>0s .. 3600s</entry>
|
|
<entry>300s</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>idle_timeout</entry>
|
|
<entry>Idle Timeout</entry>
|
|
<entry>0m or greater</entry>
|
|
<entry>20m</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>maximum_retry_count</entry>
|
|
<entry>N2</entry>
|
|
<entry>1 .. 31</entry>
|
|
<entry>10</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>maximum_packet_length</entry>
|
|
<entry>AX.25 Frame Length</entry>
|
|
<entry>1 .. 512</entry>
|
|
<entry>256</entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</Para>
|
|
|
|
<Para>
|
|
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, e.g. T3 and Idle, a zero value indicates
|
|
that the timer is disabled.
|
|
</Para>
|
|
|
|
<Para>
|
|
The structure of the files in <Literal>/proc/sys/net/netrom/</Literal>
|
|
is as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<informaltable frame=all>
|
|
<tgroup cols=2>
|
|
<thead>
|
|
<row><entry>Filename</entry><entry>Meaning</entry><entry>Values</entry><entry>Default</entry></row>
|
|
</thead>
|
|
<tbody>
|
|
|
|
<row>
|
|
<entry>default_path_quality</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>10</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>link_fails_count</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>2</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>network_ttl_initialiser</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>16</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>obsolescence_count_initialiser</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>6</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>routing_control</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>1</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>transport_acknowledge_delay</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>50</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>transport_busy_delay</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>1800</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>transport_maximum_tries</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>3</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>transport_requested_window_size</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>4</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>transport_timeout</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>1200</entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</Para>
|
|
|
|
<Para>
|
|
The structure of the files in <Literal>/proc/sys/net/rose/</Literal>
|
|
is as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<informaltable frame=all>
|
|
<tgroup cols=2>
|
|
<thead>
|
|
<row><entry>Filename</entry><entry>Meaning</entry><entry>Values</entry><entry>Default</entry></row>
|
|
</thead>
|
|
<tbody>
|
|
|
|
<row>
|
|
<entry>acknowledge_hold_back_timeout</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>50</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>call_request_timeout</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>2000</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>clear_request_timeout</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>1800</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>link_fail_timeout</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>1200</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>maximum_virtual_circuits</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>50</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>reset_request_timeout</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>1800</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>restart_request_timeout</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>1800</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>routing_control</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>1</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>window_size</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>3</entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</Para>
|
|
|
|
<Para>
|
|
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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# cat /proc/sys/net/rose/window_size
|
|
3
|
|
# echo 4 >/proc/sys/net/rose/window_size
|
|
# cat /proc/sys/net/rose/window_size
|
|
4
|
|
</Screen>
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Configuring an AX.25 port</Title>
|
|
|
|
<!-- TODO:
|
|
Take more of the information from http://www.febo.com/linux-ax25/index.html
|
|
and incorporate it into this HOWTO (with credit).
|
|
-->
|
|
|
|
<Para>
|
|
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 <Literal>/etc/ax25/axports</Literal> file.
|
|
You must have an entry in this file for each AX.25 port you want on your
|
|
system.
|
|
</Para>
|
|
|
|
<Sect2><Title>Creating the AX.25 network device</Title>
|
|
|
|
<Para>
|
|
The network device is what is listed when you use the `<Emphasis>ifconfig</Emphasis>'
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
Each of these device drivers will create a network device when it is started.
|
|
</Para>
|
|
|
|
<Sect3><Title>Creating a KISS device</Title>
|
|
|
|
<Para>
|
|
<Emphasis>Kernel Compile Options</Emphasis>:
|
|
|
|
<Screen>
|
|
Amateur Radio support --->
|
|
[*] Amateur Radio support
|
|
--- Packet Radio protocols
|
|
<*> Amateur Radio AX.25 Level 2 protocol
|
|
...
|
|
AX.25 network device drivers --->
|
|
--- AX.25 network device drivers
|
|
<*> Serial port KISS driver
|
|
...
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
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 <Emphasis>minicom</Emphasis> or <Emphasis>seyon</Emphasis> to
|
|
configure the TNC into kiss mode.
|
|
</Para>
|
|
|
|
<Para>
|
|
To create a KISS device you use the <Emphasis>kissattach</Emphasis>
|
|
program. In it simplest form you can use the
|
|
<Emphasis>kissattach</Emphasis> program as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /usr/sbin/kissattach /dev/ttyS0 radio 44.135.96.242
|
|
# kissparms -p radio -t 100 -s 100 -r 25
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>kissattach</Emphasis> command will create a KISS network
|
|
device. These devices are called `<Literal>ax[0-9]</Literal>'. The
|
|
first time you use the <Emphasis>kissattach</Emphasis> command it
|
|
creates `<Literal>ax0</Literal>', the second time it creates
|
|
`<Literal>ax1</Literal>' etc. Each KISS device has an associated
|
|
serial port.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>kissparms</Emphasis> command allows you to set various
|
|
KISS parameters on a KISS device.
|
|
</Para>
|
|
|
|
<Para>
|
|
Specifically the example presented would create a KISS network device
|
|
using the serial device `<Literal>/dev/ttyS0</Literal>' and the entry
|
|
from the <Literal>/etc/ax25/axports</Literal> with a port name of
|
|
`<Literal>radio</Literal>'. It then configures it with a
|
|
<Emphasis>txdelay</Emphasis> and <Emphasis>slottime</Emphasis> of 100
|
|
milliseconds and a <Emphasis>ppersist</Emphasis> value of 25.
|
|
</Para>
|
|
|
|
<Para>
|
|
Please refer to the <Emphasis>man</Emphasis> pages for more information.
|
|
</Para>
|
|
|
|
<Sect4><Title>Configuring for Dual Port TNC's</Title>
|
|
|
|
<Para>
|
|
The <Emphasis>mkiss</Emphasis> 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 <Emphasis>before</Emphasis> you do any of the AX.25
|
|
configuration. The devices that you then do the AX.25 configuration on
|
|
are pseudo-TTY interfaces, (<Literal>/dev/ttyq*</Literal>), 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
|
|
`<Literal>/dev/ptyq*</Literal>' and the slave ends are called
|
|
`<Literal>/dev/ttyq*</Literal>'. There is a one to one relationship
|
|
between masters and slaves, so <Literal>/dev/ptyq0</Literal> is the
|
|
master end of a pipe with <Literal>/dev/ttyq0</Literal> as its
|
|
slave. You must open the master end of a pipe before opening the slave
|
|
end. <Emphasis>mkiss</Emphasis> exploits this mechanism to split a
|
|
single serial device into separate devices.
|
|
</Para>
|
|
|
|
<Para>
|
|
Example: if you have a dual port TNC and it is connected to your
|
|
<Literal>/dev/ttyS0</Literal> serial device at 9600 bps, the command:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /usr/sbin/mkiss -s 9600 /dev/ttyS0 /dev/ptyq0 /dev/ptyq1
|
|
# /usr/sbin/kissattach /dev/ttyq0 port1 44.135.96.242
|
|
# /usr/sbin/kissattach /dev/ttyq1 port2 44.135.96.242
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
would create two pseudo-tty devices that each look like a normal
|
|
single port TNC. You would then treat <Literal>/dev/ttyq0</Literal>
|
|
and <Literal>/dev/ttyq1</Literal> just as you would a conventional
|
|
serial device with TNC connected. This means you'd then use the
|
|
<Emphasis>kissattach</Emphasis> command as described above, on each of
|
|
those, in the example for AX.25 ports called <Literal>port1</Literal>
|
|
and <Literal>port2</Literal>. You shouldn't use
|
|
<Emphasis>kissattach</Emphasis> on the actual serial device as the
|
|
<Emphasis>mkiss</Emphasis> program uses it.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>mkiss</Emphasis> command has a number of optional
|
|
arguments that you may wish to use. They are summarized as follows:
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>-c</Term>
|
|
<ListItem>
|
|
<Para>
|
|
enables the addition of a one byte checksum to each KISS frame.
|
|
This is not supported by most KISS implementations, it is supported by the
|
|
G8BPG KISS ROM.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>-s <speed></Term>
|
|
<ListItem>
|
|
<Para>
|
|
sets the speed of the serial port.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>-h</Term>
|
|
<ListItem>
|
|
<Para>
|
|
enables hardware handshaking on the serial port, it is off by
|
|
default. Most KISS implementation do not support this, but some do.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>-l</Term>
|
|
<ListItem>
|
|
<Para>
|
|
enables logging of information to the <Emphasis>syslog</Emphasis> log file.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
</Sect4>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Creating a 6PACK device</Title>
|
|
|
|
<Para>
|
|
<Emphasis>Kernel Compile Options</Emphasis>:
|
|
|
|
<Screen>
|
|
Amateur Radio support --->
|
|
[*] Amateur Radio support
|
|
--- Packet Radio protocols
|
|
<*> Amateur Radio AX.25 Level 2 protocol
|
|
...
|
|
AX.25 network device drivers --->
|
|
--- AX.25 network device drivers
|
|
...
|
|
<*> Serial port 6PACK driver
|
|
...
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
6PACK is a protocol that is supported by some TNCs as an alternative
|
|
to KISS. It is used in a similar fashion to the KISS driver, using the
|
|
<Literal>slattach</Literal> command instead of <Literal>kissattach</Literal>.
|
|
</Para>
|
|
|
|
<!-- TODO:
|
|
Move info from the 6PACK mini-HOWTO (in the kernel source) into here.
|
|
-->
|
|
|
|
<Para>
|
|
A mini HOWTO on the 6PACK driver is included in the kernel source code
|
|
as the file
|
|
<Literal>/usr/src/linux/Documentation/networking/6pack.txt</Literal>.
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Creating a Baycom device</Title>
|
|
|
|
<Para>
|
|
<Emphasis>Kernel Compile Options</Emphasis>:
|
|
|
|
<Screen>
|
|
Amateur Radio support --->
|
|
[*] Amateur Radio support
|
|
--- Packet Radio protocols
|
|
<*> Amateur Radio AX.25 Level 2 protocol
|
|
...
|
|
AX.25 network device drivers --->
|
|
--- AX.25 network device drivers
|
|
...
|
|
<?> BAYCOM ser12 fullduplex driver for AX.25
|
|
<?> BAYCOM ser12 halfduplex driver for AX.25
|
|
<?> BAYCOM picpar and par96 driver for AX.25
|
|
<?> BAYCOM epp driver for AX.25
|
|
...
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
<ULink URL="mailto:sailer@ife.ee.ethz.ch">Thomas Sailer</ULink>,
|
|
despite the popularly held belief that it would not work very well,
|
|
has developed Linux support for Baycom modems. His driver supports the
|
|
<Literal>Ser12</Literal> serial port, <Literal>Par96</Literal> and the
|
|
enhanced <Literal>PicPar</Literal> parallel port modems. Further
|
|
information about the modems themselves may be obtained from the
|
|
<ULink URL="http://www.baycom.de/">Baycom Web site</ULink>.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The Baycom driver creates network devices called:
|
|
<Literal>bc0</Literal>, <Literal>bc1</Literal>, <Literal>bc2</Literal>
|
|
etc. when it is configured.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>sethdlc</Emphasis> 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
|
|
<Emphasis>insmod</Emphasis> command line when you load the Baycom
|
|
module.
|
|
</Para>
|
|
|
|
<Para>
|
|
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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# setserial /dev/ttyS0 uart none
|
|
# insmod hdlcdrv
|
|
# insmod baycom mode="ser12*" iobase=0x3f8 irq=4
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Par96 parallel port type modem on LPT1: using hardware DCD detection:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# insmod hdlcdrv
|
|
# insmod baycom mode="par96" iobase=0x378 irq=7 options=0
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This is not really the preferred way to do it. The <Emphasis>sethdlc</Emphasis> utility
|
|
works just as easily with one device as with many.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>sethdlc</Emphasis> <Emphasis>man</Emphasis> 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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# insmod hdlcdrv
|
|
# insmod baycom
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
or that you compiled the kernel with the driver inbuilt.
|
|
</Para>
|
|
|
|
<Para>
|
|
Configure the <Literal>bc0</Literal> device driver as a Parallel port Baycom modem on LPT1:
|
|
with software DCD:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# sethdlc -p -i bc0 mode par96 io 0x378 irq 7
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Configure the <Literal>bc1</Literal> device driver as a Serial port Baycom modem on COM1:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# sethdlc -p -i bc1 mode "ser12*" io 0x3f8 irq 4
|
|
</Screen>
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Configuring the AX.25 channel access parameters</Title>
|
|
|
|
<Para>
|
|
The AX.25 channel access parameters are the equivalent of the KISS ppersist,
|
|
txdelay and slottime type parameters. Again you use the <Emphasis>sethdlc</Emphasis> utility
|
|
for this.
|
|
</Para>
|
|
|
|
<Para>
|
|
Again the <Emphasis>sethdlc</Emphasis> man page is the source of the most complete information
|
|
but another example of two won't hurt:
|
|
</Para>
|
|
|
|
<Para>
|
|
Configure the <Literal>bc0</Literal> device with TxDelay of 200 mS, SlotTime of 100 mS,
|
|
PPersist of 40 and half duplex:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# sethdlc -i bc0 -a txd 200 slot 100 ppersist 40 half
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Note that the timing values are in milliseconds.
|
|
</Para>
|
|
|
|
<Sect4><Title>Configuring the Kernel AX.25 to use the Baycom device</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The first step is to configure the device with an AX.25 callsign. The
|
|
<Emphasis>ifconfig</Emphasis> utility may be used to perform this.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /sbin/ifconfig bc0 hw ax25 VK2KTJ-15 up
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
will assign the Baycom device <Literal>bc0</Literal> the AX.25
|
|
callsign <Literal>VK2KTJ-15</Literal>. Alternatively you can use the
|
|
<Emphasis>axparms</Emphasis> command, you'll still need to use the
|
|
<Emphasis>ifconfig</Emphasis> command to bring the device up though:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# ifconfig bc0 up
|
|
# axparms -setcall bc0 vk2ktj-15
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The next step is to create an entry in the <Literal>/etc/ax25/axports</Literal> file
|
|
as you would for any other device. The entry in the <Literal>axports</Literal> file is
|
|
associated with the network device you've configured by the callsign you
|
|
configure. The entry in the <Literal>axports</Literal> file that has the callsign that
|
|
you configured the Baycom device with is the one that will be used to
|
|
refer to it.
|
|
</Para>
|
|
|
|
<Para>
|
|
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 NET/ROM or ROSE over it
|
|
as you please.
|
|
</Para>
|
|
|
|
</Sect4>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Creating a kernel Soundmodem device</Title>
|
|
|
|
<Para>
|
|
<Emphasis>Kernel Compile Options</Emphasis>:
|
|
|
|
<Screen>
|
|
Amateur Radio support --->
|
|
[*] Amateur Radio support
|
|
--- Packet Radio protocols
|
|
<*> Amateur Radio AX.25 Level 2 protocol
|
|
...
|
|
AX.25 network device drivers --->
|
|
--- AX.25 network device drivers
|
|
...
|
|
<*> Soundcard modem driver
|
|
[?] soundmodem support for Soundblaster and compatible cards
|
|
[?] soundmodem support for WSS and Crystal cards
|
|
[?] soundmodem support for 1200 baud AFSK modulation
|
|
[?] soundmodem support for 2400 baud AFSK modulation (7.3728MHz crystal)
|
|
[?] soundmodem support for 2400 baud AFSK modulation (8MHz crystal)
|
|
[?] soundmodem support for 2666 baud AFSK modulation
|
|
[?] soundmodem support for 4800 baud HAPN-1 modulation
|
|
[?] soundmodem support for 4800 baud PSK modulation
|
|
[?] soundmodem support for 9600 baud FSK G3RUH modulation
|
|
...
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Thomas Sailer has built a 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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 Windows Sound System Compatible models. If you have a sound
|
|
card of another type, you can try the user-mode soundmodem described later
|
|
in this document.
|
|
</Para>
|
|
|
|
<Para>
|
|
The sound cards require some circuitry to help them drive the
|
|
Push-To-Talk circuitry, and information on this is available from
|
|
<ULink URL="http://www.baycom.org/~tom/pcf/ptt_circ/ptt.html">Thomas's
|
|
Soundmodem PTT circuit web page</ULink>. 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The Soundmodem driver creates network devices called:
|
|
<Literal>sm0</Literal>, <Literal>sm1</Literal>, <Literal>sm2</Literal> etc when it is configured.
|
|
</Para>
|
|
|
|
<Note>
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
</Note>
|
|
|
|
<Sect4><Title>Configuring the sound card</Title>
|
|
|
|
<Para>
|
|
The Soundmodem driver does not initialize the sound card. The ax25-utils
|
|
package includes a utility to do this called `<Emphasis>setcrystal</Emphasis>' that may
|
|
be used for sound cards based on the Crystal chip set. If you have some other
|
|
card then you will have to use some other software to initialize it.
|
|
Its syntax is fairly straightforward:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
setcrystal [-w wssio] [-s sbio] [-f synthio] [-i irq] [-d dma] [-c dma2]
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# setcrystal -s 0x388 -i 10 -d 1
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
To configure a Window Sound System card at i/o base address 0x534, irq 5, DMA 3
|
|
you would use:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# setcrystal -w 0x534 -i 5 -d 3
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Literal>[-f synthio]</Literal> parameter is the set the synthesizer address, and the
|
|
<Literal>[-c dma2]</Literal> parameter is to set the second DMA channel to allow full duplex
|
|
operation.
|
|
</Para>
|
|
|
|
</Sect4>
|
|
|
|
<Sect4><Title>Configuring the Soundmodem driver</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>sethdlc</Emphasis> 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 <Emphasis>insmod</Emphasis> command line when you load the
|
|
Soundmodem module.
|
|
</Para>
|
|
|
|
<Para>
|
|
For example, a simple configuration, with one SoundBlaster soundcard
|
|
configured as described above emulating a 1200 bps modem:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# insmod hdlcdrv
|
|
# insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This is not really the preferred way to do it. The <Emphasis>sethdlc</Emphasis> utility
|
|
works just as easily with one device as with many.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>sethdlc</Emphasis> 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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# insmod hdlcdrv
|
|
# insmod soundmodem
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
or that you compiled the kernel with the driver inbuilt.
|
|
</Para>
|
|
|
|
<Para>
|
|
Configure the driver to support the Windows Sound System card we configured
|
|
above to emulate a G3RUH 9600 compatible modem as device <Literal>sm0</Literal> using a
|
|
parallel port at 0x378 to key the Push-To-Talk:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# sethdlc -p -i sm0 mode wss:fsk9600 io 0x534 irq 5 dma 3 pario 0x378
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Configure the driver to support the SoundBlaster card we configured above
|
|
to emulate a 4800 bps HAPN modem as device <Literal>sm1</Literal> using the serial port
|
|
located at 0x2f8 to key the Push-To-Talk:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# sethdlc -p -i sm1 mode sbc:hapn4800 io 0x388 irq 10 dma 1 serio 0x2f8
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Configure the driver to support the SoundBlaster card we configured above
|
|
to emulate a 1200 bps AFSK modem as device <Literal>sm1</Literal> using the serial port
|
|
located at 0x2f8 to key the Push-To-Talk:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# sethdlc -p -i sm1 mode sbc:afsk1200 io 0x388 irq 10 dma 1 serio 0x2f8
|
|
</Screen>
|
|
</Para>
|
|
|
|
</Sect4>
|
|
|
|
<Sect4><Title>Configuring the AX.25 channel access parameters</Title>
|
|
|
|
<Para>
|
|
The AX.25 channel access parameters are the equivalent of the KISS ppersist,
|
|
txdelay and slottime type parameters. You use the <Emphasis>sethdlc</Emphasis> utility for
|
|
this as well.
|
|
</Para>
|
|
|
|
<Para>
|
|
Again the <Emphasis>sethdlc</Emphasis> man page is the source of the most complete information
|
|
but another example of two won't hurt:
|
|
</Para>
|
|
|
|
<Para>
|
|
Configure the <Literal>sm0</Literal> device with TxDelay of 100 mS, SlotTime of 50mS,
|
|
PPersist of 128 and full duplex:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# sethdlc -i sm0 -a txd 100 slot 50 ppersist 128 full
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Note that the timing values are in milliseconds.
|
|
</Para>
|
|
|
|
</Sect4>
|
|
|
|
<Sect4><Title>Setting the audio levels and tuning the driver</Title>
|
|
|
|
<Para>
|
|
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 <Emphasis>smdiag</Emphasis> and <Emphasis>smmixer</Emphasis>.
|
|
</Para>
|
|
|
|
<Para>
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term><Emphasis>smdiag</Emphasis></Term>
|
|
<ListItem>
|
|
<Para>
|
|
provides two types of display, either an oscilloscope
|
|
type display or an eye pattern type display.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term><Emphasis>smmixer</Emphasis></Term>
|
|
<ListItem>
|
|
<Para>
|
|
allows you to actually adjust the transmit and
|
|
receive audio levels.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
To start the <Emphasis>smdiag</Emphasis> utility in 'eye' mode for the Soundmodem device
|
|
<Literal>sm0</Literal> you would use:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# smdiag -i sm0 -e
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
To start the <Emphasis>smmixer</Emphasis> utility for the Soundmodem
|
|
device <Literal>sm0</Literal> you would use:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# smmixer -i sm0
|
|
</Screen>
|
|
</Para>
|
|
|
|
</Sect4>
|
|
|
|
<Sect4><Title>Configuring the Kernel AX.25 to use the Soundmodem</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The first step is to configure the device with an AX.25 callsign.
|
|
The <Emphasis>ifconfig</Emphasis> utility may be used to perform this.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /sbin/ifconfig sm0 hw ax25 VK2KTJ-15 up
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
will assign the Soundmodem device <Literal>sm0</Literal> the AX.25
|
|
callsign <Literal>VK2KTJ-15</Literal>. Alternatively you can use the
|
|
<Emphasis>axparms</Emphasis> command, but you still need the
|
|
<Emphasis>ifconfig</Emphasis> utility to bring the device up:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# ifconfig sm0 up
|
|
# axparms -setcall sm0 vk2ktj-15
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
The next step is to create an entry in the <Literal>/etc/ax25/axports</Literal> file
|
|
as you would for any other device. The entry in the <Literal>axports</Literal> file is
|
|
associated with the network device you've configured by the callsign you
|
|
configure. The entry in the <Literal>axports</Literal> file that has the callsign that
|
|
you configured the Soundmodem device with is the one that will be used to
|
|
refer to it.
|
|
</Para>
|
|
|
|
<Para>
|
|
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 NET/ROM or ROSE over it
|
|
as you please.
|
|
</Para>
|
|
|
|
</Sect4>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Creating a user-mode Soundmodem device</Title>
|
|
|
|
<Para>
|
|
<Emphasis>Kernel Compile Options</Emphasis>: not applicable
|
|
|
|
</Para>
|
|
|
|
<!-- TODO:
|
|
Write more detailed documentation on this.
|
|
-->
|
|
|
|
<Para>
|
|
Thomas Sailer has written a sound modem driver that runs in user-mode
|
|
using the kernel sound drivers, so it should work with any sound card
|
|
supported under Linux.
|
|
</Para>
|
|
|
|
<Para>
|
|
The driver is implemented as the user-mode program
|
|
<Literal>soundmodem</Literal>. The graphical
|
|
<Literal>soundmodemconfig</Literal> program allows configuring and
|
|
testing the soundmodem driver. As well as kernel sound support you
|
|
need the kernel AX.25 mkiss driver.
|
|
</Para>
|
|
|
|
<Para>
|
|
The software and documentation can be downloaded from
|
|
<ULink URL="http://www.baycom.org/~tom/ham/soundmodem/">http://www.baycom.org/~tom/ham/soundmodem</ULink>.
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Creating a YAM device</Title>
|
|
|
|
<!-- TODO:
|
|
Write more detailed documentation on this
|
|
-->
|
|
|
|
<Para>
|
|
<Emphasis>Kernel Compile Options</Emphasis>:
|
|
|
|
<Screen>
|
|
Amateur Radio support --->
|
|
[*] Amateur Radio support
|
|
--- Packet Radio protocols
|
|
<*> Amateur Radio AX.25 Level 2 protocol
|
|
...
|
|
AX.25 network device drivers --->
|
|
--- AX.25 network device drivers
|
|
...
|
|
<?> YAM driver for AX.25
|
|
...
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
YAM is Yet Another Modem, a 9600 baud modem designed by Nico Palermo.
|
|
Information on the Linux driver can be found at
|
|
<ULink URL="http://www.teaser.fr/~frible/yam.html">http://www.teaser.fr/~frible/yam.html</ULink>
|
|
while general information on the modem can be found at
|
|
<ULink URL="http://www.microlet.com/yam/">http://www.microlet.com/yam/</ULink>
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Creating a PI card device</Title>
|
|
|
|
<Para>
|
|
<Emphasis>Kernel Compile Options</Emphasis>:
|
|
|
|
<Screen>
|
|
General setup --->
|
|
[*] Networking support
|
|
Network device support --->
|
|
[*] Network device support
|
|
...
|
|
[*] Radio network interfaces
|
|
[*] Ottawa PI and PI/2 support for AX.25
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The PI card device driver creates devices named
|
|
`<Literal>pi[0-9][ab]</Literal>'. The first PI card detected will be
|
|
allocated `<Literal>pi0</Literal>', the second
|
|
`<Literal>pi1</Literal>' etc. The `<Literal>a</Literal>' and
|
|
`<Literal>b</Literal>' 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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /sbin/ifconfig pi0a hw ax25 VK2KTJ-15 up
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This command would configure the first port on the first PI card
|
|
detected with the callsign <Literal>VK2KTJ-15</Literal> and make it
|
|
active. To use the device all you now need to do is to configure an
|
|
entry into your <Literal>/etc/ax25/axports</Literal> file with a
|
|
matching callsign/ssid and you will be ready to continue on.
|
|
</Para>
|
|
|
|
<Para>
|
|
The PI card driver was written by
|
|
<ULink URL="mailto:dp@hydra.carleton.edu">David Perry</ULink>.
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Creating a PacketTwin device</Title>
|
|
|
|
<Para>
|
|
<Emphasis>Kernel Compile Options</Emphasis>:
|
|
|
|
<Screen>
|
|
General setup --->
|
|
[*] Networking support
|
|
Network device support --->
|
|
[*] Network device support
|
|
...
|
|
[*] Radio network interfaces
|
|
[*] Gracilis PackeTwin support for AX.25
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The PacketTwin card device driver creates devices named
|
|
`<Literal>pt[0-9][ab]</Literal>'. The first PacketTwin card detected
|
|
will be allocated `<Literal>pt0</Literal>', the second
|
|
`<Literal>pt1</Literal>' etc. The `<Literal>a</Literal>' and
|
|
`<Literal>b</Literal>' 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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /sbin/ifconfig pt0a hw ax25 VK2KTJ-15 up
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This command would configure the first port on the first PacketTwin
|
|
card detected with the callsign <Literal>VK2KTJ-15</Literal> and make
|
|
it active. To use the device all you now need to do is to configure an
|
|
entry into your <Literal>/etc/ax25/axports</Literal> file with a
|
|
matching callsign/ssid and you will be ready to continue on.
|
|
</Para>
|
|
|
|
<Para>
|
|
The PacketTwin card driver was written by
|
|
<ULink URL="mailto:csmall@triode.apana.org.au">Craig Small</ULink>, VK2XLZ.
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Creating a generic SCC device</Title>
|
|
|
|
<Para>
|
|
<Emphasis>Kernel Compile Options</Emphasis>:
|
|
|
|
<Screen>
|
|
General setup --->
|
|
[*] Networking support
|
|
Network device support --->
|
|
[*] Network device support
|
|
...
|
|
[*] Radio network interfaces
|
|
[*] Z8530 SCC KISS emulation driver for AX.25
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
<ULink URL="mailto:jreuter@poboxes.com">Joerg Reuter</ULink>, DL1BKE,
|
|
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.
|
|
</Para>
|
|
|
|
<Sect4><Title>Obtaining and building the configuration tool package</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
You can obtain the configuration tools package from:
|
|
<ULink URL="http://www.qsl.net/dl1bke">Joerg's web page</ULink>,
|
|
<ULink URL="ftp://db0bm.automation.fh-aachen.de/incoming/dl1bke">ftp://db0bm.automation.fh-aachen.de/incoming/dl1bke</ULink>,
|
|
<ULink URL="ftp://insl1.etec.uni-karlsruhe.de/pub/hamradio/linux/z8530">ftp://insl1.etec.uni-karlsruhe.de/pub/hamradio/linux/z8530</ULink>,
|
|
<ULink URL="ftp://ftp.ucsd.edu/hamradio/packet/tcpip/linux">ftp://ftp.ucsd.edu/hamradio/packet/tcpip/linux</ULink>, or
|
|
<ULink URL="ftp://ftp.ucsd.edu/hamradio/packet/tcpip/incoming">ftp://ftp.ucsd.edu/hamradio/packet/tcpip/incoming</ULink>.
|
|
</Para>
|
|
|
|
<Para>
|
|
You will find multiple versions, choose the one that best suits the
|
|
kernel you intend to use:
|
|
<Literal>z8530drv-2.4a.dl1bke.tar.gz</Literal> for 2.0.* kernels and
|
|
<Literal>z8530drv-utils-3.0.tar.gz</Literal> for 2.1.6 or later kernels.
|
|
</Para>
|
|
|
|
<Para>
|
|
The following commands were what I used to compile and install the package
|
|
for kernel version 2.0.30:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# 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
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
After the above is complete you should have three new programs
|
|
installed in your <Literal>/sbin</Literal> directory:
|
|
<Emphasis>gencfg</Emphasis>, <Emphasis>sccinit</Emphasis> and
|
|
<Emphasis>sccstat</Emphasis>. It is these programs that you will use
|
|
to configure the driver for your card.
|
|
</Para>
|
|
|
|
<Para>
|
|
You will also have a group of new special device files created in your
|
|
<Literal>/dev</Literal> called
|
|
<Literal>scc0</Literal>-<Literal>scc7</Literal>. These will be used
|
|
later and will be the `KISS' devices you will end up using.
|
|
</Para>
|
|
|
|
<Para>
|
|
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 `<Literal>Y</Literal>' to:
|
|
`<Literal>Z8530 SCC kiss emulation driver for AX.25</Literal>' when asked during a
|
|
kernel `<Literal>make config</Literal>'.
|
|
</Para>
|
|
|
|
<Para>
|
|
If you chose to 'make module' then the new <Literal>scc.o</Literal> will have been
|
|
installed in the appropriate <Literal>/lib/modules</Literal> directory and you do
|
|
not need to recompile your kernel. Remember to use the <Emphasis>insmod</Emphasis> command
|
|
to load the module before your try and configure it.
|
|
</Para>
|
|
|
|
</Sect4>
|
|
|
|
<Sect4><Title>Configuring the driver for your card</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
There is more comprehensive documentation in the package and you should
|
|
read this if you have any problems. You should particularly look at
|
|
<Literal>doc/scc_eng.doc</Literal> or <Literal>doc/scc_ger.doc</Literal> 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The main configuration file is read by the <Emphasis>sccinit</Emphasis> program and is
|
|
called <Literal>/etc/z8530drv.conf</Literal>. 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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# sccinit
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
into the <Literal>rc</Literal> file that configures your network and the driver will
|
|
be initialized according to the contents of the configuration file. You must
|
|
do this before you attempt to use the driver.
|
|
</Para>
|
|
|
|
<Sect5><Title>Configuration of the hardware parameters</Title>
|
|
|
|
<Para>
|
|
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 <Literal>#define MAXSCC 4</Literal> in
|
|
<Literal>scc.c</Literal> can be increased if you require support for more.
|
|
</Para>
|
|
|
|
<Para>
|
|
The allowable keywords and arguments are:
|
|
</Para>
|
|
|
|
<Para>
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>chip</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the <Literal>chip</Literal> keyword is used to separate stanzas. It will
|
|
take anything as an argument. The arguments are not used.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>data_a</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>ctrl_a</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>data_b</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>ctrl_b</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>irq</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>pclock</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>board</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the type of board supporting this 8530 SCC. The argument is
|
|
a character string. The allowed values are:
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>PA0HZP</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the PA0HZP SCC Card
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>EAGLE</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the Eagle card
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>PC100</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the DRSI PC100 SCC card
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>PRIMUS</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the PRIMUS-PC (DG9BL) card
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>BAYCOM</Term>
|
|
<ListItem>
|
|
<Para>
|
|
BayCom (U)SCC card
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>escc</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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'.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>vector</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>special</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this keyword is optional and specifies the address of the
|
|
special function register on several cards. The default is 0.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>option</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this keyword is optional and defaults to 0.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
<Para>
|
|
Some example configurations for the more popular cards are as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>BayCom USCC</Term>
|
|
<ListItem>
|
|
<Para>
|
|
|
|
<Screen>
|
|
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
|
|
</Screen>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>PA0HZP SCC card</Term>
|
|
<ListItem>
|
|
<Para>
|
|
|
|
<Screen>
|
|
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
|
|
</Screen>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>DRSI SCC card</Term>
|
|
<ListItem>
|
|
<Para>
|
|
|
|
<Screen>
|
|
chip 1
|
|
data_a 0x303
|
|
data_b 0x301
|
|
ctrl_a 0x302
|
|
ctrl_b 0x300
|
|
irq 7
|
|
pclock 4915200
|
|
board DRSI
|
|
escc no
|
|
</Screen>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
<Para>
|
|
If you already have a working configuration for your card under NOS, then
|
|
you can use the <Emphasis>gencfg</Emphasis> command to convert the PE1CHL NOS driver
|
|
commands into a form suitable for use in the z8530 driver configuration
|
|
file.
|
|
</Para>
|
|
|
|
<Para>
|
|
To use <Emphasis>gencfg</Emphasis> you simply invoke it with the same parameters as you
|
|
used for the PE1CHL driver in NET/NOS. For example:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# gencfg 2 0x150 4 2 0 1 0x168 9 4915200
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
will generate a skeleton configuration for the OptoSCC card.
|
|
</Para>
|
|
|
|
</Sect5>
|
|
|
|
</Sect4>
|
|
|
|
<Sect4><Title>Channel Configuration</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
These keywords and arguments are also written to the <Literal>/etc/z8530drv.conf</Literal>
|
|
file and must appear <Emphasis>after</Emphasis> the hardware parameters section.
|
|
</Para>
|
|
|
|
<Para>
|
|
Sequence is very important in this section, but if you stick with the suggested
|
|
sequence it should work okay. The keywords and arguments are:
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>device</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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. <Literal>/dev/scc0</Literal>
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>speed</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this keyword specifies the speed in bits per second of the
|
|
interface. The argument is an integer: e.g. <Literal>1200</Literal>
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>clock</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this keyword specifies where the clock for the data will
|
|
be sourced. Allowable values are:
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>dpll</Term>
|
|
<ListItem>
|
|
<Para>
|
|
normal halfduplex operation
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>external</Term>
|
|
<ListItem>
|
|
<Para>
|
|
MODEM supplies its own Rx/Tx clock
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>divider</Term>
|
|
<ListItem>
|
|
<Para>
|
|
use fullduplex divider if installed.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>mode</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this keyword specifies the data coding to be used. Allowable
|
|
arguments are: <Literal>nrzi</Literal> or <Literal>nrz</Literal>
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>rxbuffers</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this keyword specifies the number of receive buffers to
|
|
allocate memory for. The argument is an integer, e.g. 8.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>txbuffers</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this keyword specifies the number of transmit buffers to
|
|
allocate memory for. The argument is an integer, e.g. 8.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>bufsize</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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 <Literal>384</Literal>
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>txdelay</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS transmit delay value, the argument is an integer in mS.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>persist</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS persist value, the argument is an integer.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>slot</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS slot time value, the argument is an integer in mS.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>tail</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS transmit tail value, the argument is an integer in mS.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>fulldup</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS full duplex flag, the argument is an integer.
|
|
<Literal>1</Literal>==Full Duplex, <Literal>0</Literal>==Half Duplex.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>wait</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS wait value, the argument is an integer in mS.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>min</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS min value, the argument is an integer in S.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>maxkey</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS maximum keyup time, the argument is an integer in S.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>idle</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS idle timer value, the argument is an integer in S.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>maxdef</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS maxdef value, the argument is an integer.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>group</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS group value, the argument is an integer.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>txoff</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS txoff value, the argument is an integer in mS.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>softdcd</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS softdcd value, the argument is an integer.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>slip</Term>
|
|
<ListItem>
|
|
<Para>
|
|
the KISS slip flag, the argument is an integer.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
</Sect4>
|
|
|
|
<Sect4><Title>Using the driver</Title>
|
|
|
|
<Para>
|
|
To use the driver you simply treat the <Literal>/dev/scc*</Literal> 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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# kissattach -s 4800 /dev/scc0 VK2KTJ
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
You can also use NOS to attach to it in precisely the same way. From JNOS
|
|
for example you would use something like:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
attach asy scc0 0 ax25 scc0 256 256 4800
|
|
</Screen>
|
|
</Para>
|
|
|
|
</Sect4>
|
|
|
|
<Sect4><Title>The <Emphasis>sccstat</Emphasis> and <Emphasis>sccparam</Emphasis> tools</Title>
|
|
|
|
<Para>
|
|
To assist in the diagnosis of problems you can use the <Emphasis>sccstat</Emphasis>
|
|
program to display the current configuration of an SCC device. To use it
|
|
try:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# sccstat /dev/scc0
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
you will displayed a very large amount of information relating to the
|
|
configuration and health of the <Literal>/dev/scc0</Literal> SCC port.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>sccparam</Emphasis> command allows you to change or modify a configuration
|
|
after you have booted. Its syntax is very similar to the NOS <Literal>param</Literal>
|
|
command, so to set the <Literal>txtail</Literal> setting of a device to 100mS you
|
|
would use:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# sccparam /dev/scc0 txtail 0x8
|
|
</Screen>
|
|
</Para>
|
|
|
|
</Sect4>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Creating a BPQ ethernet device</Title>
|
|
|
|
<Para>
|
|
<Emphasis>Kernel Compile Options</Emphasis>:
|
|
|
|
<Screen>
|
|
General setup --->
|
|
[*] Networking support
|
|
Network device support --->
|
|
[*] Network device support
|
|
...
|
|
[*] Radio network interfaces
|
|
[*] BPQ Ethernet driver for AX.25
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The BPQ network devices are named `<Literal>bpq[0-9]</Literal>'. The
|
|
`<Literal>bpq0</Literal>' device is associated with the
|
|
`<Literal>eth0</Literal>' device, the `<Literal>bpq1</Literal>' device
|
|
with the `<Literal>eth1</Literal>' device etc.
|
|
</Para>
|
|
|
|
<Para>
|
|
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
|
|
<ULink URL="Ethernet-HOWTO.html">Ethernet-HOWTO</ULink>
|
|
for more information on how to do this.
|
|
</Para>
|
|
|
|
<Para>
|
|
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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /sbin/ifconfig bpq0 hw ax25 vk2ktj-14 up
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Again, remember that the callsign you specify should match the entry in the
|
|
<Literal>/etc/ax25/axports</Literal> file that you wish to use for this port.
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Configuring the BPQ Node to talk to the Linux AX.25 support</Title>
|
|
|
|
<Para>
|
|
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 modified to look similar to
|
|
this:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
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
|
|
</Screen>
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Creating the <Literal>/etc/ax25/axports</Literal> file</Title>
|
|
|
|
<Para>
|
|
The <Literal>/etc/ax25/axports</Literal> is a simple text file that you create with
|
|
a text editor. The format of the <Literal>/etc/ax25/axports</Literal> file is as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
portname callsign baudrate paclen window description
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
where:
|
|
</Para>
|
|
|
|
<Para>
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>portname</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is a text name that you will refer to the port by.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>callsign</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the AX.25 callsign you want to assign to the port.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>baudrate</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the speed at which you wish the port to communicate with
|
|
your TNC.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>paclen</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the maximum packet length you want to configure the port
|
|
to use for AX.25 connected mode connections.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>window</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the AX.25 window (K) parameter. This is the same as the
|
|
<Literal>MAXFRAME</Literal> setting of many TNC's.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>description</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is a textual description of the port.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
<Para>
|
|
In my case, mine looks like:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
radio VK2KTJ-15 4800 256 2 4800bps 144.800 MHz
|
|
ether VK2KTJ-14 10000000 256 2 BPQ/ethernet device
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Configuring AX.25 routing</Title>
|
|
|
|
<Para>
|
|
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 <Emphasis>axparms</Emphasis> command enables
|
|
you to do this. Again, the <Emphasis>man</Emphasis> page offers a
|
|
complete description, but a simple example might be:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /usr/sbin/axparms -route add radio VK2XLZ VK2SUT
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This command would set a digipeater entry for
|
|
<Literal>VK2XLZ</Literal> via <Literal>VK2SUT</Literal> on the AX.25
|
|
port named <Literal>radio</Literal>.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Configuring an AX.25 interface for TCP/IP</Title>
|
|
|
|
<Para>
|
|
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 <Emphasis>kissattach</Emphasis> command has an option
|
|
that allows you to specify an IP address. The more conventional method
|
|
using the <Emphasis>ifconfig</Emphasis> command will work on all
|
|
interface types.
|
|
</Para>
|
|
|
|
<Para>
|
|
So, modifying the previous KISS example:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /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
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
to create the AX.25 interface with an IP address of <Literal>44.136.8.5</Literal> and
|
|
an <Literal>MTU</Literal> of <Literal>512</Literal> bytes. You should still use the
|
|
<Emphasis>ifconfig</Emphasis> to configure the other parameters if necessary.
|
|
</Para>
|
|
|
|
<Para>
|
|
If you have any other interface type then you use the <Emphasis>ifconfig</Emphasis> 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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /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
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
To test it out, try a ping or a telnet to a local host.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# ping -i 5 44.136.8.58
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Note the use of the `<Literal>-i 5</Literal>' arguments to
|
|
<Emphasis>ping</Emphasis> to tell it to send pings every 5 seconds
|
|
instead of its default of 1 second.
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Configuring a NET/ROM port</Title>
|
|
|
|
<Para>
|
|
The NET/ROM protocol relies on, and uses the AX.25 ports you have created.
|
|
The NET/ROM protocol rides on top of the AX.25 protocol. To configure NET/ROM
|
|
on an AX.25 interface you must configure two files. One file describes the
|
|
NET/ROM interfaces, and the other file describes which of the AX.25 ports
|
|
will carry NET/ROM. You can configure multiple NET/ROM ports, each with its
|
|
own callsign and alias, the same procedure applies for each.
|
|
</Para>
|
|
|
|
<Sect2><Title>Configuring <Literal>/etc/ax25/nrports</Literal></Title>
|
|
|
|
<Para>
|
|
The first is the <Literal>/etc/ax25/nrports</Literal> file. This file describes
|
|
the NET/ROM ports in much the same way as the <Literal>/etc/ax25/axports</Literal>
|
|
file describes the AX.25 ports. Each NET/ROM device you wish to create
|
|
must have an entry in the <Literal>/etc/ax25/nrports</Literal> file. Normally
|
|
a Linux machine would have only one NET/ROM 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 separate NET/ROM alias and
|
|
so you would create more than one.
|
|
</Para>
|
|
|
|
<Para>
|
|
This file is formatted as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
name callsign alias paclen description
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Where:
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>name</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the text name that you wish to refer to the port by.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>callsign</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the callsign that the NET/ROM traffic from this port will use. Note,
|
|
this is <Emphasis>not</Emphasis> that address that users should
|
|
connect to to get access to a <Emphasis>node</Emphasis> style
|
|
interface. (The node program is covered later). This callsign/ssid
|
|
should be unique and should not appear elsewhere in either of the
|
|
<Literal>/etc/ax25/axports</Literal> or the
|
|
<Literal>/etc/ax25/nrports</Literal> files.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>alias</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the NET/ROM alias this port will have assigned to it.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>paclen</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the maximum size of NET/ROM frames transmitted by this port.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>description</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is a free text description of the port.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
<Para>
|
|
An example would look something like the following:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
netrom VK2KTJ-9 LINUX 236 Linux Switch Port
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This example creates a NET/ROM port known to the rest of the NET/ROM network
|
|
as `<Literal>LINUX:VK2KTJ-9</Literal>'.
|
|
</Para>
|
|
|
|
<Para>
|
|
This file is used by programs such as the <Emphasis>call</Emphasis> program.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Configuring <Literal>/etc/ax25/nrbroadcast</Literal></Title>
|
|
|
|
<Para>
|
|
The second file is the <Literal>/etc/ax25/nrbroadcast</Literal> 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 NET/ROM traffic on.
|
|
</Para>
|
|
|
|
<Para>
|
|
This file is formatted as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
axport min_obs def_qual worst_qual verbose
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Where:
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>axport</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the port name obtained from the
|
|
<Literal>/etc/ax25/axports</Literal> file. If you do not have an entry in
|
|
<Literal>/etc/ax25/nrbroadcasts</Literal> for a port then this means that no NET/ROM
|
|
routing will occur and any received NET/ROM broadcasts will be ignored for that
|
|
port.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>min_obs</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the minimum obselesence value for the port.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>def_qual</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the default quality for the port.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>worst_qual</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the worst quality value for the port, any routes under
|
|
this quality will be ignored.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>verbose</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is a flag determining whether full NET/ROM routing broadcasts
|
|
will occur from this port or only a routing broadcast advertising the node
|
|
itself.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
<Para>
|
|
An example would look something like the following:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
radio 1 200 100 1
|
|
</Screen>
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Creating the NET/ROM Network device</Title>
|
|
|
|
<Para>
|
|
When you have the two configuration files completed you must create
|
|
the NET/ROM device in much the same way as you did for the AX.25
|
|
devices. This time you use the <Emphasis>nrattach</Emphasis>
|
|
command. The <Emphasis>nrattach</Emphasis> works in just the same way
|
|
as the <Emphasis>axattach</Emphasis> command except that it creates
|
|
NET/ROM network devices called `<Literal>nr[0-9]</Literal>'. Again, the
|
|
first time you use the <Emphasis>nrattach</Emphasis> command it
|
|
creates the `<Literal>nr0</Literal>' device, the second time it
|
|
creates the `<Literal>nr1</Literal>' network devices etc. To create
|
|
the network device for the NET/ROM port we've defined we would use:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# nrattach netrom
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This command would start the NET/ROM device (<Literal>nr0</Literal>)
|
|
named <Literal>netrom</Literal> configured with the details specified
|
|
in the <Literal>/etc/ax25/nrports</Literal> file.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Starting the NET/ROM daemon</Title>
|
|
|
|
<Para>
|
|
The Linux kernel does all of the NET/ROM protocol and switching, but does not
|
|
manage some functions. The NET/ROM daemon manages the NET/ROM routing tables
|
|
and generates the NET/ROM routing broadcasts. You start NET/ROM daemon with
|
|
the command:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /usr/sbin/netromd -i
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
You should soon see the <Literal>/proc/net/nr_neigh</Literal> file filling up with
|
|
information about your NET/ROM neighbours.
|
|
</Para>
|
|
|
|
<Para>
|
|
Remember to put the <Literal>/usr/sbin/netromd</Literal> command in your
|
|
<Emphasis>rc</Emphasis> files so that it is started automatically each time you reboot.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Configuring NET/ROM routing. </Title>
|
|
|
|
<Para>
|
|
You may wish to configure static NET/ROM routes for specific hosts.
|
|
The <Emphasis>nrparms</Emphasis> command enables you to do
|
|
this. Again, the <Emphasis>man</Emphasis> page offers a complete
|
|
description, but a simple example might be:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /usr/sbin/nrparms -nodes VK2XLZ-10 + #MINTO 120 5 radio VK2SUT-9
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This command would set a NET/ROM route to <Literal>#MINTO:VK2XLZ-10</Literal> via a neighbour
|
|
<Literal>VK2SUT-9</Literal> on my AX.25 port called `<Literal>radio</Literal>'.
|
|
</Para>
|
|
|
|
<Para>
|
|
You can manually create entries for new neighbours using the <Emphasis>nrparms</Emphasis>
|
|
command as well. For example:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /usr/sbin/nrparms -routes radio VK2SUT-9 + 120
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This command would create <Literal>VK2SUT-9</Literal> as a NET/ROM neighbour with a quality
|
|
of <Literal>120</Literal> and this will be locked and will not be deleted automatically.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Configuring a NET/ROM interface for TCP/IP</Title>
|
|
|
|
<Para>
|
|
Configuring a NET/ROM interface for TCP/IP is almost identical to configuring
|
|
an AX.25 interface for TCP/IP.
|
|
</Para>
|
|
|
|
<Para>
|
|
Again you can either specify the ip address and mtu on the <Emphasis>nrattach</Emphasis>
|
|
command line, or use the <Emphasis>ifconfig</Emphasis> and <Emphasis>route</Emphasis> commands, but
|
|
you need to manually add <Emphasis>arp</Emphasis> entries for hosts you wish to route to
|
|
because there is no mechanism available for your machine to learn what
|
|
NET/ROM address it should use to reach a particular IP host.
|
|
</Para>
|
|
|
|
<Para>
|
|
So, to create an <Literal>nr0</Literal> device with an IP address of <Literal>44.136.8.5</Literal>,
|
|
an mtu of <Literal>512</Literal> and configured with the details from the
|
|
<Literal>/etc/ax25/nrports</Literal> file for a NET/ROM port named <Literal>netrom</Literal>
|
|
you would use:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /usr/sbin/nrattach -i 44.136.8.5 -m 512 netrom
|
|
# route add 44.136.8.5 nr0
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
or you could use something like the following commands manually:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /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
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Then for each IP host you wish to reach via NET/ROM you need to set route and
|
|
arp entries. To reach a destination host with an IP address of
|
|
<Literal>44.136.80.4</Literal> at NET/ROM address <Literal>BBS:VK3BBS</Literal> via a NET/ROM
|
|
neighbour with callsign <Literal>VK2SUT-0</Literal> you would use commands as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# 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
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
The `<Literal>120</Literal>' and `<Literal>6</Literal>' arguments to
|
|
the <Emphasis>nrparms</Emphasis> command are the NET/ROM
|
|
<Emphasis>quality</Emphasis> and <Emphasis>obsolescence
|
|
count</Emphasis> values for the route.
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Configuring a ROSE port</Title>
|
|
|
|
<Para>
|
|
The ROSE packet layer protocol is similar to layer three of the X.25
|
|
specification. The kernel based ROSE support is a <Emphasis>modified</Emphasis> version of the
|
|
<ULink URL="http://fpac.lmi.ecp.fr/f1oat/f1oat.html">FPAC Rose implementation</ULink>.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Sect2><Title>Configuring <Literal>/etc/ax25/rsports</Literal> </Title>
|
|
|
|
<Para>
|
|
The file where you configure your ROSE interfaces is the
|
|
<Literal>/etc/ax25/rsports</Literal> file. This file describes the ROSE port in much
|
|
the same way as the <Literal>/etc/ax25/axports</Literal> file describes the AX.25 ports.
|
|
</Para>
|
|
|
|
<Para>
|
|
This file is formatted as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
name address description
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Where:
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>name</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the text name that you wish to refer to the port by.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>address</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the 10 digit ROSE address you wish to assign to this port.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>description</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is a free text description of the port.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
<Para>
|
|
An example would look something like the following:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
rose 5050294760 Rose Port
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Note that ROSE will use the default callsign/ssid configured on each
|
|
AX.25 port unless you specify otherwise.
|
|
</Para>
|
|
|
|
<Para>
|
|
To configure a separate callsign/ssid for ROSE to use on each port you
|
|
use the <Emphasis>rsparms</Emphasis> command as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /usr/sbin/rsprams -call VK2KTJ-10
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This example would make Linux listen for and use the callsign/ssid
|
|
<Literal>VK2KTJ-10</Literal> on all of the configured AX.25 ports for ROSE calls.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Creating the ROSE Network device</Title>
|
|
|
|
<Para>
|
|
When you have created the <Literal>/etc/ax25/rsports</Literal> 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 <Emphasis>rsattach</Emphasis>
|
|
command. The <Emphasis>rsattach</Emphasis> command creates network
|
|
devices named `<Literal>rose[0-5]</Literal>'. The first time you use
|
|
the <Emphasis>rsattach</Emphasis> command it create the
|
|
`<Literal>rose0</Literal>' device, the second time it creates the
|
|
`<Literal>rose1</Literal>' device etc. For example:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# rsattach rose
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This command would start the ROSE device (<Literal>rose0</Literal>) configured with the
|
|
details specified in the <Literal>/etc/ax25/rsports</Literal> file for the entry
|
|
named `<Literal>rose</Literal>'.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Configuring ROSE Routing</Title>
|
|
|
|
<Para>
|
|
The ROSE protocol currently supports only static routing. The <Emphasis>rsparms</Emphasis>
|
|
utility allows you to configure your ROSE routing table under Linux.
|
|
</Para>
|
|
|
|
<Para>
|
|
For example:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# rsparms -nodes add 5050295502 radio vk2xlz
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
would add a route to ROSE node <Literal>5050295502</Literal> via an
|
|
AX.25 port named `<Literal>radio</Literal>' in your
|
|
<Literal>/etc/ax25/axports</Literal> file to a neighbour with the
|
|
callsign <Literal>VK2XLZ</Literal>.
|
|
</Para>
|
|
|
|
<Para>
|
|
You may specify a route with a mask to capture a number of ROSE destinations
|
|
into a single routing entry. The syntax looks like:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# rsparms -nodes add 5050295502/4 radio vk2xlz
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
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 <Literal>5050</Literal>. An alternate form
|
|
for this command is:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# rsparms -nodes add 5050/4 radio vk2xlz
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
which is probably the less ambiguous form.
|
|
</Para>
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Making AX.25/NET/ROM/ROSE calls</Title>
|
|
|
|
<Para>
|
|
Now that you have all of your AX.25, NET/ROM and ROSE interfaces configured
|
|
and active, you should be able to make test calls.
|
|
</Para>
|
|
|
|
<Para>
|
|
The AX.25 Utilities package includes a program called `<Emphasis>call</Emphasis>' which
|
|
is a split screen terminal program for AX.25, NET/ROM and ROSE.
|
|
</Para>
|
|
|
|
<Para>
|
|
A simple AX.25 call would look like:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
/usr/bin/call radio VK2DAY via VK2SUT
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
A simple NET/ROM call to a node with an alias of <Literal>SUNBBS</Literal> would look like:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
/usr/bin/call netrom SUNBBS
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
A simple ROSE call to <Literal>HEARD</Literal> at node
|
|
<Literal>5050882960</Literal> would look like:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
/usr/bin/call rose HEARD 5050882960
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Note: you must tell <Emphasis>call</Emphasis> 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>call</Emphasis> program is a line mode terminal program for making
|
|
AX.25 calls. It recognizes lines that start with `<Literal>˜</Literal>' as command lines.
|
|
The `<Literal>˜.</Literal>' command will close the connection.
|
|
</Para>
|
|
|
|
<Para>
|
|
Please refer to the man page in <Literal>/usr/man</Literal> for more information.
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Configuring Linux to accept Packet connections</Title>
|
|
|
|
<Para>
|
|
Linux is a powerful operating system and offers a great deal of flexibility
|
|
in how it is configured. With this flexibility comes a cost in configuring
|
|
it to do what you want. When configuring your Linux machine to accept incoming
|
|
AX.25, NET/ROM or ROSE connections there are a number of questions you need to
|
|
ask yourself. The most important of which is: "What do I want users to see when
|
|
they connect?". People are developing neat little applications that may be
|
|
used to provide services to callers, a simple example is the <Emphasis>pms</Emphasis> program
|
|
included in the AX.25 utilities, a more complex example is the <Emphasis>node</Emphasis> program
|
|
also included in the AX.25 utilities. Alternatively you might want to give
|
|
users a login prompt so that they can make use of a shell account, or you
|
|
might even have written your own program, such as a customized database or a
|
|
game, that you want people to connect to. Whatever you choose, you must tell
|
|
the AX.25 software about this so that it knows what software to run when it
|
|
accepts an incoming AX.25 connection.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>ax25d</Emphasis> program is similar to the <Emphasis>inetd</Emphasis> program commonly used
|
|
to accept incoming TCP/IP connections on UNIX machines. It sits and listens
|
|
for incoming connections, when it detects one it goes away and checks a
|
|
configuration file to determine what program to run and connect to that
|
|
connection. Since this the standard tool for accepting incoming AX.25, NET/ROM
|
|
and ROSE connections I'll describe how to configure it.
|
|
</Para>
|
|
|
|
<Sect2><Title>Creating the <Literal>/etc/ax25/ax25d.conf</Literal> file</Title>
|
|
|
|
<Para>
|
|
This file is the configuration file for the <Emphasis>ax25d</Emphasis> AX.25 daemon which
|
|
handles incoming AX.25, NET/ROM and ROSE connections.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The general format of the <Literal>ax25d.conf</Literal> file is as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# 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>
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Where:
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>#</Term>
|
|
<ListItem>
|
|
<Para>
|
|
at the start of a line marks a comment and is completely ignored
|
|
by the <Emphasis>ax25d</Emphasis> program.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term><port_name></Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the name of the AX.25, NET/ROM or ROSE port as specified in the
|
|
<Literal>/etc/ax25/axports</Literal>,
|
|
<Literal>/etc/ax25/nrports</Literal> and
|
|
<Literal>/etc/ax25/rsports</Literal> files. The name of the port is
|
|
surrounded by the `<Literal>[]</Literal>' brackets if it is an AX.25
|
|
port, the `<Literal><></Literal>' brackets if it is a NET/ROM
|
|
port, or the `<Literal>{}</Literal>' brackets if it is a
|
|
ROSE port. There is an alternate form for this field, and that is use
|
|
prefix the port name with `<Literal>callsign/ssid via</Literal>' to
|
|
indicate that you wish accept calls to the callsign/ssid via this
|
|
interface. The example should more clearly illustrate this.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term><peer></Term>
|
|
<ListItem>
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>window</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the AX.25 Window parameter (K) or MAXFRAME parameter for
|
|
this configuration.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>T1</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the Frame retransmission (T1) timer in half second units.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>T2</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the amount of time the AX.25 software will wait for another
|
|
incoming frame before preparing a response in 1 second units.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>T3</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the amount of time of inactivity before the AX.25 software
|
|
will disconnect the session in 1 second units.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>idle</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the idle timer value in seconds.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>N2</Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the number of consecutive retransmissions that will occur
|
|
before the connection is closed.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term><mode></Term>
|
|
<ListItem>
|
|
<Para>
|
|
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.
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>u/U</Term>
|
|
<ListItem>
|
|
<Para>
|
|
UTMP - currently unsupported.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>v/V</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Validate call - currently unsupported.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>q/Q</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Quiet - Don't log connection
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>n/N</Term>
|
|
<ListItem>
|
|
<Para>
|
|
check NET/ROM Neighbour - currently unsupported.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>d/D</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Disallow Digipeaters - Connections must be direct, not digipeated.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>l/L</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Lockout - Don't allow connection.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>*/0</Term>
|
|
<ListItem>
|
|
<Para>
|
|
marker - place marker, no mode set.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term><uid></Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the userid that the program to be run to support the
|
|
connection should be run as.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term><cmd></Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the full pathname of the command to be run, with no
|
|
arguments specified.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term><cmd-name></Term>
|
|
<ListItem>
|
|
<Para>
|
|
is the text that should appear in a <Emphasis>ps</Emphasis> as
|
|
the command name running (normally the same as <cmd> except without the
|
|
directory path information.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term><arguments></Term>
|
|
<ListItem>
|
|
<Para>
|
|
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:
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>%d</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Name of the port the connection was received on.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>%U</Term>
|
|
<ListItem>
|
|
<Para>
|
|
AX.25 callsign of the connected party without the SSID, in
|
|
uppercase.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>%u</Term>
|
|
<ListItem>
|
|
<Para>
|
|
AX.25 callsign of the connected party without the SSID, in
|
|
lowercase.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>%S</Term>
|
|
<ListItem>
|
|
<Para>
|
|
AX.25 callsign of the connected party with the SSID, in
|
|
uppercase.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>%s</Term>
|
|
<ListItem>
|
|
<Para>
|
|
AX.25 callsign of the connected party with the SSID, in
|
|
lowercase.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>%P</Term>
|
|
<ListItem>
|
|
<Para>
|
|
AX.25 callsign of the remote node that the connection came
|
|
in from without the SSID, in uppercase.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>%p</Term>
|
|
<ListItem>
|
|
<Para>
|
|
AX.25 callsign of the remote node that the connection came
|
|
in from without the SSID, in lowercase.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>%R</Term>
|
|
<ListItem>
|
|
<Para>
|
|
AX.25 callsign of the remote node that the connection came
|
|
in from with the SSID, in uppercase.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>%r</Term>
|
|
<ListItem>
|
|
<Para>
|
|
AX.25 callsign of the remote node that the connection came
|
|
in from with the SSID, in lowercase.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
<Para>
|
|
You need one section in the above format for each AX.25, NET/ROM or ROSE
|
|
interface you want to accept incoming AX.25, NET/ROM or ROSE connections on.
|
|
</Para>
|
|
|
|
<Para>
|
|
There are two special lines in the paragraph, one starts with the string
|
|
`<Literal>parameters</Literal>' and the other starts with the string `<Literal>default</Literal>'
|
|
(yes there is a difference). These lines serve special functions.
|
|
</Para>
|
|
|
|
<Para>
|
|
The `<Literal>default</Literal>' 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 `<Literal>default</Literal>'
|
|
rule. If you don't have a `<Literal>default</Literal>' rule, then any connections not
|
|
matching any specific rule will be disconnected immediately without notice.
|
|
</Para>
|
|
|
|
<Para>
|
|
The `<Literal>parameters</Literal>' 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 `<Literal>parameters</Literal>' 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
|
|
`<Literal>parameters</Literal>' entry. The trap is that the these
|
|
defaults apply <Emphasis>only</Emphasis> to those rules
|
|
<Emphasis>below</Emphasis> the `<Literal>parameters</Literal>' line,
|
|
not to those above. You may have more than one
|
|
`<Literal>parameters</Literal>' rule per interface definition, and in
|
|
this way you may create groups of default configurations. It is
|
|
important to note that the `<Literal>parameters</Literal>' rule does
|
|
not allow you to set the `<Literal>uid</Literal>' or
|
|
`<Literal>command</Literal>' fields.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>A simple example <Literal>ax25d.conf</Literal> file</Title>
|
|
|
|
<Para>
|
|
Okay, an illustrative example:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# 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
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This example says that anybody attempting to connect to the callsign
|
|
`<Literal>VK2KTJ-0</Literal>' heard on the AX.25 port called `<Literal>radio</Literal>' will have
|
|
the following rules applied:
|
|
</Para>
|
|
|
|
<Para>
|
|
Anyone whose callsign is set to `NOCALL' should be locked out, note the
|
|
use of mode `L'.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Literal>parameters</Literal> line changes two parameters from the
|
|
kernel defaults (Window and T1) and will run the
|
|
<Emphasis>/usr/sbin/axspawn</Emphasis> program for them. Any copies of
|
|
<Emphasis>/usr/sbin/axspawn</Emphasis> run this way will appear as
|
|
<Emphasis>axspawn</Emphasis> in a <Emphasis>ps</Emphasis> listing for
|
|
convenience. The next two lines provide definitions for two stations
|
|
who will receive those permissions.
|
|
</Para>
|
|
|
|
<Para>
|
|
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
|
|
<Emphasis>pms</Emphasis> 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
|
|
<Literal>VK2KTJ</Literal>. (See the `Configuring the PMS' section below for more details).
|
|
</Para>
|
|
|
|
<Para>
|
|
The next configuration accepts calls to <Literal>VK2KTJ-1</Literal>
|
|
via the <Literal>radio</Literal> port. It runs the
|
|
<Emphasis>node</Emphasis> program for everybody that connects to it.
|
|
</Para>
|
|
|
|
<Para>
|
|
The next configuration is a NET/ROM configuration, note the use of the
|
|
greater-then and less-than braces instead of the square brackets. These
|
|
denote a NET/ROM configuration. This configuration is simpler, it simply
|
|
says that anyone connecting to our NET/ROM port called `<Literal>netrom</Literal>' will
|
|
have the <Emphasis>node</Emphasis> program run for them, unless they have a callsign of
|
|
`<Literal>NOCALL</Literal>' in which case they will be locked out.
|
|
</Para>
|
|
|
|
<Para>
|
|
The last two configurations are for incoming ROSE connections. The first
|
|
for people who have placed calls to `<Literal>vk2ktj-0</Literal>' and the second for
|
|
`<Literal>VK2KTJ-1</Literal> 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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
|
|
<Literal>ax25d.conf</Literal> <Emphasis>man</Emphasis> page. A more
|
|
detailed example is included in the <Literal>ax25-utils</Literal>
|
|
package that might be useful to you too.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Starting <Emphasis>ax25d</Emphasis></Title>
|
|
|
|
<Para>
|
|
When you have the two configuration files completed you start <Emphasis>ax25d</Emphasis>
|
|
with the command:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /usr/sbin/ax25d
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
When this is run people should be able to make AX.25 connections to
|
|
your Linux machine. Remember to put the <Literal>ax25d</Literal>
|
|
command in your <Emphasis>rc</Emphasis> files so that it is started
|
|
automatically when you reboot each time.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Configuring the <Emphasis>node</Emphasis> software</Title>
|
|
|
|
<Para>
|
|
The <Emphasis>node</Emphasis> software was developed by
|
|
<ULink URL="mailto:tomi.manninen@hut.fi">Tomi Manninen</ULink>
|
|
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, NET/ROM, 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The node would normally be invoked from the <Emphasis>ax25d</Emphasis>
|
|
program although it is also capable of being invoked from the TCP/IP
|
|
<Emphasis>inetd</Emphasis> program to allow users to telnet to your
|
|
machine and obtain access to it, or by running it from the command
|
|
line.
|
|
</Para>
|
|
|
|
<Sect2><Title>Creating the <Literal>/etc/ax25/node.conf</Literal> file</Title>
|
|
|
|
<Para>
|
|
The <Literal>node.conf</Literal> file is where the main configuration of the node
|
|
takes place. It is a simple text file and its format is as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /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
|
|
|
|
# NET/ROM port
|
|
# This is the name of the NET/ROM port that will be used for
|
|
# outgoing NET/ROM 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"
|
|
|
|
# External 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
|
|
</Screen>
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Creating the <Literal>/etc/ax25/node.perms</Literal> file</Title>
|
|
|
|
<Para>
|
|
The <Emphasis>node</Emphasis> 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 <Literal>node.perms</Literal> 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>user</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>method</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Each protocol or access method is also given permissions. For example you
|
|
might allow users who have connected via AX.25 or NET/ROM 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:
|
|
|
|
<informaltable frame=all>
|
|
<tgroup cols=2>
|
|
<thead>
|
|
<row><entry>Method</entry><entry>Description</entry></row>
|
|
</thead>
|
|
<tbody>
|
|
|
|
<row>
|
|
<entry>ampr</entry>
|
|
<entry>User is telnet connected from an amprnet address (44.0.0.0)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ax25</entry>
|
|
<entry>User connected by AX.25</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>host</entry>
|
|
<entry>User started node from command line</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>inet</entry>
|
|
<entry>user is telnet connected from a non-loca, non-ampr address.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>local</entry>
|
|
<entry>User is telnet connected from a 'local' host</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>netrom</entry>
|
|
<entry>User connected by NET/ROM</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>rose</entry>
|
|
<entry>User connected by ROSE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>*</entry>
|
|
<entry>User connected by any means.</entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
|
|
<VarListEntry>
|
|
<Term>port</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>password</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>permissions</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<informaltable frame=all>
|
|
<tgroup cols=2>
|
|
<thead>
|
|
<row><entry>Value</entry><entry>Description</entry></row>
|
|
</thead>
|
|
<tbody>
|
|
|
|
<row>
|
|
<entry>1</entry>
|
|
<entry>Login allowed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>2</entry>
|
|
<entry>AX.25 (C)onnects allowed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>4</entry>
|
|
<entry>NET/ROM (C)onnects allowed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>8</entry>
|
|
<entry>(T)elnet to local hosts allowed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>16</entry>
|
|
<entry>(T)elnet to amprnet (44.0.0.0) hosts allowed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>32</entry>
|
|
<entry>(T)elnet to non-local, non-amprnet hosts allowed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>64</entry>
|
|
<entry>Hidden ports allowed for AX.25 (C)onnects.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>128</entry>
|
|
<entry>ROSE (C)onnects allowed.</entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
<Para>
|
|
A sample <Literal>nodes.perms</Literal> might look like:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /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, NET/ROM, 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
|
|
</Screen>
|
|
|
|
</Para>
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Configuring <Emphasis>node</Emphasis> to run from <Emphasis>ax25d</Emphasis></Title>
|
|
|
|
<Para>
|
|
The <Emphasis>node</Emphasis> program would normally be run by the
|
|
<Emphasis>ax25d</Emphasis> program. To do this you need to add
|
|
appropriate rules to the <Literal>/etc/ax25/ax25d.conf</Literal>
|
|
file. In my configuration I wanted users to have a choice of either
|
|
connecting to the <Emphasis>node</Emphasis> or connecting to other
|
|
services. <Emphasis>ax25d</Emphasis> allows you to do this by cleverly
|
|
creating port aliases. For example, given the
|
|
<Emphasis>ax25d</Emphasis> configuration presented above, I want to
|
|
configure <Emphasis>node</Emphasis> so that all users who connect to
|
|
<Literal>VK2KTJ-1</Literal> are given the node. To do this I add the
|
|
following to my <Literal>/etc/ax25/ax25d.conf</Literal> file:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
[vk2ktj-1 via radio]
|
|
default * * * * * 0 root /usr/sbin/node node
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This says that the Linux kernel code will answer any connection
|
|
requests for the callsign `<Literal>VK2KTJ-1</Literal>' heard on the
|
|
AX.25 port named `<Literal>radio</Literal>', and will cause the
|
|
<Emphasis>node</Emphasis> program to be run.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Configuring <Emphasis>node</Emphasis> to run from <Emphasis>inetd</Emphasis></Title>
|
|
|
|
<Para>
|
|
If you want users to be able to telnet a port on your machine and obtain
|
|
access to the <Emphasis>node</Emphasis> 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 <Emphasis>node</Emphasis> in his documentation.
|
|
</Para>
|
|
|
|
<Para>
|
|
You need to modify two files.
|
|
</Para>
|
|
|
|
<Para>
|
|
To <Literal>/etc/services</Literal> you should add:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
node 3694/tcp #OH2BNS's node software
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
and to <Literal>/etc/inetd.conf</Literal> you should add:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
node stream tcp nowait root /usr/sbin/node node
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
When this is done, and you have restarted the <Emphasis>inetd</Emphasis> 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
|
|
<Emphasis>node</Emphasis>.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Configuring <Emphasis>axspawn</Emphasis></Title>
|
|
|
|
<Para>
|
|
The <Emphasis>axspawn</Emphasis> 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 <Emphasis>ax25d</Emphasis> program as
|
|
described above in a manner similar to the <Emphasis>node</Emphasis>
|
|
program. To allow a user to log in to your machine you should add a
|
|
line similar to the following into your
|
|
<Literal>/etc/ax25/ax25d.conf</Literal> file:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
default * * * * * 1 root /usr/sbin/axspawn axspawn %u
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
If the line ends in the <Literal>+</Literal> 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
|
|
<Emphasis>axspawn</Emphasis> program run when they connect. When <Emphasis>axspawn</Emphasis> is
|
|
run it first checks that the command line argument it is supplied is a legal
|
|
callsign, strips the SSID, then it checks that <Literal>/etc/passwd</Literal> file to
|
|
see if that user has an account configured. If there is an account, and the
|
|
password is either <Literal>""</Literal> (null) or <Literal>+</Literal> 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 <Literal>/etc/passwd</Literal>
|
|
file then <Emphasis>axspawn</Emphasis> may be configured to automatically create one.
|
|
</Para>
|
|
|
|
<Sect2><Title>Creating the <Literal>/etc/ax25/axspawn.conf</Literal> file</Title>
|
|
|
|
<Para>
|
|
You can alter the behaviour of <Emphasis>axspawn</Emphasis> in various ways by use of
|
|
the <Literal>/etc/ax25/axspawn.conf</Literal> file. This file is formatted as
|
|
follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /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
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The eight configurable characteristics of <Emphasis>axspawn</Emphasis> are as follows:
|
|
</Para>
|
|
|
|
<Para>
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>#</Term>
|
|
<ListItem>
|
|
<Para>
|
|
indicates a comment.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>create</Term>
|
|
<ListItem>
|
|
<Para>
|
|
if this field is set to <Literal>yes</Literal> then <Emphasis>axspawn</Emphasis>
|
|
will attempt to automatically create a user account for any user who connects
|
|
and does not already have an entry in the <Literal>/etc/passwd</Literal> file.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>guest</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this field names the login name of the account that will
|
|
be used for people who connect who do not already have accounts if
|
|
<Emphasis>create</Emphasis> is set to <Literal>no</Literal>. This is usually <Literal>ax25</Literal> or
|
|
<Literal>guest</Literal>.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>group</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this field names the group name that will be used for any
|
|
users who connect and do not already have an entry in the <Literal>/etc/passwd</Literal>
|
|
file.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>first_uid</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this is the number of the first userid that will be
|
|
automatically created for new users.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>max_uid</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this is the maximum number that will be used for the userid
|
|
of new users.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>home</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this is the home (login) directory of new users.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>shell</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this is the login shell of any new users.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>associate</Term>
|
|
<ListItem>
|
|
<Para>
|
|
this flag indicates whether outgoing AX.25 connections
|
|
made by this user after they login will use their own callsign, or your
|
|
stations callsign.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Configuring the <Emphasis>pms</Emphasis></Title>
|
|
|
|
<Para>
|
|
The <Emphasis>pms</Emphasis> program is an implementation of a simple personal message
|
|
system. It was originally written by Alan Cox.
|
|
<ULink URL="mailto:dcb@vectorbd.com">Dave Brown</ULink>, N2RJT,
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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 <Literal>ax25d.conf</Literal> file so that connected users
|
|
are presented with the PMS.
|
|
</Para>
|
|
|
|
<Sect2><Title>Create the <Literal>/etc/ax25/pms.motd</Literal> file</Title>
|
|
|
|
<Para>
|
|
The <Literal>/etc/ax25/pms.motd</Literal> 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.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Create the <Literal>/etc/ax25/pms.info</Literal> file</Title>
|
|
|
|
<Para>
|
|
The <Literal>/etc/ax25/pms.info</Literal> 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
|
|
<Literal>Info</Literal> command from the <Literal>PMS></Literal> prompt.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Associate AX.25 callsigns with system users</Title>
|
|
|
|
<Para>
|
|
When a connected user sends mail to an AX.25 callsign, the <Emphasis>pms</Emphasis> 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.
|
|
</Para>
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Add the PMS to the <Literal>/etc/ax25/ax25d.conf</Literal> file</Title>
|
|
|
|
<Para>
|
|
Adding the <Emphasis>pms</Emphasis> to your <Literal>ax25d.conf</Literal> 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 NET/ROM by convention expect the end-of-line
|
|
to be <Emphasis>carriage return, linefeed</Emphasis> while the standard UNIX end-of-line is
|
|
just <Emphasis>newline</Emphasis>. 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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
default 1 10 5 100 5 0 root /usr/sbin/pms pms -a -o vk2ktj
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This simply runs the <Emphasis>pms</Emphasis> program, telling it that it is an AX.25
|
|
connection it is connected to and that the PMS owner is <Literal>vk2ktj</Literal>.
|
|
Check the <Emphasis>man</Emphasis> page for what you should specify for other connection
|
|
methods.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Test the PMS</Title>
|
|
|
|
<Para>
|
|
To test the PMS, you can try the following command from the command line:
|
|
# /usr/sbin/pms -u vk2ktj -o vk2ktj
|
|
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 <Literal>vk2ktj</Literal>. You can do all the things connected users can.
|
|
</Para>
|
|
|
|
<Para>
|
|
Additionally you might try getting some other node to connect to you to
|
|
confirm that your <Literal>ax25d.conf</Literal> configuration works.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Configuring the <Emphasis>user_call</Emphasis> programs</Title>
|
|
|
|
<Para>
|
|
The `<Emphasis>user_call</Emphasis>' programs are really called:
|
|
<Emphasis>ax25_call</Emphasis> and
|
|
<Emphasis>netrom_call</Emphasis>. They are very simple programs
|
|
designed to be called from <Emphasis>ax25d</Emphasis> 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 <Emphasis>node</Emphasis> program.
|
|
</Para>
|
|
|
|
<Para>
|
|
They are like a very simple <Emphasis>call</Emphasis> 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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 <Emphasis>ax25_call</Emphasis> program can simplify this if it is called from the
|
|
<Emphasis>ax25d</Emphasis> program.
|
|
</Para>
|
|
|
|
<Para>
|
|
Imagine the BPQ node has the callsign <Literal>VK2KTJ-9</Literal> and that the linux
|
|
machine has the AX.25/ethernet port named `<Literal>bpq</Literal>'. Let us also imagine
|
|
the Linux gateway machine has a radio port called `<Literal>radio</Literal>'.
|
|
</Para>
|
|
|
|
<Para>
|
|
An entry in the <Literal>/etc/ax25/ax25d.conf</Literal> that looked like:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
[VK2KTJ-1 via radio]
|
|
default * * * * * * *
|
|
root /usr/sbin/ax25_call ax25_call bpq %u vk2ktj-9
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
would enable users to connect direct to `<Literal>VK2KTJ-1</Literal>'
|
|
which would actually be the Linux <Emphasis>ax25d</Emphasis> daemon
|
|
and then be automatically switched to an AX.25 connection to
|
|
`<Literal>VK2KTJ-9</Literal>' via the `<Literal>bpq</Literal>'
|
|
interface.
|
|
</Para>
|
|
|
|
<Para>
|
|
There are all sorts of other possible configurations that you might try.
|
|
The `<Emphasis>netrom_call</Emphasis>' and `<Emphasis>rose_call</Emphasis>' 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 <Emphasis>ax25d</Emphasis> proxy
|
|
the connection to the remote machine.
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Configuring the ROSE Uplink and Downlink commands</Title>
|
|
|
|
<Para>
|
|
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 <Literal>VK2KTJ-5</Literal> and
|
|
the AX.25 user wants to connect to <Literal>VK5XXX</Literal> at remote ROSE node
|
|
<Literal>5050882960</Literal> then they would issue the command:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
c vk5xxx v vk2ktj-5 5050 882960
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
At the remote node, <Literal>VK5XXX</Literal> would see an incoming connection with the
|
|
local AX.25 users callsign and being digipeated via the remote ROSE nodes
|
|
callsign.
|
|
</Para>
|
|
|
|
<Para>
|
|
The Linux ROSE implementation does not support this capability in the
|
|
kernel, but there are two application programs called
|
|
<Emphasis>rsuplnk</Emphasis> and <Emphasis>rsdwnlnk</Emphasis> which
|
|
perform this function.
|
|
</Para>
|
|
|
|
<Sect2><Title>Configuring a ROSE downlink</Title>
|
|
|
|
<Para>
|
|
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 <Literal>/etc/ax25/ax25d.conf</Literal>
|
|
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 <Literal>NODE-0</Literal> or <Literal>HEARD-0</Literal> that you wish to handle
|
|
locally, but for all other destination calls you may want to pass them to
|
|
the <Emphasis>rsdwnlink</Emphasis> command and assume they are AX.25 users.
|
|
</Para>
|
|
|
|
<Para>
|
|
A typical configuration would look like:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
#
|
|
{* via rose}
|
|
NOCALL * * * * * * L
|
|
default * * * * * * - root /usr/sbin/rsdwnlnk rsdwnlnk 4800 vk2ktj-5
|
|
#
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
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 <Literal>4800</Literal> with a digipeater path of <Literal>VK2KTJ-5</Literal>.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Configuring a ROSE uplink</Title>
|
|
|
|
<Para>
|
|
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
|
|
<Literal>/etc/ax25/ax25d.conf</Literal> file that looks similar to the following:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
#
|
|
[VK2KTJ-5* via 4800]
|
|
NOCALL * * * * * * L
|
|
default * * * * * * - root /usr/sbin/rsuplnk rsuplnk rose
|
|
#
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
Note the special syntax for the local callsign. The `<Literal>*</Literal>' character
|
|
indicates that the application should be invoked if the callsign is heard in
|
|
the digipeater path of a connection.
|
|
</Para>
|
|
|
|
<Para>
|
|
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
|
|
<Literal>VK2KTJ-5</Literal> on the AX.25 port named
|
|
<Literal>4800</Literal> would be handled by the
|
|
<Emphasis>rsuplnk</Emphasis> command.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Associating AX.25 callsigns with Linux users</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
You make the association with the <Emphasis>axparms</Emphasis> command. An example looks
|
|
like:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# axparms -assoc vk2ktj terry
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
This command associates that AX.25 callsign <Literal>vk2ktj</Literal> with the user
|
|
<Literal>terry</Literal> on the machine. So, for example, any mail for <Literal>vk2ktj</Literal>
|
|
on the <Emphasis>pms</Emphasis> will be sent to Linux account <Literal>terry</Literal>.
|
|
</Para>
|
|
|
|
<Para>
|
|
Remember to put these associations into your <Emphasis>rc</Emphasis> file so that they
|
|
are available each time your reboot.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis>Note</Emphasis> you should never associate a callsign with the <Literal>root</Literal>
|
|
account as this can cause configuration problems in other programs.
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Configuring APRS</Title>
|
|
|
|
<!-- TODO:
|
|
Write this section (assuming it is within the scope of this HOWTO).
|
|
-->
|
|
|
|
<Note>
|
|
<Para>
|
|
This section has yet to be written. It should cover aprsd, aprsdigi,
|
|
aprsmon, xastir, JavAPRS, etc.
|
|
</Para>
|
|
</Note>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>The <Literal>/proc/</Literal> file system entries</Title>
|
|
|
|
<Para>
|
|
The <Literal>/proc</Literal> filesystem contains a number of files specifically
|
|
related to the AX.25 and NET/ROM 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>/proc/net/arp</Term>
|
|
<ListItem>
|
|
<Para>
|
|
contains the list of Address Resolution Protocol
|
|
mappings of IP addresses to MAC layer protocol addresses. These can be AX.25,
|
|
ethernet or some other MAC layer protocol.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>/proc/net/ax25</Term>
|
|
<ListItem>
|
|
<Para>
|
|
contains a list of AX.25 sockets opened. These might
|
|
be listening for a connection, or active sessions.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>/proc/net/ax25_bpqether</Term>
|
|
<ListItem>
|
|
<Para>
|
|
contains the AX.25 over ethernet BPQ
|
|
style callsign mappings.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>/proc/net/ax25_calls</Term>
|
|
<ListItem>
|
|
<Para>
|
|
contains the linux userid to callsign
|
|
mappings set my the <Emphasis>axparms -assoc</Emphasis> command.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>/proc/net/ax25_route</Term>
|
|
<ListItem>
|
|
<Para>
|
|
contains AX.25 digipeater path
|
|
information.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>/proc/net/nr</Term>
|
|
<ListItem>
|
|
<Para>
|
|
contains a list of NET/ROM sockets opened. These might
|
|
be listening for a connection, or active sessions.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>/proc/net/nr_neigh</Term>
|
|
<ListItem>
|
|
<Para>
|
|
contains information about the NET/ROM
|
|
neighbours known to the NET/ROM software.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>/proc/net/nr_nodes</Term>
|
|
<ListItem>
|
|
<Para>
|
|
contains information about the NET/ROM
|
|
nodes known to the NET/ROM software.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>/proc/net/rose</Term>
|
|
<ListItem>
|
|
<Para>
|
|
contains a list of ROSE sockets opened. These might
|
|
be listening for a connection, or active sessions.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>/proc/net/rose_nodes</Term>
|
|
<ListItem>
|
|
<Para>
|
|
contains a mapping of ROSE destinations
|
|
to ROSE neighbours.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>/proc/net/rose_neigh</Term>
|
|
<ListItem>
|
|
<Para>
|
|
contains a list of known ROSE neighbours.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>/proc/net/rose_routes</Term>
|
|
<ListItem>
|
|
<Para>
|
|
contains a list of all established ROSE
|
|
connections.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>AX.25, NET/ROM, ROSE network programming</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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, NET/ROM and ROSE protocols within your software.
|
|
</Para>
|
|
|
|
<Sect2><Title>The address families</Title>
|
|
|
|
<Para>
|
|
Network programming for AX.25, NET/ROM 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The address family names for AX.25, NET/ROM and ROSE are <Literal>AF_AX25</Literal>,
|
|
<Literal>AF_NETROM</Literal> and <Literal>AF_ROSE</Literal> respectively.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>The header files</Title>
|
|
|
|
<Para>
|
|
You must always include the `<Literal>netax25/ax25.h</Literal>' header
|
|
file, and also the `<Literal>netrom/netrom.h</Literal>' or
|
|
`<Literal>netrose/rose.h</Literal>' header files if you are dealing
|
|
with those protocols. Simple top level skeletons would look something
|
|
like the following:
|
|
</Para>
|
|
|
|
<Para>
|
|
For AX.25:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
#include <netax25/ax25.h>
|
|
int s, addrlen = sizeof(struct full_sockaddr_ax25);
|
|
struct full_sockaddr_ax25 sockaddr;
|
|
sockaddr.fsa_ax25.sax25_family = AF_AX25
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
For NET/ROM:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
#include <netax25/ax25.h>
|
|
#include <netrom/netrom.h>
|
|
int s, addrlen = sizeof(struct full_sockaddr_ax25);
|
|
struct full_sockaddr_ax25 sockaddr;
|
|
sockaddr.fsa_ax25.sax25_family = AF_NETROM;
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
For ROSE:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
#include <netax25/ax25.h>
|
|
#include <netrose/rose.h>
|
|
int s, addrlen = sizeof(struct sockaddr_rose);
|
|
struct sockaddr_rose sockaddr;
|
|
sockaddr.srose_family = AF_ROSE;
|
|
</Screen>
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Callsign mangling and examples</Title>
|
|
|
|
<Para>
|
|
There are routines within the <Literal>lib/ax25.a</Literal> library built in the
|
|
AX.25 utilities package that manage the callsign conversions for you. You can
|
|
write your own of course if you wish.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>user_call</Emphasis> utilities are excellent examples from which to
|
|
work. The source code for them is included in the AX.25 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The examples are simple enough to not be very confusing. If you have any
|
|
questions, you should feel to direct them to the <Literal>linux-hams</Literal> mailing
|
|
list and someone there will be sure to help you.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Some sample configurations</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Sect2><Title>Small Ethernet LAN with Linux as a router to Radio LAN</Title>
|
|
|
|
<Para>
|
|
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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
. . . . . .
|
|
___ _________ .
|
|
| 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
|
|
| | | .
|
|
| | | .
|
|
| \_________/ .
|
|
_|_ . . . . . .
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
#!/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 " NET/ROM: "
|
|
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
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
<Literal>/etc/ax25/axports</Literal>
|
|
|
|
<Screen>
|
|
# name callsign speed paclen window description
|
|
4800 VK2KTJ-0 4800 256 2 144.800 MHz
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
<Literal>/etc/ax25/nrports</Literal>
|
|
|
|
<Screen>
|
|
# name callsign alias paclen description
|
|
netrom VK2KTJ-9 LINUX 235 Linux Switch Port
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
<Literal>/etc/ax25/nrbroadcast</Literal>
|
|
|
|
<Screen>
|
|
# ax25_name min_obs def_qual worst_qual verbose
|
|
4800 1 120 10 1
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Note the following:
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
You must have IP_FORWARDING enabled in your kernel.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
The AX.25 configuration files are pretty much those used as examples
|
|
in the earlier sections, refer to those where necessary.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
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
|
|
<Literal>44.136.8.97</Literal> for that port too.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Literal>44.136.8.68</Literal> is my local IPIP encapsulated gateway and hence
|
|
is where I point my default route.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Each of the machines on my Ethernet network have a route:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
route add -net 44.0.0.0 netmask 255.0.0.0 \
|
|
gw 44.136.8.97 window 512 mss 512 eth0
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
The use of the <Emphasis>mss</Emphasis> and <Emphasis>window</Emphasis> parameters means that I can
|
|
get optimum performance from both local Ethernet and radio based connections.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
The router machine is a lowly 386DX20 with a 20Mb hard drive and a very
|
|
minimal linux configuration.
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>IPIP encapsulated gateway configuration</Title>
|
|
|
|
<Para>
|
|
Linux is now very commonly used for TCP/IP encapsulated gateways
|
|
around the world. The 2.2 and 2.4 kernels provide a new method, making
|
|
the old <Literal>ipip</Literal> configuration obsolete. The
|
|
<Literal>ip</Literal> command contained in the IPROUTE2 package is now
|
|
the main tool, as described in the <ULink
|
|
URL="http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html">Linux 2.4
|
|
Advanced Routing HOWTO</ULink>.
|
|
</Para>
|
|
|
|
<Para>
|
|
A typical configuration would look similar to the following:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
__________ _________
|
|
/ \ Internet / \ 44.177.155.0/24
|
|
| | | | ______
|
|
| UCSD | | Linux | / \
|
|
| | | | | |
|
|
| ampr.org | eth1 eth0 | IPIP | | PR |
|
|
| |____________________| |____| Node |
|
|
|44.0.0.0/8| | Gateway | | |
|
|
| |y.y.y.y x.x.x.x| | | |
|
|
| | | | \______/
|
|
| | | |
|
|
\__________/ \_________/
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
The configuration file for this example is the following:
|
|
</Para>
|
|
|
|
<Para>
|
|
<Screen>
|
|
# /etc/rc.d/rc.tunnel
|
|
# This file is a simple configuration that provides the IPIP encapsulation,
|
|
# commonly used when utilising the ampr.org (44.0.0.0/8) routing via UCSD.
|
|
# The script is located on IPIP gateway with eth0 interface, connected directly
|
|
# to the internet and other (e.g. sl0) interface, connected to packet radio
|
|
# subnet, e.g. 44.177.155/24.
|
|
#
|
|
IP_eth0=x.x.x.x
|
|
IP_eth1=y.y.y.y
|
|
echo " Configuring:"
|
|
#
|
|
ip tunnel add ucsd remote $IP_eth1 mode ipip
|
|
# 'ucsd' is (any suitable) tunnel name
|
|
ifconfig ucsd $IP_eth0 up
|
|
# tunnel initialisation
|
|
ip route add 44/8 dev ucsd via $IP_eth1 onlink
|
|
# tells that tunnel should be used when sending packets to ampr.org network
|
|
# onlink is the magic word, do not forget
|
|
echo " done."
|
|
#
|
|
# end.
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
In any case, the tunnel must be set up on both sides of the route.
|
|
The tunnelling interface configured above is used for both
|
|
encapsulation and decapsulation. However, the same principle can be
|
|
used for one of those tasks, exclusively. When needed, the standard
|
|
routing (via UCSD), used in previous example, can be avoided by
|
|
setting the IPIP tunneling between two PR stations, where only one of
|
|
them has its own internet (public) non-ampr IP address. The task is
|
|
then to set up the one-way IPIP tunnel, to achieve a quicker and more
|
|
stable route from non-ampr IP address to ampr IP address station. In
|
|
this case, the setup, mentioned above, is used for encapsulation. The
|
|
other side of the route can leave out the route setting, due to its
|
|
pure decapsulation task.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>AXIP encapsulated gateway configuration</Title>
|
|
|
|
<Para>
|
|
Many Amateur Radio Internet gateways encapsulate AX.25, NET/ROM and ROSE in
|
|
addition to tcp/ip. Encapsulation of AX.25 frames within IP datagrams is
|
|
described in RFC-1226 by Brian Kantor. Mike Westerhof wrote an implementation
|
|
of an AX.25 encapsulation daemon for UNIX in 1991. The ax25-utils package
|
|
includes a marginally enhanced version of it for Linux.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>ax25ipd</Emphasis> 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 <Literal>/etc/ax25/ax25ipd.conf</Literal>.
|
|
</Para>
|
|
|
|
<Sect3><Title>AXIP configuration options</Title>
|
|
|
|
<Para>
|
|
The <Emphasis>ax25ipd</Emphasis> 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
Other options that are configured here are:
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
the tty that the <Emphasis>ax25ipd</Emphasis> daemon will open and its speed (usually
|
|
one end of a pipe)
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
what callsign you want to use in "digipeater" mode
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
beacon interval and text
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
</ListItem>
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>A typical <Literal>/etc/ax25/ax25ipd.conf</Literal> file</Title>
|
|
|
|
<Para>
|
|
<Screen>
|
|
#
|
|
# ax25ipd configuration file for station floyd.vk5xxx.ampr.org
|
|
#
|
|
# Select axip transport. 'ip' is what you want for compatibility
|
|
# with most other gateways.
|
|
#
|
|
socket ip
|
|
#
|
|
# Set ax25ipd mode of operation. (digi or tnc)
|
|
#
|
|
mode tnc
|
|
#
|
|
# If you selected digi, you must define a callsign. If you selected
|
|
# tnc mode, the callsign is currently optional, but this may change
|
|
# in the future! (2 calls if using dual port kiss)
|
|
#
|
|
#mycall vk5xxx-4
|
|
#mycall2 vk5xxx-5
|
|
#
|
|
# In digi mode, you may use an alias. (2 for dual port)
|
|
#
|
|
#myalias svwdns
|
|
#myalias2 svwdn2
|
|
#
|
|
# Send an ident every 540 seconds ...
|
|
#
|
|
#beacon after 540
|
|
#btext ax25ip -- tncmode rob/vk5xxx -- Experimental AXIP gateway
|
|
#
|
|
# Serial port, or pipe connected to a kissattach in my case
|
|
#
|
|
device /dev/ttyq0
|
|
#
|
|
# Set the device speed
|
|
#
|
|
speed 9600
|
|
#
|
|
# loglevel 0 - no output
|
|
# loglevel 1 - config info only
|
|
# loglevel 2 - major events and errors
|
|
# loglevel 3 - major events, errors, and AX.25 frame trace
|
|
# loglevel 4 - all events
|
|
# log 0 for the moment, syslog not working yet ...
|
|
#
|
|
loglevel 2
|
|
#
|
|
# If we are in digi mode, we might have a real tnc here, so use param to
|
|
# set the tnc parameters ...
|
|
#
|
|
#param 1 20
|
|
#
|
|
# Broadcast Address definition. Any of the addresses listed will be forwarded
|
|
# to any of the routes flagged as broadcast capable routes.
|
|
#
|
|
broadcast QST-0 NODES-0
|
|
#
|
|
# ax.25 route definition, define as many as you need.
|
|
# format is route (call/wildcard) (ip host at destination)
|
|
# ssid of 0 routes all ssid's
|
|
#
|
|
# route <destcall> <destaddr> [flags]
|
|
#
|
|
# Valid flags are:
|
|
# b - allow broadcasts to be transmitted via this route
|
|
# d - this route is the default route
|
|
#
|
|
route vk2sut-0 44.136.8.68 b
|
|
route vk5xxx 44.136.188.221 b
|
|
route vk2abc 44.1.1.1
|
|
#
|
|
#
|
|
</Screen>
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Running <Emphasis>ax25ipd</Emphasis></Title>
|
|
|
|
<Para>
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>Create your <Literal>/etc/ax25/axports</Literal> entry:</Term>
|
|
<ListItem>
|
|
<Para>
|
|
|
|
<Screen>
|
|
# /etc/ax25/axports
|
|
#
|
|
axip VK2KTJ-13 9600 256 AXIP port
|
|
#
|
|
</Screen>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>Run the <Emphasis>kissattach</Emphasis> command to create that port:</Term>
|
|
<ListItem>
|
|
<Para>
|
|
|
|
<Screen>
|
|
/usr/sbin/kissattach /dev/ptyq0 axip 44.135.96.242
|
|
</Screen>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>Run the <Emphasis>ax25ipd</Emphasis> program:</Term>
|
|
<ListItem>
|
|
<Para>
|
|
|
|
<Screen>
|
|
/usr/sbin/ax25ipd &
|
|
</Screen>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>Test the AXIP link:</Term>
|
|
<ListItem>
|
|
<Para>
|
|
|
|
<Screen>
|
|
call axip vk5xxx
|
|
</Screen>
|
|
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3><Title>Some notes about the routes and route flags</Title>
|
|
|
|
<Para>
|
|
The "<Literal>route</Literal>" command is where you specify where you want your AX.25
|
|
packets encapsulated and sent to. When the <Emphasis>ax25ipd</Emphasis> daemon receives
|
|
a packet from its interface, it compares the destination callsign with each
|
|
of the callsigns in its routing table. If it 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
There are two flags you can add to any of the route commands in the
|
|
<Literal>ax25ipd.conf</Literal> file. The two flags are:
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>b</Term>
|
|
<ListItem>
|
|
<Para>
|
|
traffic with a destination address matching any of those on
|
|
the list defined by the "<Literal>broadcast</Literal>" keyword should be transmitted via
|
|
this route.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>d</Term>
|
|
<ListItem>
|
|
<Para>
|
|
any packets not matching any route should be transmitted via
|
|
this route.
|
|
</Para>
|
|
</ListItem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Linking NOS and Linux using a pipe device</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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 <Emphasis>master</Emphasis>
|
|
end of the pipe, and the open then the second program can open the
|
|
<Emphasis>slave</Emphasis> 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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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 <Literal>/dev</Literal> directory. The master end of the pipes are
|
|
named: <Literal>ptyq[1-f]</Literal> and the slave end of the pipes are known as:
|
|
<Literal>ttyq[1-f]</Literal>. Remember they come in pairs, so if you select
|
|
<Literal>/dev/ptyqf</Literal> as your master end then you must use <Literal>/dev/ttyqf</Literal>
|
|
as the slave end.
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
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:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
# /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
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
In this example the Linux kernel has been given IP address <Literal>44.70.4.88</Literal>
|
|
and the NOS program is using IP address <Literal>44.70.248.67</Literal>. The
|
|
<Emphasis>route</Emphasis> command in the last line simply tells your linux kernel to route
|
|
all datagrams for the amprnet via the slip link created by the
|
|
<Emphasis>slattach</Emphasis> command. Normally you would put these commands into your
|
|
<Literal>/etc/rc.d/rc.inet2</Literal> 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 <Emphasis>cslip</Emphasis> instead of <Emphasis>slip</Emphasis>
|
|
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.
|
|
</Para>
|
|
|
|
<Para>
|
|
To configure the NOS end of the link you could try the following:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
# 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
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Summary of AX.25-related Linux commands</Title>
|
|
|
|
<Para>
|
|
This section summarizes all of the commands that are specific to AX.25.
|
|
</Para>
|
|
|
|
<Para>
|
|
<informaltable frame=all>
|
|
<tgroup cols=3>
|
|
<thead>
|
|
<row><entry>Command</entry><entry>Package</entry><entry>Description</entry></row>
|
|
</thead>
|
|
<tbody>
|
|
|
|
<row>
|
|
<entry>mheard</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Display AX.25 calls recently heard</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ax25d</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>General purpose AX.25, NET/ROM and ROSE daemon</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>axctl</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Configure/Kill running AX.25 connections</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>axparms</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Configure AX.25 interfaces</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>axspawn</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Allow automatic login to a Linux system</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>beacon</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Transmit periodic messages on an AX.25 port</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>bpqparms</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Configure BPQ ethernet devices</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>mheardd</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Collect information about packet activity</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>rxecho</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Route AX.25 packets between ports transparently</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>sethdlc</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Get/set Linux HDLC packet radio modem driver port information</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>smmixer</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Get/set Linux soundcard packet radio modem driver mixer</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>smdiag</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Linux soundcard packet radio modem driver diagnostics utility</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>kissattach</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Attach a KISS or 6PACK interface</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>kissnetd</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Create a virtual network</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>kissparms</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Configure KISS TNCs</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>net2kiss</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Convert a network AX.25 driver to a KISS stream on a pseudo-tty</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>mkiss</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Attach a multi KISS interface</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>nodesave</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Saves NET/ROM routing information</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>nrattach</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Start a NET/ROM interface</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>nrparms</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Configure the NET/ROM interface</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>nrsdrv</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>KISS to NET/ROM serial converter</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>netromd</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Send and receive NET/ROM routing messages</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>rsattach</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Start a ROSE interface</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>rsdwnlnk</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>User exit from the ROSE network</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>rsparms</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Configure the ROSE interface</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>rsuplnk</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>User entry into the ROSE network</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ttylinkd</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>TTYlink daemon for AX.25, NET/ROM, ROSE and IP</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>rip98d</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Send and receive RIP98 routing messages</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ax25_call</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Make an AX.25, NET/ROM, ROSE or TCP connection</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>netrom_call</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Make an AX.25, NET/ROM, ROSE or TCP connection</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>rose_call</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Make an AX.25, NET/ROM, ROSE or TCP connection</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>tcp_call</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Make an AX.25, NET/ROM, ROSE or TCP connection</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>yamcfg</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Configure YAM driver parameters</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>dmascc_cfg</entry>
|
|
<entry>ax25-tools</entry>
|
|
<entry>Configure dmascc devices</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ax25ipd</entry>
|
|
<entry>ax25-apps</entry>
|
|
<entry>AX.25 into IP Encapsulator</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ax25rtd</entry>
|
|
<entry>ax25-apps</entry>
|
|
<entry>AX.25 routing daemon</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ax25rtctl</entry>
|
|
<entry>ax25-apps</entry>
|
|
<entry>AX.25 routing daemon control utility</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>call</entry>
|
|
<entry>ax25-apps</entry>
|
|
<entry>Make an AX.25, NET/ROM or ROSE connection</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>listen</entry>
|
|
<entry>ax25-apps</entry>
|
|
<entry>Monitor AX.25 traffic</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ax25mond</entry>
|
|
<entry>ax25-apps</entry>
|
|
<entry>Dump the AX.25 network traffic and provide sockets where the received data will be retransmitted</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>soundmodem</entry>
|
|
<entry>soundmodem</entry>
|
|
<entry>Soundcard modem driver</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>soundmodemconfig</entry>
|
|
<entry>soundmodem</entry>
|
|
<entry>Soundcard modem configuration utility</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>aprsd</entry>
|
|
<entry>aprsd</entry>
|
|
<entry>APRS daemon</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>aprspass</entry>
|
|
<entry>aprsd</entry>
|
|
<entry>APRS passcode generator</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>aprsdigi</entry>
|
|
<entry>aprsdigi</entry>
|
|
<entry>APRS digipeater</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>aprsmon</entry>
|
|
<entry>aprsdigi</entry>
|
|
<entry>Monitor APRS AX.25 traffic for JavAPRS</entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Where do I find more information about .... ?</Title>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Sect2><Title>Packet Radio</Title>
|
|
|
|
<Para>
|
|
You can get general information about Packet Radio from these sites:
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<ULink URL="http://www.arrl.org/">American Radio Relay League</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<ULink URL="http://www.rats.org/">Radio Amateur Teleprinter Society</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<ULink URL="http://www.tapr.org/">Tucson Amateur Packet Radio Group</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Protocol Documentation</Title>
|
|
|
|
<Para>
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
AX.25, NET/ROM - Jonathon Naylor has collated a variety of documents that
|
|
relate to the packet radio protocols themselves. This documentation has been
|
|
packaged up into
|
|
<ULink URL="ftp://ftp.hes.iki.fi/pub/ham/unix.linux/ax25/ax25-doc-1.0.tar.gz" >ax25-doc-1.0.tar.gz</ULink>
|
|
</Para>
|
|
</ListItem>
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Hardware Documentation</Title>
|
|
|
|
<Para>
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Information on the <Emphasis>PI2 Card</Emphasis> is provided by the
|
|
<ULink URL="http://hydra.carleton.ca/">Ottawa Packet Radio Group</ULink>.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Information on <Emphasis>Baycom hardware</Emphasis> is available at the
|
|
<ULink URL="http://www.baycom.de/">Baycom Web Page</ULink>.
|
|
</Para>
|
|
</ListItem>
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2><Title>Linux Ham Radio Software</Title>
|
|
|
|
<Para>
|
|
John Ackermann has a web site with information related to configuring
|
|
AX.25 on Linux at
|
|
<ULink URL="http://www.febo.com/linux-ax25/index.html">
|
|
http://www.febo.com/linux-ax25/index.html</ULink>.
|
|
</Para>
|
|
|
|
<Para>
|
|
The Hamsoft Linux Ham Radio Applications and Utilities Database
|
|
attempts to maintain a complete list of Amateur Radio related
|
|
applications for Linux. It can be found at <ULink
|
|
URL="http://radio.linux.org.au/">http://radio.linux.org.au</ULink>.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Discussion relating to Amateur Radio and Linux</Title>
|
|
|
|
<Para>
|
|
There are various places that discussion relating to Amateur Radio and
|
|
Linux take place. They take place in the
|
|
<Literal>comp.os.linux.*</Literal> newsgroups, they also take place on
|
|
the <Literal>linux-hams</Literal> list on
|
|
<Literal>vger.kernel.org</Literal>. Other places where they are held
|
|
include the <Literal>tcp-group</Literal> mailing list at
|
|
<Literal>ucsd.edu</Literal> (the home of amateur radio TCP/IP
|
|
discussions), and you might also try the
|
|
<Literal>#linpeople</Literal> channel on the
|
|
<Literal>linuxnet</Literal> irc network.
|
|
</Para>
|
|
|
|
<Para>
|
|
To join the Linux <Emphasis>linux-hams</Emphasis> channel on the mail
|
|
list server, send mail to <Literal>majordomo@vger.kernel.org</Literal>
|
|
with the line <Literal>subscribe linux-hams</Literal> in the message
|
|
body. The subject line is ignored.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis>linux-hams</Emphasis> mailing list is archived at:
|
|
<ULink
|
|
URL="http://hes.iki.fi/archive/linux-hams/">http://hes.iki.fi/archive/linux-hams/</ULink>
|
|
and <ULink
|
|
URL="http://web.gnu.walfield.org/mail-archive/linux-hams">http://web.gnu.walfield.org/mail-archive/linux-hams</ULink>.
|
|
Please use the archives when you are first starting, because many
|
|
common questions are answered there.
|
|
</Para>
|
|
|
|
<Para>
|
|
To join the <Literal>tcp-group</Literal> send mail to
|
|
<Literal>listserver@ucsd.edu</Literal> with the line <Literal>subscribe
|
|
tcp-group</Literal> in the body of the text.
|
|
</Para>
|
|
|
|
<Note>
|
|
<Para>
|
|
Please remember that the <Literal>tcp-group</Literal> is primarily for
|
|
discussion of the use of advanced protocols, of which TCP/IP is one,
|
|
in Amateur Radio. <Emphasis>Linux specific questions should not
|
|
ordinarily go there.</Emphasis>
|
|
</Para>
|
|
</Note>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Acknowledgements</Title>
|
|
|
|
<Para>
|
|
Terry Dawson was the original author and maintainer of this HOWTO.
|
|
Jeff Tranter took over as maintainer in 2001 to allow Terry more time
|
|
to concentrate on AX.25 software development.
|
|
</Para>
|
|
|
|
<Para>
|
|
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,
|
|
John Ackermann, Riley Williams, Milan Kalina.
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Feedback</Title>
|
|
|
|
<Para>
|
|
I rely on you, the reader, to make this HOWTO useful. If you have any
|
|
suggestions, corrections, or comments, please send them to me, <ULink
|
|
URL="mailto:tranter@pobox.com">tranter@pobox.com</ULink>, and I will
|
|
try to incorporate them in the next revision.
|
|
</Para>
|
|
|
|
<Para>
|
|
If you publish this document on a CD-ROM or in hardcopy form, a
|
|
complimentary copy would be appreciated; mail me for my postal
|
|
address. Also consider making a donation to the Linux Documentation
|
|
Project to help support free documentation for Linux. Contact the
|
|
LDP at <ULink URL="mailto:feedback@linuxdoc.org">feedback@linuxdoc.org</ULink>
|
|
for more information.
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1><Title>Distribution Policy</Title>
|
|
|
|
<Para>
|
|
Copyright (c) 1996-1997 by Terry Dawson, Copyright (c) 2001 by Jeff
|
|
Tranter. Permission is granted to copy, distribute and/or modify this
|
|
document under the terms of the GNU Free Documentation License,
|
|
Version 1.1 or any later version published by the Free Software
|
|
Foundation; with no Invariant Sections, with no Front-Cover Texts, and
|
|
with no Back-Cover Texts. A copy of the license is available at
|
|
<ULink URL="http://www.gnu.org/copyleft/fdl.html">http://www.gnu.org/copyleft/fdl.html</ULink>
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
</Article>
|