🚀 go-pugleaf

Archive-name: linux/howto/AX25-HOWTO/part1
Last-modified: 29 Mar 97

-----BEGIN PGP SIGNED MESSAGE-----

*** The `Linux AX25 HOWTO' is posted automatically by the
*** Linux HOWTO coordinator, Greg Hankins <gregh@sunsite.unc.edu>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Terry Dawson <terry@perf.no.itg.telecom.com.au>.

- --- BEGIN Linux AX25 HOWTO part 1/2 ---

  Linux AX25-HOWTO, Amateur Radio.
  Terry Dawson, VK2KTJ, terry@perf.no.itg.telecom.com.au
  v1.4, 2 March 1997

  The Linux Operating System is perhaps the only operating system in the
  world that can boast native and standard support for the AX.25 packet
  radio protocol utilised by Amateur Radio Operators worldwide. This
  document aims to describe how to install and configure this support.

  1.  Introduction.

  This document was originally an appendix to the HAM-HOWTO, but grew
  too large to be reasonably managed in that fashion. This document
  describes how to install and configure the native AX.25, NetRom and
  Rose support for Linux. A few typical configurations are described
  that could be used as models to work from.

  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.

  1.1.  Changes from the previous version

  Additions:
          Updated to include module patch.
          Added some general information about kernel structure.
  Corrections/Updates:
          Corrected ax25d configuration - thanks John Tanner, VK2ZXQ
          Shuffled lots of stuff around, should be more logical now.
  ToDo:
          Fix up the SCC section, this is probably wrong.
          Expand on the programming section.
          Add some references to AX.25 and NetRom source documentation.

  1.2.  Other related documentation.

  There is a lot of related documentation. There are many documents that
  relate to Linux networking in more general ways and I strongly
  recommend you also read these as they will assist you in your efforts
  and provide you with stronger insight into other possible
  configurations.

  They are:

  The HAM-HOWTO <http://sunsite.unc.edu/LDP/HOWTO/HAM-HOWTO.html>,

  the Net-2-HOWTO <http://sunsite.unc.edu/LDP/HOWTO/NET-2-HOWTO.html>,

  the Ethernet-HOWTO <http://sunsite.unc.edu/LDP/HOWTO/Ethernet-
  HOWTO.html>,

  and:

  the Firewall-HOWTO <http://sunsite.unc.edu/LDP/HOWTO/Firewall-
  HOWTO.html>
  More general Linux information may be found by reference to other
  Linux HOWTO <http://sunsite.unc.edu/LDP/HOWTO/> documents.

  2.  Where to obtain new versions of this document.

  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 The AX25-HOWTO
  <http://sunsite.unc.edu/LDP/HOWTO/AX25-HOWTO.html>. 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.

  3.  The Packet Radio Protocols and Linux.

  The AX.25 protocol offers both connected and connectionless modes of
  operation, and is used either by itself for point-point links, or to
  carry other protocols such as TCP/IP and NetRom.

  It is similar to X.25 level 2 in structure, with some extensions to
  make it more useful in the amateur radio environment.

  The NetRom protocol is an attempt at a full network protocol and uses
  AX.25 at its lowest layer as a datalink protocol. It provides a
  network layer that is an adapted form of AX.25. The NetRom protocol
  features dynamic routing and node aliases.

  The Rose protocol was conceived and first implemented by Tom Moulton
  W2VY and is an implementation of the X.25 packet layer protocol and is
  designed to operate with AX.25 as its datalink layer protocol. It too
  provides a network layer. Rose addresses take the form of 10 digit
  numbers. The first four digits are called the Data Network
  Identification Code (DNIC) and are taken from Appendix B of the CCITT
  X.121 recommendation. More information on the Rose protocol may be
  ontained from the RATS Web server <http://www.rats.org/>.

  Alan Cox developed some early kernel based AX.25 software support for
  Linux.  Jonathon Naylor <g4klx@g4klx.demon.co.uk> has taken up ongoing
  development of the code, has added NetRom and Rose support and is now
  the developer of the AX.25 related kernel code. DAMA support was
  developed by Joerg, DL1BKE, jreuter@lykos.tng.oche.de. Baycom and
  SoundModem support were added by Thomas Sailer,
  <sailer@ife.ee.ethz.ch>. The AX.25 utility software is now maintained
  by me.

  The Linux code supports KISS based TNC's (Terminal Node Controllers),
  the Ottawa PI card, the Gracilis PacketTwin card and other Z8530 SCC
  based cards with the generic SCC driver and both the Parallel and
  Serial port Baycom modems. Thomas's new soundmodem driver supports
  Soundblaster and soundcards based on the Crystal chipset.

  The User programs contain a simple PMS (Personal Message System), a
  beacon facility, a line mode connect program, `listen' an example of
  how to capture all AX.25 frames at raw interface level and programs to
  configure the NetRom protocol. Included also are an AX.25 server style
  program to handle and despatch incoming AX.25 connections and a NetRom
  daemon which does most of the hard work for NetRom support.

  3.1.  How it all fits together.

  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.

  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.

  Simplified Protocol Layering Diagram

       -----------------------------------------------
       | AF_AX25 | AF_NETROM |  AF_INET    | AF_ROSE |
       |=========|===========|=============|=========|
       |         |           |             |         |
       |         |           |    TCP/IP   |         |
       |         |           ----------    |         |
       |         |   NetRom           |    | Rose    |
       |         -------------------------------------
       |            AX.25                            |
       -----------------------------------------------

  This diagram simply illustrates that NetRom, Rose and TCP/IP all run
  directly on top of AX.25, but that each of these protocols is treated
  as a seperate protocol at the programming interface. The `AF_' names
  are simply the names given to the `Address Family' of each of these
  protocols when writing programs to use them. The important thing to
  note here is the implicit dependence on the configuration of your
  AX.25 devices before you can configure your NetRom, Rose or TCP/IP
  devices.

  Software module diagram on Linux Network Implementation

  ----------------------------------------------------------------------------
   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
  ----------------------------------------------------------------------------

  This diagram is a little more general than the first. This diagram
  attempts to show the relationship between user applications, the ker�
  nel 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 exam�
  ple, if you want to run the call 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 ker�
  nel includes the desired protocol that presents a programming inter�
  face that the call program can use. I have attempted to lay out this
  document in roughly that order.

  4.  The AX.25/NetRom software components.

  The AX.25 software is comprised of three components, the kernel
  source, the network configuration tools and the utility programs.

  The version 2.0.xx Linux kernels include the AX.25, NetRom, Z8530 SCC,
  PI card and PacketTwin drivers by default. These have been
  significantly enhanced in the 2.1.* kernels. Unfortunately, the rest
  of the 2.1.*  kernels makes them fairly unstable at the moment and not
  a good choice for a production system. To solve this problem Jonathon
  Naylor has prepared a patch kit which will bring the amateur radio
  protocol support in a 2.0.28 kernel up to the standard of the 2.1.*
  kernels. This is very simple to apply, and provides a range of
  facilities not present in the standard kernel such as Rose support.

  4.1.  Finding the kernel, tools and utility packages.

  4.1.1.  The kernel source:

  The kernel source can be found in its usual place at:

  ftp.funet.fi

       /pub/Linux/PEOPLE/Linus/v2.0/linux-2.0.29.tar.gz

  The current version of Jonathons upgrade patch is available at:

  ftp.cs.nott.ac.uk

       /jsn/ax25-module-12.tar.gz

  4.1.2.  The network tools:

  The latest alpha release of the standard Linux network tools support
  AX.25 and NetRom and can be found at:

  ftp.inka.de

       /pub/comp/Linux/networking/net-tools/net-tools-1.32-alpha.tar.gz

  or:

  ftp.linux.org.uk

  /pub/linux/Networking/PROGRAMS/base/net-tools-1.32-alpha.tar.gz

  The latest ipfwadm package can be found at:

  ftp.xos.nl

       /pub/linux/ipfwadm/

  4.1.3.  The AX25 utilities:

  There are two different strains of AX25-utilities. One is for the
  2.0.* kernels and the other will work with either the 2.1.* kernels or
  the 2.0.28+module10 kernel. The ax25-utils version number indicate the
  oldest version of kernel that they will work with. Please choose a
  version of the ax25-utils appropriate to your kernel.

  The AX.25 utility programs for 2.1.22 or later, or 2.0.28+module can
  be found at Jonathon Naylors home site:

  ftp.cs.nott.ac.uk

       /jsn/ax25-utils-2.1.22b.tar.gz

  or at:

  sunsite.unc.edu

       /pub/Linux/apps/ham/ax25-utils-2.1.22b.tar.gz

  The older tools, capable of working with the unpatched 2.0.29 kernel
  are called ax25-utils-2.0.12c.tar.gz at the same sites.

  5.  Installing the AX.25/NetRom software.

  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.

  5.1.  Compiling the kernel.

  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.

  The normal place for the kernel source to be unpacked to is the
  /usr/src directory into a subdirectory called linux.  To do this you
  should be logged in as root and execute a series of commands similar
  to the following:

       # mv linux linux.old
       # cd /usr/src
       # tar xvfz linux-2.0.29.tar.gz
       # tar xvfz /pub/net/ax25/ax25-module-12.tar.gz
       # patch -p0 </usr/src/ax25-module-12/ax25-2.0.29-2.1.22.diff
       # cd linux

  After you have unpacked the kernel source and applied the upgrade, you
  need to run the configuration script and choose the options that suit
  your hardware configuration and the options that you wish built into
  your kernel.  You do this by using the command:

       # make config

  You might also try:

       # make menuconfig

  if you prefer a full screen menu based method. I'm going to describe
  the original method, but you use whichever you are most comfortable
  with.

  In either case you will be offered a range of options at which you
  must answer `Y' or `N'. (Note you may also answer `M' if you are using
  modules.  For the sake of simplicity I will assume you are not, please
  make appropriate modifications if you are).

  The options most relevant to an AX.25 configuration are:

  Code maturity level options  --->
      ...
      [*] Prompt for development and/or incomplete code/drivers
      ...
  General setup  --->
      ...
      [*] Networking support
      ...
  Networking options  --->
      ...
      [*] TCP/IP networking
      [?] IP: forwarding/gatewaying
      ...
      [?] IP: tunneling
      ...
      [?] IP: Allow large windows (not recommended if <16Mb of memory)
      ...
      [*] Amateur Radio AX.25 Level 2
      [?] Amateur Radio NET/ROM
      [?] Amateur Radio X.25 PLP (Rose)
      ...
  Network device support  --->
      [*] Network device support
      ...
      [*] Radio network interfaces
      [?] BAYCOM ser12 and par96 driver for AX.25
      [?] Soundcard modem driver for AX.25
      [?] Soundmodem support for Soundblaster and compatible cards
      [?] Soundmodem support for WSS and Crystal cards
      [?] Soundmodem support for 1200 baud AFSK modulation
      [?] Soundmodem support for 4800 baud HAPN-1 modulation
      [?] Soundmodem support for 9600 baud FSK G3RUH modulation
      [?] Serial port KISS driver for AX.25
      [?] BPQ Ethernet driver for AX.25
      [?] Gracilis PackeTwin support for AX.25
      [?] Ottawa PI and PI/2 support for AX.25
      [?] Z8530 SCC KISS emulation driver for AX.25
      ...

  The options I have flagged with a `*' are those that you must must
  answer `Y' to. The rest are dependent on what hardware you have and
  what other options you want to include. Some of these options are
  described in more detail later on, so if you don't know what you want
  yet, then read ahead and come back to this step later.

  After you have completed the kernel configuration you should be able
  to cleanly compile your new kernel:

       # make dep
       # make clean
       # make zImage

  Make sure you move your arch/i386/boot/zImage file wherever you want
  it and then edit your /etc/lilo.conf file and rerun lilo to ensure
  that you actually boot from it.

  5.1.1.  What's new in 2.0.*+ModuleXX or 2.1.* Kernels ?

  The 2.1.* kernels have enhanced versions of nearly all of the
  protocols and drivers. The most significant of the enhancements are:

     modularised
        the protocols and drivers have all been modularised so that you
        can insmod and rmmod them whenever you wish. This reduces the
        kernel memory requirements for infrequently used modules and
        makes development and bug hunting much simpler.

     all drivers are now network drivers
        all of the network devices such as Baycom, SCC, PI, Packettwin
        etc now present a normal network interface, that is they now
        look like the ethernet driver does, they no longer look like
        KISS TNC's. A new utility called net2kiss allows you to build a
        kiss interface to these devices if you wish.

     bug fixed
        there have been many bug fixes and new features added to the
        drivers and protocols.

  5.2.  The network configuration tools.

  Now that you have compiled the kernel you should compile the new
  network configuration tools. These tools allow you to modify the
  configuration of network devices and to add routes to the routing
  table.

  The new alpha release of the standard net-tools package includes
  support for AX.25 and NetRom support. I've tested this and it seems to
  work well for me.

  5.2.1.  Building the standard net-tools release.

  Don't forget to read the Release file and follow any instructions
  there. The steps I used to compile the tools were:

       # cd /usr/src
       # tar xvfz net-tools-1.32-alpha.tar.gz
       # cd net-tools-1.32-alpha
       # make config

  At this stage you will be presented with a series of configuration
  questions, similar to the kernel configuration questions. Be sure to
  include support for all of the protocols and network devices types
  that you intend to use. If you do not know how to answer a particular
  question then answer `Y'.

  The tools should compile cleanly against the kernel source without
  error.

  When the compilation is complete, you should need only use the:

       # make install

  command to install the programs in their proper place.

  If you wish to use the IP firewall facilities then you will need the
  latest firewall administration tool ipfwadm. This tool replaces the
  older ipfw tool which will not work with new kernels.

  I compiled the ipfwadm utility with the following commands:

       # cd /usr/src
       # tar xvfz ipfwadm-2.0beta2.tar.gz
       # cd ipfwadm-2.0beta2
       # make install
       # cp ipfwadm.8 /usr/man/man8
       # cp ipfw.4 /usr/man/man4

  5.3.  The AX.25 user programs.

  After you have successfully compiled and booted your new kernel, you
  need to compile the user programs. To compile and install the user
  programs you should use a series of commands similar to the following:

       # cd /usr/src
       # tax xvfz ax25-utils-2.1.22b.tar.gz
       # cd ax25-utils-2.1.22b
       # make config
       # make
       # make install

  The files will be installed under the /usr directory by default in
  subdirectories: bin, sbin, etc and man.

  If you get messages something like:

  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.)

  then you should double check that you have the ncurses package
  properly installed on your system. The configuration script attempts
  to locate your ncurses packages in the common locations, but some
  installations have ncurses badly installed and it is unable to locate
  them.

  6.  A note on callsigns, addresses and things before we start.

  Each AX.25 and NetRom port on your system must have a callsign/ssid
  allocated to it. These are configured in the configuration files that
  will be described in detail later on.
  Some AX.25 implementations such as NOS and BPQ will allow you to
  configure the same callsign/ssid on each AX.25 and NetRom port. For
  somewhat complicated technical reasons Linux does not allow this. This
  isn't as big a problem in practise as it might seem.

  This means that there are things you should be aware of and take into
  consideration when doing your configurations.

  1. Each AX.25 and NetRom port must be configured with a unique
     callsign/ssid.

  2. 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.

  3. NetRom will use the callsign/ssid specified for it in its
     configuration file, but this callsign is only used when your NetRom
     is speaking to another NetRom, this is not the callsign/ssid that
     AX.25 users who wish to use your NetRom `node' will use. More on
     this later.

  4. Rose will, by default, use the callsign/ssid of the AX.25 port,
     unless the Rose callsign has been specifically set using the
     `rsparms' command.  If you set a callsign/ssid using the `rsparms'
     command then Rose will use this callsign/ssid on all ports.

  5. Other programs, such as the `ax25d' program can listen using any
     callsign/ssid that they wish and these may be duplicated across
     different ports.

  6. If you are careful with routing you can configure the same IP
     address on all ports if you wish.

  6.1.  What are all those T1, T2, N2 and things ?

  Just as not every ham is an engineer, 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.

  -------------------------------------------------------------------
  Linux  | TAPR TNC | Description
  -------------------------------------------------------------------
  T1     | FRACK    | How long to wait before retransmitting an
         |          | unacknowledged frame.
  -------------------------------------------------------------------
  T2     | RESPTIME | The minimum amount of time to wait for another
         |          | frame to be received before transmitting
         |          | an acknowledgement.
  -------------------------------------------------------------------
  T3     | CHECK    | The period of time we wait between sending
         |          | a check that the link is still active.
  -------------------------------------------------------------------
  N2     | RETRY    | How many times to retransmit a frame before
         |          | assuming the connection has failed.
  -------------------------------------------------------------------
  Idle   |          | The period of time a connection can be idle
         |          | before we close it down.
  -------------------------------------------------------------------
  Window | MAXFRAME | The maximum number of unacknowledged
         |          | transmitted frames.
  -------------------------------------------------------------------

  6.2.  Run time configurable parameters

  The 2.1.* and 2.0.29+module kernels have a new feature that allows you
  to change many previously unchangable parameters at run time. If you
  take a careful look at the /proc/sys/net/ directory structure you will
  see many files with useful names that describe various parameters for
  the network configuration. The files in the /proc/sys/net/ax25/
  directory each represents one configured AX.25 port. The name of the
  file relates to the name of the port. The structure of the files is as
  follows:

  No.     Name                    Meaning                         Default
  1       IP Default Mode         0=DG 1=VC                       0
  2       AX.25 Default Mode      0=Normal 1=Extended             0
  3       Allow Vanilla Connects  0=No 1=Yes                      1
  4       Backoff                 0=Linear 1=Exponential          1
  5       Connected Mode          0=No 1=Yes                      1
  6       Standard Window         1  <= N <= 7                    2
  7       Extended Window         1  <= N <= 63                   32
  8       T1 Timeout              1s <= N <= 30s                  10s
  9       T2 Timeout              1s <= N <= 20s                  3s
  10      T3 Timeout              0s <= N <= 3600s                300s
  11      Idle Timeout            0m <= N                         20m
  12      N2                      1  <= N <= 31                   10
  13      AX.25 Frame Length      1  <= N <= 512                  256
  14      Max Queue               1  <= N <= 20                   2
  15      Digipeater Mode         0=None 1=Inband 2=XBand 3=Both  3

  In the table T1, T2 and T3 are given in seconds, and the Idle Timeout
  is given in minutes. But please note that the values used in the
  sysctl interface are given in internal units where the time in seconds
  is multiplied by 10, this allows resolution down to 1/10 of a second.
  With timers that are allowed to be zero, eg T3 and Idle, a zero value
  indicates that the timer is disabled.

  7.  Configuring an AX.25 port.

  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
  /etc/ax25/axport file.  You must have an entry in this file for each
  AX.25 port you want on your system.

  7.1.  Creating the /etc/ax25/axports file.

  The /etc/ax25/axports is a simple text file that you create with a
  text editor. The format of the /etc/ax25/axports file is as follows:

       portname  callsign  baudrate  paclen  window  description

  where:

     portname
        is a text name that you will refer to the port by.

     callsign
        is the AX.25 callsign you want to assign to the port.

     baudrate
        is the speed at which you wish the port to communicate with your
        TNC.

     paclen
        is the maximum packet length you want to configure the port to
        use for AX.25 connected mode connections.

     window
        is the AX.25 window (K) parameter. This is the same as the
        MAXFRAME setting of many tnc's.

     description
        is a textual description of the port.

  In my case, mine looks like:

       radio    VK2KTJ-15       4800        256     2       4800bps 144.800 MHz
       ether    VK2KTJ-14       10000000    256     2       BPQ/ethernet device

  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.

  This file will be used by programs described later.

  7.2.  Creating the AX.25 network device.

  The network device is what is listed when you use the `ifconfig'
  command. This is the object that the Linux kernel sends and receives
  network data from. Nearly always the network device has a physical
  port associated with it, but there are occasions where this isn't
  necessary. The network device does relate directly to a device driver.

  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.

  Each of these device drivers will create a network device when it is
  started.

  7.2.1.  Creating a KISS device.

  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 minicom or seyon to configure the TNC into kiss mode.

  To create a KISS device you use the kissattach program. In it simplest
  form you can use the kissattach program as follows:

       # /usr/sbin/kissattach /dev/ttyS0 radio
       # kissparms -p radio -t 100 -s 100 -r 25

  The kissattach command will create a KISS network device. These
  devices are called `ax[0-9]'. The first time you use the kissattach
  command it creates `ax0', the second time it creates `ax1' etc. Each
  KISS device has an associated serial port.

  The kissparms command allows you to set various KISS parameters on a
  KISS device.

  Specifically the example presented would create a KISS network device
  using the serial device `/dev/ttyS0' and the entry from the
  /etc/ax25/axports with a port name of `radio'. It then configures it
  with a txdelay and slottime of 100 milliseconds and a ppersist value
  of 25.

  Please refer to the man pages for more information.

  7.2.1.1.  Configuring for Dual Port TNC's

  The mkiss utility included in the ax25-utils distribution allows you
  to make use of both modems on a dual port TNC. Configuration is fairly
  simple. It works by taking a single serial device connected to a
  single multiport TNC and making it look like a number of devices each
  connected to a single port TNC. You do this before you do any of the
  AX.25 configuration. The devices that you then do the AX.25
  configuration on are pseudo-TTY interfaces, (/dev/ttyp*), 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 `/dev/ptyp*' and the
  slave ends are called `/dev/ttyp*'. There is a one to one relationship
  between masters and slaves, so /dev/ptyp0 is the master end of a pipe
  with /dev/ttyp0 as its slave. You must open the master end of a pipe
  before opening the slave end. mkiss exploits this mechanism to split a
  single serial device into seperate devices.

  Example: if you have a dual port tnc and it is connected to your
  /dev/ttyS0 serial device at 9600 bps, the command:

       # /usr/sbin/mkiss -s 9600 /dev/ttyS0 /dev/ptyp0 /dev/ptyp1
       # /usr/sbin/kissattach /dev/ttyp0 port1
       # /usr/sbin/kissattach /dev/ttyp1 port2

  would create two pseudo-tty devices that each look like a normal
  single port TNC. You would then treat /dev/ttyp0 and /dev/ttyp1 just
  as you would a conventional serial device with TNC connected. This
  means you'd then use the kissattach command as described above, on
  each of those, in the example for AX.25 ports called port1 and port2.
  You shouldn't use kissattach on the actual serial device as the mkiss
  program uses it.

  The mkiss command has a number of optional arguments that you may wish
  to use. They are summarised as follows:

     -c enables the addition of a one byte checksum to each KISS frame.
        This is not supported by most KISS implementation, it is
        supported by the G8BPG KISS rom.

     -s <speed>
        sets the speed of the serial port.

     -h enables hardware handshaking on the serial port, it is off by
        default. Most KISS implementation do not support this, but some
        do.

     -l enables logging of information to the syslog logfile.

  7.2.2.  Creating a Baycom device.

  Thomas Sailer, <sailer@ife.ee.ethz.ch>, despite the popularly held
  belief that it would not work very well, has developed Linux support
  for Baycom modems. His driver supports the Ser12 serial port, Par96
  and the enhanced PicPar parallel port modems.  Further information
  about the modems themselves may be obtained from the Baycom Web site
  <http://www.baycom.de/>.

  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.

  The sethdlc utility allows you to configure the driver with these
  parameters, or, if you have only one Baycom modem installed you may
  specify the parameters on the insmod commmand line when you load the
  Baycom module.

  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:

  # setserial /dev/ttyS0 uart none
  # insmod baycom mode="ser12*" iobase=0x3f8 irq=4

  Par96 parallel port type modem on LPT1: using hardware DCD detection:

       # insmod baycom mode="par96" iobase=0x378 irq=7 options=0

  This is not really the preferred way to do it. The sethdlc utility
  works just as easily with one device as with many.

  The sethdlc man page has the full details, but a couple of examples
  will illustrate the most important aspects of this configuration. The
  following examples assume you have already loaded the baycom module
  using:

       # insmod baycom

  Configure the bc0 device driver as a Parallel port Baycom modem on
  LPT1: with software DCD:

       # sethdlc -p -i bc0 mode par96 io 0x378 irq 7

  Configure the bc1 device driver as a Serial port Baycom modem on COM1:

       # sethdlc -p -i bc1 mode "ser12*" io 0x3f8 irq 4

  7.2.3.  Configuring the AX.25 channel access parameters.

  The AX.25 channel access parameters are the equivalent of the KISS
  ppersist, txdelay and slottime type parameters. Again you use the
  sethdlc utility for this.

  Again the sethdlc man page is the source of the most complete
  information but another example of two won't hurt:

  Configure the bc0 device with TxDelay of 200 mS, SlotTime of 100 mS,
  PPersist of 40 and half duplex:

       # sethdlc -i bc0 -a txd 20 slot 10 ppersist 40 half

  Note that the timing values are in 10's of milliseconds.

  7.2.4.  Creating a SoundModem device.

  Thomas Sailer has built a new driver for the kernel that allows you to
  use your soundcard as a modem. Connect your radio directly to your
  soundcard to play packet! Thomas recommends at least a 486DX2/66 if
  you want to use this software as all of the digital signal processing
  is done by the main CPU.

  The driver currently emulates 1200 bps AFSK, 4800 HAPN and 9600 FSK
  (G3RUH compatible) modem types. The only sound cards currently
  supported are SoundBlaster and WindowsSoundSystem Compatible models.
  The sound cards require some circuitry to help them drive the Push-To-
  Talk circuitry, and information on this is available from Thomas's
  SoundModem PTT circuit web page
  <http://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html>. 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.

  The SoundModem driver creates network devices called: sm0, sm1, sm2
  etc when it is configured.

  Note: 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.

  7.2.4.1.  Configuring the sound card.

  The SoundModem driver does not initialise the sound card. The
  ax25-utils package includes a utility to do this called `setcrystal'
  that may be used for SoundCards based on the Crystal chipset. If you
  have some other card then you will have to use some other software to
  initialise it.  Its syntax is fairly straightforward:

       setcrystal [-w wssio] [-s sbio] [-f synthio] [-i irq] [-d dma] [-c dma2]

  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:

       # setcrystal -s 0x388 -i 10 -d 1

  To configure a WindowSoundSystem card at i/o base address 0x534, irq
  5, DMA 3 you would use:

       # setcrystal -w 0x534 -i 5 -d 3

  The [-f synthio] parameter is the set the synthesiser address, and the
  [-c dma2] parameter is to set the second DMA channel to allow full
  duplex operation.

  7.2.4.2.  Configuring the SoundModem driver.

  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.

  The sethdlc utility allows you to configure the driver with these
  parameters, or, if you have only one soundcard installed you may
  specify the parameters on the insmod commmand line when you load the
  SoundModem module.

  For example, a simple configuration, with one SoundBlaster soundcard
  configured as described above emulating a 1200 bps modem:

       # insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1

  This is not really the preferred way to do it. The sethdlc utility
  works just as easily with one device as with many.

  The sethdlc man page has the full details, but a couple of examples
  will illustrate the most important aspects of this configuration. The
  following examples assume you have already loaded the SoundModem
  modules using:

       # insmod soundmodem

  Configure the driver to support the WindowsSoundSystem card we
  configured above to emulate a G3RUH 9600 compatible modem as device
  sm0 using a parallel port at 0x378 to key the Push-To-Talk:

       # sethdlc -p -i sm0 mode wss:fsk9600 io 0x534 irq 5 dma 3 pario 0x378
       # ifconfig sm0 up

  Configure the driver to support the SoundBlaster card we configured
  above to emulate a 4800 bps HAPN modem as device sm1 using the serial
  port located at 0x2f8 to key the Push-To-Talk:

       # sethdlc -p -i sm1 mode sbc:hapn4800 io 0x388 irq 10 dma 1 serio 0x2f8
       # ifconfig sm1 up

  Configure the driver to support the SoundBlaster card we configured
  above to emulate a 1200 bps AFSK modem as device sm1 using the serial
  port located at 0x2f8 to key the Push-To-Talk:

       # sethdlc -p -i sm1 mode sbc:afsk1200 io 0x388 irq 10 dma 1 serio 0x2f8
       # ifconfig sm1 up

  7.2.4.3.  Configuring the AX.25 channel access parameters.

  The AX.25 channel access parameters are the equivalent of the KISS
  ppersist, txdelay and slottime type parameters. You use the sethdlc
  utility for this as well.

  Again the sethdlc man page is the source of the most complete
  information but another example of two won't hurt:

  Configure the sm0 device with TxDelay of 100 mS, SlotTime of 50mS,
  PPersist of 128 and full duplex:

       # sethdlc -i sm0 -a txd 10 slot 5 ppersist 128 full

  Note that the timing values are in 10's of milliseconds.

  7.2.4.4.  Setting the audio levels and tuning the driver.

  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 smdiag and smmixer.

     smdiag
        provides two types of display, either an oscilloscope type
        display or an eye pattern type display.

     smmixer
        allows you to actually adjust the transmit and receive audio
        levels.

  To start the smdiag utility in 'eye' mode for the SoundModem device
  sm0 you would use:

       # smdiag -i sm0 -e

  To start the smmixer utility for the SoundModem device sm0 you would
  use:

       # smmixer -i sm0

  7.2.4.5.  Configuring the Kernel AX.25 to use the SoundModem

  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.

  The first step is to configure the device with an AX.25 callsign. The
  ifconfig utility is used to perform this.

  # /sbin/ifconfig sm0 hw ax25 VK2KTJ-15 up

  will assign the SoundModem device sm0 the AX.25 callsign VK2KTJ-4.

  The next step is to create an entry in the /etc/ax25/axports file as
  you would for any other device. The entry in the axports file is
  associated with the network device you've configured by the callsign
  you configure. The entry in the axports file that has the callsign
  that you configured the SoundModem device with is the one that will be
  used to refer to it.

  You may then treat the new AX.25 device as you would any other,
  configure it for TCP/IP, add it to ax25d and run NetRom or Rose over
  it as you please.

  7.2.5.  Creating a PI card device.

  The PI card device driver creates devices named `pi[0-9][ab]'. The
  first PI card detected will be allocated `pi0', the second `pi1' etc.
  The `a' and `b' refer to the first and second physical interface on
  the PI card. If you have built your kernel to include the PI card
  driver, and the card has been properly detected then you can use the
  following command to configure the network device:

       # /sbin/ifconfig pi0a hw ax25 VK2KTJ-15 up

  This command would configure the first port on the first PI card
  detected with the callsign VK2KTJ-15 and make it active. Note the
  callsign should match the entry in the /etc/ax25/axports file that you
  wish to use for this port.

  The PI card driver was written by David Perry, <dp@hydra.carleton.edu>

  7.2.6.  Creating a PacketTwin device.

  The PacketTwin card device driver creates devices named `pt[0-9][ab]'.
  The first PacketTwin card detected will be allocated `pt0', the second
  `pt1' etc. The `a' and `b' refer to the first and second physical
  interface on the PacketTwin card. If you have built your kernel to
  include the PacketTwin card driver, and the card has been properly
  detected then you can use the following command to configure the
  network device:

       # /sbin/ifconfig pt0a hw ax25 VK2KTJ-15 up

  This command would configure the first port on the first PacketTwin
  card detected with the callsign VK2KTJ-15 and make it active. Note the
  callsign should match the entry in the /etc/ax25/axports file that you
  wish to use for this port.

  The PacketTwin card driver was written by Craig Small VK2XLZ,
  <csmall@triode.apana.org.au>.

  7.2.7.  Creating a generic SCC device.

  Joerg Reuter, DL1BKE, jreuter@lykos.tng.oche.de 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.

  7.2.7.1.  Obtaining and building the configuration tool package.

  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.

  You can obtain the configuration tools package from:

  db0bm.automation.fh-aachen.de

       /incoming/dl1bke/

  or:

  insl1.etec.uni-karlsruhe.de

       /pub/hamradio/linux/z8530/

  or:

  ftp.ucsd.edu

       /hamradio/packet/tcpip/linux
       /hamradio/packet/tcpip/incoming/

  You will find multiple versions, choose the one that best suits the
  kernel you intend to use:

  z8530drv-2.4a.dl1bke.tar.gz   2.0.*
  z8530drv-utils-3.0.tar.gz    2.1.6 or greater

  The following command were what I used to compile and install the
  package for kernel version 2.0.25:

  # 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

  After the above is complete you should have three new programs
  installed in your /sbin directory: gencfg, sccinit and sccstat. It is
  these programs that you will use to configure the driver for your
  card.

  You will also have a group of new special device files created in your
  /dev called scc0 .. scc7. These will be used later and will be the
  `KISS' devices you will end up using.

  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 `Y' to: `Z8530 SCC kiss emulation driver for
  AX.25' when asked during a kernel `make config'.

  If you chose to 'make module' then the new scc.o will have been
  installed in the appropriate /lib/modules directory and you do not
  need to recompile your kernel. Remember to use the insmod command to
  load the module before your try and configure it.

  7.2.7.2.  Configuring the driver for your card.

  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.

  There is more comprehensive documentation in the package and you
  should read this if you have any problems. You should particularly
  look at doc/scc_eng.doc or doc/scc_ger.doc 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.

  The main configuration file is read by the sccinit program and is
  called /etc/z8530drv.conf. 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:

       # sccinit

  into the rc file that configures your network and the driver will be
  initialised according to the contents of the configuration file. You
  must do this before you attempt to use the driver.

  7.2.7.2.1.  Configuration of the hardware parameters.

  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 #define
  MAXSCC 4 in scc.c can be increased if you require support for more.

  The allowable keywords and arguments are:

     chip
        the chip keyword is used to separate stanzas. It will take
        anything as an argument. The arguments are not used.

     data_a
        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

     ctrl_a
        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

     data_b
        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

     ctrl_b
        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

     irq
        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

     pclock
        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.

     board
        the type of board supporting this 8530 SCC. The argument is a
        character string. The allowed values are:

        PA0HZP
           the PA0HZP SCC Card

        EAGLE
           the Eagle card

        PC100
           the DRSI PC100 SCC card

        PRIMUS
           the PRIMUS-PC (DG9BL) card

        BAYCOM
           BayCom (U)SCC card

     escc
        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'.

     vector
        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.

     special
        this keyword is optional and specifies the address of the
        special function register on several cards. The default is 0.

     option
        this keyword is optional and defaults to 0.

  Some example configurations for the more popular cards are as follows:

     BayCom USCC

          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

     PA0HZP SCC card

          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

     DRSI SCC card

          chip 1
          data_a 0x303
          data_b 0x301
          ctrl_a 0x302
          ctrl_b 0x300
          irq 7
          pclock 4915200
          board DRSI
          escc no

  If you already have a working configuration for your card under NOS,
  then you can use the gencfg command to convert the PE1CHL NOS driver
  commands into a form suitable for use in the z8530 driver
  configuration file.

  To use gencfg you simply invoke it with the same parameters as you
  used for the PE1CHL driver in NET/NOS. For example:

       # gencfg 2 0x150 4 2 0 1 0x168 9 4915200

  will generate a skeleton configuration for the OptoSCC card.

  7.2.7.3.  Channel Configuration

  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.

  These keywords and arguments are also written to the
  /etc/z8530drv.conf file and must appear after the hardware parameters
  section.

  Sequence is very important in this section, but if you stick with the
  suggested sequence it should work ok. The keywords and arguments are:

     device
        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. /dev/scc0

     speed
        this keyword specifies the speed in bits per second of the
        interface. The argument is an integer: e.g. 1200

     clock
        this keyword specifies where the clock for the data will be
        sourced. Allowable values are:

        dpll
           normal halfduplex operation

        external
           MODEM supplies its own Rx/Tx clock
        divider
           use fullduplex divider if installed.

     mode
        this keyword specifies the data coding to be used. Allowable
        arguments are: nrzi or nrz

     rxbuffers
        this keyword specifies the number of receive buffers to allocate
        memory for. The argument is an integer, e.g. 8.

     txbuffers
        this keyword specifies the number of transmit buffers to
        allocate memory for. The argument is an integer, e.g. 8.

     bufsize
        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 384

     txdelay
        the KISS transmit delay value, the argument is an integer in mS.

     persist
        the KISS persist value, the argument is an integer.

     slot
        the KISS slot time value, the argument is an integer in mS.

     tail
        the KISS transmit tail value, the argument is an integer in mS.

     fulldup
        the KISS full duplex flag, the argument is an integer.  1==Full
        Duplex, 0==Half Duplex.

     wait
        the KISS wait value, the argument is an integer in mS.

     min
        the KISS min value, the argument is an integer in S.

     maxkey
        the KISS maximum keyup time, the argument is an integer in S.

     idle
        the KISS idle timer value, the argument is an integer in S.

     maxdef
        the KISS maxdef value, the argument is an integer.

     group
        the KISS group value, the argument is an integer.

     txoff
        the KISS txoff value, the argument is an integer in mS.

     softdcd
        the KISS softdcd value, the argument is an integer.

     slip
        the KISS slip flag, the argument is an integer.

  7.2.7.4.  Using the driver.

  To use the driver you simply treat the /dev/scc* 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:

       # kissattach -s 4800 /dev/scc0 VK2KTJ

  You can also use NOS to attach to it in precisely the same way. From
  JNOS for example you would use something like:

       attach asy scc0 0 ax25 scc0 256 256 4800

  7.2.7.5.  The sccstat and sccparam tools.

  To assist in the diagnosis of problems you can use the sccstat program
  to display the current configuration of an SCC device. To use it try:

       # sccstat /dev/scc0

  you will displayed a very large amount of information relating to the
  configuration and health of the /dev/scc0 SCC port.

  The sccparam command allows you to change or modify a configuration
  after you have booted. Its syntax is very similar to the NOS param
  command, so to set the txtail setting of a device to 100mS you would
  use:

       # sccparam /dev/scc0 txtail 0x8

  7.2.8.  Creating a BPQ ethernet device.

  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.

  The BPQ network devices are named `bpq[0-9]'. The `bpq0' device is
  associated with the `eth0' device, the `bpq1' device with the `eth1'
  device etc.

  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 Ethernet-HOWTO <Ethernet-HOWTO.html> for more
  information on how to do this.

  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:

       # /sbin/ifconfig bpq0 hw ax25 vk2ktj-14 up

  Again, remember that the callsign you specify should match the entry
  in the /etc/ax25/axports file that you wish to use for this port.

  7.2.9.  Configuring the BPQ Node to talk to the Linux AX.25 support.

  BPQ Ethernet normally uses a multicast address. The Linux
  implementation does not, and instead it uses the normal Ethernet
  broadcast address. The NET.CFG file for the BPQ ODI driver should
  therefore be modifified to look similar to this:

       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

  7.3.  Configuring AX.25 interface operational paramaters.

  The AX.25 utilities packages includes a utility called axctl to enable
  you to configure the various parameters of an AX.25 interface.

  This command is quite straight forward to use and the man page will
  provide you with a complete description, but an example of its use
  might be:

       # /usr/sbin/axctl radio -window 2 -t1 5 -n2 10

  This command would set the Window, T1 and N2 parameters for the AX.25
  port named `radio'.
  7.4.  Configuring AX.25 routing.

  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 axparms command enables you to do this. Again,
  the man page offers a complete description, but a simple example might
  be:

       # /usr/sbin/axparms -route add radio VK2XLZ VK2SUT

  This command would set a digipeater entry for VK2XLZ via VK2SUT on the
  AX.25 port named radio.

  8.  Configuring an AX.25 interface for TCP/IP.

  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 kissattach command has an option that allows you to do
  specify an IP address. The more conventional method using the ifconfig
  command will work on all interface types.

  So, modifying the previous KISS example:

       # /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

  to create the AX.25 interface with an IP address of 44.136.8.5 and an
  MTU of 512 bytes. You should still use the ifconfig to configure the
  other parameters if necessary.

  If you have any other interface type then you use the ifconfig 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:

       # /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

  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.

  To test it out, try a ping or a telnet to a local host.

  # ping -i 5 44.136.8.58

  Note the use of the `-i 5' arguments to ping to tell it to send pings
  every 5 seconds instead of its default of 1 second.

  9.  Configuring a NetRom port.

  The NetRom protocol relies on, and uses the AX.25 ports you have
  created.  The NetRom protocol rides on top of the AX.25 protocol. To
  configure NetRom on an AX.25 interface you must configure two files.
  One file describes the Netrom interfaces, and the other file describes
  which of the AX.25 ports will carry NetRom.

  9.1.  Configuring /etc/ax25/nrports

  The first is the /etc/ax25/nrports file. This file describes the
  NetRom ports in much the same way as the /etc/ax25/axports file
  describes the AX.25 ports. Each NetRom device you wish to create must
  have an entry in the /etc/ax25/nrports file. Normally a Linux machine
  would have only one NetRom device configured that would use a number
  of the AX.25 ports defined. In some situations you might wish a
  special service such as a BBS to have a seperate NetRom alias and so
  you would create more than one.

  This file is formatted as follows:

       name callsign  alias  paclen   description

- --- END Linux AX25 HOWTO part 1/2 ---

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gregh@cc.gatech.edu for public key

iQCVAwUBM0Mb2HtNTo2suu5NAQE99QP+ODbK7g5VDfv8HLmYrge7Kk8vRtRU+NRo
qZzixv9FVhLFBSbF4hiicRWVzVQxbt27FS0RWzhtgIdKl2C2uWaIiOvvXHfrr+yv
/RnN7ANkTTQfC31+la20UJKAM5K7uG6exzOHSphZxueniUUYn07jlR73WYbGlLCG
2PI5OhrsIdQ=
=QMbB
-----END PGP SIGNATURE-----