🚀 go-pugleaf

Archive-name: linux/howto/AX25-HOWTO/part2
Last-modified: 2 Jan 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 2/2 ---

  If you wanted to define rules for another interface, a NetRom
  interface for example, then you would add another paragraph coded in
  the same way with rules and callsign appropriate to it.

  This example is a contrived one but I think it illustrates clearly the
  important features of the syntax of the configuration file. Jonathon
  includes a much longer and more detailed example in the ax25-utils
  package that you should look at if you need more information.

  14.3.  Some ax25d configuration hints.

  Here are some simple hints for you to consider while configuring ax25d
  on your machine:

     Split your services up
        You have 10 SSID's, make use of them. If you have configured
        your ax25 port for tcp/ip then it will use the callsign you
        assigned in your axattach command. It is best to avoid mixing
        tcp/ip, NetRom and plain AX.25 connections on the same SSID.
        Split them up and you will avoid problems later.

     Use the defaults feature
        Choosing sensible defaults can simplify your configurations
        immensely. If you choose sensible defaults you will only need to
        add exceptions to the default as things change over time.

  14.4.  Starting ax25d

  When you have the two configuration files completed you start ax25d
  with the command:

       # /usr/sbin/ax25d

  When this is run people should be able to make AX.25 connections to
  your Linux machine. Remember to put the ax25d command in your rc files
  so that it is started automatically when you reboot each time.

  14.5.  Configuring the node software.

  The node software was developed by Tomi Manninen
  <tomi.manninen@hut.fi> and was based on the original PMS program.  It
  provides a fairly complete and flexible node capability that is easily
  configured. It allows users once they are connected to make telnet,
  netrom or telnet connections out and to obtain various sorts of
  information such as Finger, Nodes and Heard lists etc.

  The node would normally be invoked from the ax25d program although it
  is also capable of being invoked from the tcp/ip inetd program to
  allow users to telnet to your machine and obtain access to it, or by
  running it from the command line.

  14.5.1.  Creating the /etc/ax25/node.conf file.

  The node.conf file is where the main configuration of the node takes
  place. It is a simple text file and its format is as follows:

       # /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     70cm 2m

       # Callserver
       # If configured the node provides users with access to a callserver.
       callserver      zone.oh7rba.ampr.org

       # 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 commands simple.
       alias           CONV    "telnet vk1xwt.ampr.org 3600"
       alias           BBS     "connect radio vk2xsb"

  14.5.2.  Creating the /etc/ax25/node.perms file.

  The node 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 node.perms 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.

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

     method
        Each protocol or access method is also given permissions. For
        example you might allow users who have connected via AX.25 or
        NetRom to use the (C)onnect option, but prevent others, such as
        those who are telnet connected from a non-local node from having
        access to it. The second field therefore allows you to select
        which access method this permissions rule should apply to.  The
        access methods allowed are:

          method  description
          ------  -----------------------------------------------------------
          ax25    User connected by AX.25
          netrom  User connected by NetRom
          host    User started node from command line
          local   User is telnet connected from a 'local' host
          ampr    User is telnet connected from an amprnet address (44.0.0.0)
          inet    user is telnet connected from a non-loca, non-ampr address.

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

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

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

     value   description
     -----   -------------------------------------------------
      1      Login allowed.
      2      AX25 (C)onnects allowed.
      4      NetRom (C)onnects allowed.
      8      (T)elnet to local hosts allowed.
      16     (T)elnet to amprnet (44.0.0.0) hosts allowed.
      32     (T)elnet to non-local, non-amprnet hosts allowed.
      64     Hidden ports allowed for AX.25 (C)onnects.

     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.

  A sample nodes.perms might look like:

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

       # The following users are banned from connecting
       NOCALL  *       *       *       0
       PK232   *       *       *       0
       PMS     *       *       *       0

       # INET users are banned from connecting.
       *       inet    *       *       0

       # AX.25, NetRom, Local, Host and AMPR users may (C)onnect and (T)elnet
       # to local and ampr hosts but not to other IP addresses.
       *       ax25    *       *       31
       *       netrom  *       *       31
       *       local   *       *       31
       *       host    *       *       31
       *       ampr    *       *       31

  14.5.3.  Configuring node to run from ax25d

  The node program would normally be run by the ax25d program.  To do
  this you need to add appropriate rules to the /etc/ax25/ax25d.conf
  file. In my configuration I wanted users to have a choice of either
  connecting to the node or connecting to other services. ax25d allows
  you to do this by cleverly creating creating port aliases. For
  example, given the ax25d configuration presented above, I want to
  configure node so that all users who connect to VK2KTJ-1 are given the
  node. To do this I add the following to my /etc/ax25/ax25d.conf file:

       [VK2KTJ-1 VIA VK2KTJ-0]
       default         * *    *   *   *   0    root /usr/sbin/node node radio

  This simply says that all users who connect to VK2KTJ-1 on the same
  device (by the same port) as VK2KTJ-0 should cause the node program to
  be run with the name of the port they have connected via, in this case
  you will recall the /etc/ax25/axports specifies the port name as radio
  that supports the callsign VK2KTJ-0.

  14.5.4.  Configuring node to run from inetd

  If you want users to be able to telnet a port on your machine and
  obtain access to the node 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 node in his
  documentation.

  You need to modify two files.

  To /etc/services you should add:

       node    4000/tcp        #OH2BNS's node software

  and to /etc/inetd.conf you should add:

       node    stream  tcp     nowait  root    /usr/sbin/node node

  When this is done, and you have restarted the inetd program any user
  who telnet connects to port 4000 of your machine will be prompted to
  login and if configured, their password and then they will be con�
  nected to the node.

  14.6.  Configuring axspawn.

  The axspawn program is a simple program that allows AX.25 stations who
  connect to be logged in to your machine. It is invoked from the ax25d
  program as described above. To allow a user to log in to your machine
  you should add a line similar to the following into your
  /etc/ax25/ax25d.conf file:

       default * * * * * 1 root /usr/sbin/axspawn axspawn %u

  If the line ends in the + 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 axspawn program run when they connect. When axspawn is run it
  first checks that the command line argument it is supplied is a legal
  callsign, strips the SSID, then it checks that /etc/passwd file to see
  if that user has an account configured. If there is an account, and
  the password is either "" (null) or + 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 /etc/passwd
  file then axspawn may be configured to automatically create one.

  14.6.1.  Creating the /etc/ax25/axspawn.conf file.

  You can alter the behaviour of axspawn in various ways by use of the
  /etc/ax25/axspawn.conf file. This file is formatted as follows:

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

  The eight configurable characteristics of axspawn are as follows:

     #  indicates a comment.

     create
        if this field is set to yes then axspawn will attempt to
        automatically create a user account for any user who connects
        and does not already have an entry in the /etc/passwd file.

     guest
        this field names the login name of the account that will be used
        for people who connect who do not already have accounts if
        create is set to no. This is usually ax25 or guest.

     group
        this field names the group name that will be used for any users
        who connect and do not already have an entry in the /etc/passwd
        file.

     first_uid
        this is the number of the first userid that will be
        automatically created for new users.

     max_uid
        this is the maximum number that will be used for the userid of
        new users.

     home
        this is the home (login) directory of new users.

     shell
        this is the login shell of any new users.

     associate
        this flag indicates whether outgoing AX.25 connections made by
        this user after they login will use their own callsign, or your
        stations callsign.

  14.7.  Configuring the pms

  The pms program is an implementation of a simple personal message
  system. It was originally written by Alan Cox. Dave Brown, N2RJT,
  <dcb@vectorbd.com> 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.

  Configuring the pms program is still a little clumsy at the moment
  because it is new but bare with it while Dave works on it. The only
  difficult part is modifying the source code to support your local mail
  delivery agent and whether you use the ttylinkd program or the talk-
  ax25 program.

  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 ax25d.conf file so that
  connected users are presented with the PMS.

  14.7.1.  Customising pms.c

  If you take a look at the pms.c file in the ax25-utils package you
  will see that there a few items that you can configure.  Perhaps the
  most important to configure is the one that allows you to specify what
  local mail delivery agent you use. In most installations the deliver
  program may well work, but in the minimal installation on my gateway
  machine I needed to modify the line that previously said:

  #define MAIL_DELIVERY_AGENT     "deliver %s"

  to:

  #define MAIL_DELIVERY_AGENT     "/bin/mail.local %s"

  There is no easy way of knowing what local delivery agent your machine
  is configured to use, so perhaps you could simply look for either of
  these files in the obvious places and choose whichever seems to be
  there.

  I also have the ttylinkd program installed, so I needed to modify the
  section relating to it. I keep my copy of the ttylinkd program in my
  /usr/sbin directory, so I modified the line that previously said:

  /* #define MY_TALK              "/usr/local/bin/ttylinkd" */

  to:

  #define MY_TALK              "/usr/sbin/ttylinkd"

  If you use the talk-ax25 program then you would remove the /* and */
  from around that line instead.

  There is one last definition that might be useful to you, and that is
  if you have a default email gateway. This line is the line containing
  the string MY_GATEWAY. If you have an email gateway that you use, then
  you should remove the comments from this line and change the address
  to that of your gateway.

  14.7.2.  Create the /etc/ax25/pms.motd file.

  The /etc/ax25/pms.motd 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.

  14.7.3.  Create the /etc/ax25/pms.info file.

  The /etc/ax25/pms.info 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 Info command from the PMS> prompt.

  14.7.4.  Associate AX.25 callsigns with system users.

  When a connected user sends mail to an AX.25 callsign, the pms 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.

  14.7.5.  Add the PMS to the /etc/ax25/ax25d.conf file.

  Adding the pms to your ax25d.conf file is very simple.  There is one
  small thing you need to think about though. Dave has added command
  line arguments to the PMS to allow it to handle a number of different
  text end-of-line conventions. AX.25 and NetRom by convention expect
  the end-of-line to be carriage return, linefeed while the standard
  unix end-of-line is just newline. 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:

       default  1  10 5 100 5   0    root  /usr/sbin/pms pms -a -o vk2ktj

  This simply runs the pms program, telling it that it is an AX.25
  connection it is connected to and that the PMS owner is vk2ktj.  Check
  the man page for what you should specify for other connection methods.

  14.7.6.  Test the PMS.

  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 vk2ktj. You can do all the things connected users
  can.

  Additionally you might try getting some other node to connect to you
  to confirm that your ax25d.conf configuration works.

  14.8.  Configuring the user_call programs.

  The `user_call' programs are really called: ax25_call and netrom_call.
  They are very simple programs designed to be called from ax25d to
  automate network connections to remote hosts. They may of course be
  called from a number of other places such as shell scripts or other
  daemons such as the node program.

  They are like a very simple call program. They don't do any meddling
  with the data at all, so the end of line handling you'll have to worry
  about yourself.

  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.

  15.  Associating AX.25 callsigns with Linux users.

  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.

  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.

  You make the association with the axparms command. An example looks
  like:

       # axparms -assoc vk2ktj terry

  This command associates that AX.25 callsign vk2ktj with the user terry
  on the machine. So, for example, any mail for vk2ktj on the pms will
  be sent to Linux account terry.

  Remember to put these associations into your rc file so that they are
  available each time your reboot.

  Note you should never associate a callsign with the root account as
  this can cause configuration problems in other programs.

  16.  HOWTO link NOS and the Linux kernel networking software

  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. 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 ax25_call program can
  simplify this if it is called from the ax25d program.

  Imagine the BPQ node has the callsign VK2KTJ-9 and that the linux
  machine has the AX.25/ethernet port named `bpq'. Let us also imagine
  the Linux gateway machine has a radio port called `radio'.

  An entry in the /etc/ax25/ax25d.conf that looked like:

       [VK2KTJ-1 via radio]
       parameters 1   5  2   900 900 15  0
       default    *   *   *   *   *   *   *  root ax25_call bpq vk2ktj-9

  would enable users to connect direct to `VK2KTJ-1' which would actu�
  ally be the Linux ax25d daemon and then be automatically switch to an
  AX.25 connection to `VK2KTJ-9' via the `bpq' interface.

  There are all sorts of other possible configurations that you might
  try.  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 ax25d proxy the connection to the remote machine.

  16.1.  Linking NOS and Linux using a pipe device

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

  Since both Linux and NOS support the slip protocol it is possible to
  link the two together by creating a slip link. You could do this by
  using two serial ports with a loopback cable between them, but this
  would be slow and costly. Linux provides a feature that many other
  Unix-like operating systems provide called `pipes'. These are special
  pseudo devices that look like a standard tty device to software but in
  fact loopback to another pipe device. To use these pipes the first
  program must open the master end of the pipe, and the open then the
  second program can open the slave end of the pipe. When both ends are
  open the programs can communicate with each other simply by writing
  characters to the pipes in the way they would if they were terminal
  devices.

  To use this feature to connect the Linux Kernel and a copy of NOS, or
  some other program you first must choose a pipe device to use. You can
  find one by looking in your /dev directory. The master end of the
  pipes are named: ptyp[1-f] and the slave end of the pipes are known
  as: ttyp[1-f]. Remember they come in pairs, so if you select
  /dev/ptypf as your master end then you must use /dev/ttypf as the
  slave end.

  Once you have chosen a pipe device pair to use you should allocate the
  master end to you linux kernel and the slave end to the NOS program,
  as the Linux kernel starts first and the master end of the pipe must
  be opened first.  You must also remember that your Linux kernel must
  have a different IP address to your NOS, so you will need to allocate
  a unique address for it if you haven't already.
  You configure the pipe just as if it were a serial device, so to
  create the slip link from your linux kernel you can use commands
  similar to the following:

       # /sbin/slattach -s 38400 -p slip /dev/ptypf &
       # /sbin/ifconfig sl0 broadcast 44.255.255.255 pointopoint 44.70.248.67 /
               mtu 1536 44.70.4.88
       # /sbin/route add 44.70.248.67 sl0
       # /sbin/route add -net 44.0.0.0 netmask 255.0.0.0 gw 44.70.248.67

  In this example the Linux kernel has been given IP address 44.70.4.88
  and the NOS program is using IP address 44.70.248.67. The route
  command in the last line simply tells your linux kernel to route all
  datagrams for the amprnet via the slip link created by the slattach
  command. Normally you would put these commands into your
  /etc/rc.d/rc.inet2 file after all your other network configuration is
  complete so that the slip link is created automatically when you
  reboot.  Note: there is no advantage in using cslip instead of slip as
  it actually reduces performance because the link is only a virtual one
  and occurs fast enough that having to compress the headers first takes
  longer than transmitting the uncompressed datagram.

  To configure the NOS end of the link you could try the following:

       # you can call the interface anything you want; I use "linux" for convenience.
       attach asy ttypf - slip linux 1024 1024 38400
       route addprivate 44.70.4.88 linux

  These commands will create a slip port named `linux' via the slave end
  of the pipe device pair to your linux kernel, and a route to it to
  make it work. When you have started NOS you should be able to ping and
  telnet to your NOS from your Linux machine and vice versa. If not,
  double check that you have made no mistakes especially that you have
  the addresses configured properly and have the pipe devices around the
  right way.

  17.  The /proc/ file system entries.

  The /proc filesystem contains a number of files specifically related
  to the AX25 and NetRom kernel software. These files are normally used
  by the AX52 utilities, but they are plainly formatted so you may be
  interested in reading them. The format is fairly easily understood so
  I don't think much explanation will be necessary.

     arp
        contains the list of Address Resolution Protocol mappings of IP
        addresses to MAC layer protocol addresses. These can can AX.25,
        ethernet or some other MAC layer protocol.

     ax25
        contains the AX.25 port configuration information.

     ax25%lowbar;bpqether
        contains the AX25 over ethernet BPQ style callsign mappings.
     ax25_calls
        contains the linux userid to callsign mappings set my the
        axparms -assoc command.

     ax25_route
        contains AX.25 digipeater path information.

     nr contains the NetRom port configuration information.

     nr_neigh
        contains information about the  NetRom neighbours known to the
        NetRom software.

     nr_nodes
        contains information about the NetRom nodes known to the NetRom
        software.

  18.  Walking on the wilder side .. the developmental software

  If all of the above doesn't satisfy your desire to push the limits
  there is plenty more for you to play with.

  There have a been a number of enhancements that are available as
  experimental software for you to try. They come either as patches
  against the 2.0.*  kernels, or in the alpha 2.1.* kernels.

  Be warned though, this software is new, pretty much untested and
  likely to contain bugs. If that worries you, then ignore this section
  of the document.

  18.1.  Enhanced versions of just about everything.

  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.

  To take advantage of the features of the 2.1.* AX.25 support you must
  use the new ax25-utils package. You shouldn't use a kernel older than
  2.1.17 and you should use ax25-utils-2.1.17.tar.gz which is available
  from the sites listed in "The AX25 Utilities" section above.

  18.2.  ROSE Packet Layer Support

  The Rose packet layer protocol is similar to layer three of the X.25
  specification. The kernel based Rose support is a modified version of
  the FPAC Rose implementation
  <http://fpac.lmi.ecp.fr/f1oat/f1oat.html>.

  18.2.1.  Configuring /etc/ax25/rsports

  The file where you configure your Rose interfaces is the
  /etc/ax25/rsports file. This file describes the Rose port in much the
  same way as the /etc/ax25/axports file describes the AX.25 ports.

  This file is formatted as follows:

       name  addresss  description

  Where:

     name
        is the text name that you wish to refer to the port by.

     address
        is the 10 digit Rose address you wish to assign to this port.

     description
        is a free text description of the port.

  An example would look something like the following:

       rose  5050924760  Rose Port

  Note that the ports are referred to by name by programs such as call.

  18.2.2.  Creating the Rose device

  When you have created the /etc/ax25/rsports 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 rsattach command:

       # rsattach rose

  This command would start the Rose device (rose0) named rose configured
  with the details specified in the /etc/ax25/rsports file.

  18.2.3.  Configuring Rose Routing

  The Rose protocol currently supports only static routing. The rsparms
  utility allows you to configure your Rose routing table under Linux.

  For example:

  # rsparms -nodes add 5050295502 radio vk2xlz

  would add a route to Rose node 5050295502 via an AX.25 port named
  `radio' in your /etc/ax25/axports file to a neighbour with the call�
  sign VK2XLZ.

  Kernels 2.1.17 and later support variable length Rose masks, so that
  you you may specify a route that looks like:

       # rsparms -nodes add 5050295502/4 radio vk2xlz

  which would be identical to the previous example except that it would
  match any destination address that matched the first four digits sup�
  plied, in this case any address commencing with the digits 5050. An
  alternate form for this command is:

       # rsparms -nodes add 5050/4 radio vk2xlz

  which is probably the less ambiguous form.

  18.2.4.  Testing the Rose interface.

  You now should be able to make outgoing Rose connections. To test Rose
  connections you can use the call program as demonstrated:

       /usr/bin/call rose VK2DAY 5050928860

  to connect to VK2DAY at Rose node 5050928860.

  The call program is a linemode terminal program for making Rose calls.
  It recognises lines that start with `~' as command lines.  The `~.'
  command will close the connection.

  Please refer to the man page in /usr/man for more information.

  18.2.5.  Configuring ax25d to accept incoming Rose connections

  The ax25d daemon included in the ax25-utils-2.1.* packages supports
  accepting incoming Rose connections. The procedure is virtually
  identical to configuration for AX.25, or NetRom with the major
  difference being that the port label has taken on a slightly modified
  syntax. An example Rose configuration would look something like:

  #
  # Format for ROSE:
  # {Callsign VIA ROSE port}
  #
  {* VIA rose}
  parameters 7   100 10  *   *   5  0
  #
  default    *   *   *   *   *   *  *  root /usr/sbin/pms -b -u %u -o vk2ktj

  The `* VIA rose'  says: `Accept connections to any callsign via the
  rose device named `rose' in the /etc/ax25/rsports file.  If the entry
  looked like:

       {VK2KTJ-9 VIA rose}
        ...
        ...

  then only connections to VK2KTJ-9 received via the port named `rose'
  would match.

  18.3.  Enhanced Baycom modem driver.

  In kernel 2.1.17 and newer, the setbaycom utility has been replaced by
  the sethdlc utility. Additionally the Baycom driver no longer uses
  device file in the /dev directory, so if you've upgraded you can
  delete the old ones with:

       # rm /dev/bc[0-9]

  18.3.1.  Configuring the Baycom driver.

  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 modem=1 iobase=0x3f8 irq=4 options=1

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

  # insmod baycom modem=2 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 modem ser12 io 0x3f8 irq 4

  18.3.2.  Configuring the AX.25 channel access parameters.

  Configuring the what ? 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 100 mS, SlotTime of 50mS,
  PPersist of 128 and full duplex:

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

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

  18.4.  Soundcard DSP based modem driver.

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

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

  18.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 hw=0 mode=0 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 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

  18.4.3.  Configuring the AX.25 channel access parameters.

  Configuring the what ? 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 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.

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

  18.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
  axparms utility is used to perform this.

       # axparms -setcall sm0 vk2ktj-4

  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.

  18.5.  Run time configurable parameters

  The 2.1.* 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.

  19.  Some sample configurations.

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

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

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

                                            .      .   .    .    . .
    ---                                .
     | Network       /---------\     .    Network
     | 44.136.8.96/29|         |    .     44.136.8/24        \ | /
     |               | Linux   |   .                          \|/
     |               |         |  .                            |
     |          eth0 | Router  |  .  /-----\    /----------\   |
     |---------------|         |-----| TNC |----| Radio    |---/
     |   44.136.8.97 |  and    |  .  \-----/    \----------/
     |               |         | sl0
     |               | Server  | 44.136.8.5
     |               |         |    .
     |               |         |     .
     |               \_________/       .
    ---                                     .      .   .    .    . .

       #!/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: "
       axattach -i 44.136.8.5 -m 512 /dev/ttyS1 4800
       ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.8.255
       route add -host 44.136.8.5 sl0
       route add -net 44.136.8.0 window 1024 sl0

       echo -n "    Netrom: "
       nrattach -i 44.136.8.5 netrom

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

       # end

  /etc/ax25/axports

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

  /etc/ax25/nrports

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

  /etc/ax25/nrbroadcast

       # ax25_name     min_obs def_qual        worst_qual      verbose
       4800            1       120             10              1

  �  You must have IP_FORWARDING enabled in your kernel.

  �  The AX.25 configuration files are pretty much those used as
     examples in the earlier sections, refer to those where necessary.

  �  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 44.136.8.97 for that port too.

  �  44.136.8.68 is my local IPIP encapsulated gateway and hence is
     where I point my default route.

  �  Each of the machines on my Ethernet network have a route:

       route add -net 44.0.0.0 netmask 255.0.0.0 \
               gw 44.136.8.97 window 512 mss 512 eth0

  The use of the mss and window parameters means that I can get optimum
  performance from both local Ethernet and radio based connections.

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

  �  The router machine is a lowly 386DX20 with a 20Mb harddrive and a
     very minimal linux configuration.

  19.2.  IPIP encapsulated gateway configuration.

  Linux is now very commonly used for tcp/ip encapsulated gateways
  around the world. The new tunnel driver supports multiple encapsulated
  routes and makes the older ipip daemon obsolete.

  A typical configuration would look similar to the following.

                                            .      .   .    .    . .
    ---                                .
     | Network       /---------\     .    Network
     | 154.27.3/24   |         |    .     44.136.16/24       \ | /
     |               | Linux   |   .                          \|/
     |               |         |  .                            |
     |          eth0 | IPIP    |  .  /-----\    /----------\   |
  ---|---------------|         |-----| TNC |----| Radio    |---/
     |   154.27.3.20 | Gateway |  .  \-----/    \----------/
     |               |         | sl0
     |               |         | 44.136.16.1
     |               |         |    .
     |               |         |     .
     |               \_________/       .
    ---                                     .      .   .    .    . .

  The configuration files of interest are:

       # /etc/rc.net
       # This file is a simple configuration that provides one KISS AX.25
       # radio port, one Ethernet device, and utilises the kernel tunnel driver
       # to perform the IPIP encapsulation/decapsulation
       #
       echo "/etc/rc.net"
       echo "  Configuring:"
       #
       echo -n "    loopback:"
       /sbin/ifconfig lo 127.0.0.1
       /sbin/route add 127.0.0.1
       echo " done."
       #
       echo -n "    ethernet:"
       /sbin/ifconfig eth0 154.27.3.20 netmask 255.255.255.0 \
                       broadcast 154.27.3.255 up
       /sbin/route add 154.27.3.20 eth0
       /sbin/route add -net 154.27.3.0 netmask 255.255.255.0 eth0
       echo " done."
       #
       echo -n "    AX.25: "
       axattach -i 44.136.16.1 -m 512 /dev/ttyS1 4800
       /sbin/ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.16.255
       /sbin/route add -host 44.136.16.1 sl0
       /sbin/route add -net 44.136.16.0 netmask 255.255.255.0 window 1024 sl0
       #
       echo -n "    tunnel:"
       /sbin/ifconfig tunl0 44.136.16.1 mtu 512 up
       #
       echo done.
       #
       echo -n "Routing ... "
       source /etc/ipip.routes
       echo done.
       #
       # end.

  and:

       # /etc/ipip.routes
       # This file is generated using the munge script
       #
       /sbin/route add -net 44.134.8.0 netmask 255.255.255.0 tunl0 gw 134.43.26.1
       /sbin/route add -net 44.34.9.0 netmask 255.255.255.0 tunl0 gw 174.84.6.17
       /sbin/route add -net 44.13.28.0 netmask 255.255.255.0 tunl0 gw 212.37.126.3
          ...
          ...
          ...

  /etc/ax25/axports

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

  Some points to note here are:

  �  The new tunnel driver uses the gw field in the routing table in
     place of the pointopoint parameter to specify the address of the
     remote IPIP gateway. This is why it now supports multiple routes
     per interface.

  �  You can configure two network devices with the same address.  In
     this example both the sl0 and the tunl0 devices have been
     configured with the IP address of the radio port. This is done so
     that the remote gateway sees the correct address from your gateway
     in encapsulated datagrams sent to it.

  �  The route commands used to specify the encapsulated routes can be
     automatically generated by a modified version of the munge script.
     This is included below. The route commands would then be written to
     a separate file and read in using the bash source /etc/ipip.routes
     command (assuming you called the file with the routing commands
     /etc/ipip.routes) as illustrated. The source file must be in the
     NOS route command format.

  �  Note the use of the window argument on the route command. Setting
     this parameter to an appropriate value improves the performance of
     your radio link.

  The new tunnel-munge script:

  #!/bin/sh
  #
  # From: Ron Atkinson <n8fow@hamgate.cc.wayne.edu>
  #
  #  This script is basically the 'munge' script written by Bdale N3EUA
  #  for the IPIP daemon and is modified by Ron Atkinson N8FOW. It's
  #  purpose is to convert a KA9Q NOS format gateways route file
  #  (usually called 'encap.txt') into a Linux routing table format
  #  for the IP tunnel driver.
  #
  #        Usage: Gateway file on stdin, Linux route format file on stdout.
  #               eg.  tunnel-munge < encap.txt > ampr-routes
  #
  # NOTE: Before you use this script be sure to check or change the
  #       following items:
  #
  #     1) Change the 'Local routes' and 'Misc user routes' sections
  #        to routes that apply to your own area (remove mine please!)
  #     2) On the fgrep line be sure to change the IP address to YOUR
  #        gateway Internet address. Failure to do so will cause serious
  #        routing loops.
  #     3) The default interface name is 'tunl0'. Make sure this is
  #        correct for your system.

  echo "#"
  echo "# IP tunnel route table built by $LOGNAME on `date`"
  echo "# by tunnel-munge script v960307."
  echo "#"
  echo "# Local routes"
  echo "route add -net 44.xxx.xxx.xxx netmask 255.mmm.mmm.mmm dev sl0"
  echo "#"
  echo "# Misc user routes"
  echo "#"
  echo "# remote routes"

  fgrep encap | grep "^route" | grep -v " XXX.XXX.XXX.XXX" | \
  awk '{
          split($3, s, "/")
          split(s[1], n,".")
          if      (n[1] == "")    n[1]="0"
          if      (n[2] == "")    n[2]="0"
          if      (n[3] == "")    n[3]="0"
          if      (n[4] == "")    n[4]="0"
          if      (s[2] == "1")   mask="128.0.0.0"
          else if (s[2] == "2")   mask="192.0.0.0"
          else if (s[2] == "3")   mask="224.0.0.0"
          else if (s[2] == "4")   mask="240.0.0.0"
          else if (s[2] == "5")   mask="248.0.0.0"
          else if (s[2] == "6")   mask="252.0.0.0"
          else if (s[2] == "7")   mask="254.0.0.0"
          else if (s[2] == "8")   mask="255.0.0.0"
          else if (s[2] == "9")   mask="255.128.0.0"
          else if (s[2] == "10")  mask="255.192.0.0"
          else if (s[2] == "11")  mask="255.224.0.0"
          else if (s[2] == "12")  mask="255.240.0.0"
          else if (s[2] == "13")  mask="255.248.0.0"
          else if (s[2] == "14")  mask="255.252.0.0"
          else if (s[2] == "15")  mask="255.254.0.0"
          else if (s[2] == "16")  mask="255.255.0.0"
          else if (s[2] == "17")  mask="255.255.128.0"
          else if (s[2] == "18")  mask="255.255.192.0"
          else if (s[2] == "19")  mask="255.255.224.0"
          else if (s[2] == "20")  mask="255.255.240.0"
          else if (s[2] == "21")  mask="255.255.248.0"
          else if (s[2] == "22")  mask="255.255.252.0"
          else if (s[2] == "23")  mask="255.255.254.0"
          else if (s[2] == "24")  mask="255.255.255.0"
          else if (s[2] == "25")  mask="255.255.255.128"
          else if (s[2] == "26")  mask="255.255.255.192"
          else if (s[2] == "27")  mask="255.255.255.224"
          else if (s[2] == "28")  mask="255.255.255.240"
          else if (s[2] == "29")  mask="255.255.255.248"
          else if (s[2] == "30")  mask="255.255.255.252"
          else if (s[2] == "31")  mask="255.255.255.254"
          else                    mask="255.255.255.255"

  if (mask == "255.255.255.255")
          printf "route add -host %s.%s.%s.%s gw %s dev tunl0\n"\
                  ,n[1],n[2],n[3],n[4],$5
  else
          printf "route add -net %s.%s.%s.%s gw %s netmask %s dev tunl0\n"\
                  ,n[1],n[2],n[3],n[4],$5,mask
   }'

  echo "#"
  echo "# default the rest of amprnet via mirrorshades.ucsd.edu"
  echo "route add -net 44.0.0.0 gw 128.54.16.18 netmask 255.0.0.0 dev tunl0"
  echo "#"
  echo "# the end"

  20.  Discussion relating to Amateur Radio and Linux.

  There are various places that discussion relating to Amateur Radio and
  Linux take place. They take place in the comp.os.linux.* newsgroups,
  they also take place on the HAMS list on vger.rutgers.edu. Other
  places where they are held include the tcp-group mailing list at
  ucsd.edu (the home of amateur radio tcp/ip discussions), and you might
  also try the #linpeople channel on the linuxnet irc network.

  To join the Linux linux-hams channel on the mail list server, send
  mail to:

       Majordomo@vger.rutgers.edu

  with the line:

       subscribe linux-hams

  in the message body. The subject line is ignored.

  The linux-hams mailing list is archived at:

  zone.pspt.fi <http://zone.pspt.fi/archive/linux-hams/> and
  zone.oh7rba.ampr.org <http://zone.oh7rba.ampr.org/archive/linux-
  hams/>.  Please use the archives when you are first starting, because
  many common questions are answered there.

  To join the tcp-group send mail to:

       listserver@ucsd.edu

  with the line:

       subscribe tcp-group

  in the body of the text.

  Note: Please remember that the tcp-group is primarily for discussion
  of the use of advanced protocols, of which tcp/ip is one, in Amateur
  Radio. Linux specific questions should not ordinarily go there.

  21.  Copyright.

  The AX25-HOWTO, information on how to install and configure some of
  the more important packages providing AX25 support for Linux.
  Copyright (c) 1996 Terry Dawson.

  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation; either version 2 of the License, or (at
  your option) any later version.

  This program is distributed in the hope that it will be useful, but
  WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
  General Public License for more details.

  You should have received a copy of the GNU General Public License
  along with this program; if not, write to the:

  Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
  USA.


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

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

iQCVAwUBMxpXe3tNTo2suu5NAQHwGAQAh8OhwXfGvM5PXCBKDiS8zi8Ld7Mxljw2
rhcB/3UjwMJYgzzXD+5ryF1A9JjnaLq2BQgozCFi2qi12DIna6BNhV2Dm92hcdF/
FsYnQsYb35yKa9s2yRPEeEnwLJj8QmLpubtYd3Ev0yK1NtCIno+dJezeU+y26Pv2
1vp7N9snaIw=
=msjQ
-----END PGP SIGNATURE-----