🚀 go-pugleaf

Archive-name: linux/howto/ax25/part1
Last-modified: 4 May 96

-----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.0 25 Apr 1996

  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 and NetRom
  support for Linux. A few typical configurations are described that
  could be used as models to work from.

  1.1.  Changes from the previous version

  Additions:
          everything.
  Corrections/Updates:

  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/mdw/HOWTO/HAM-HOWTO.html>

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

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

  the IPX-HOWTO <http://sunsite.unc.edu/mdw/HOWTO/IPX-HOWTO.html>

  and

  the Firewall-HOWTO <http://sunsite.unc.edu/mdw/HOWTO/Firewall-
  HOWTO.html>

  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/mdw/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.  Linux and the AX.25 and NetRom Packet Radio Protocols.

  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.

  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 support and is now the
  developer of the AX.25 related kernel code and utilities.

  DAMA support was developed by Joerg, DL1BKE.

  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.

  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.

  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 1.3.xx Linux kernels include the AX.25, NetRom, Z8530 SCC,
  PI card and PacketTwin drivers by default. I recommend you obtain and
  use the version 1.3.xx kernel source.

  These are three reasons I'm recommending you use the alpha version
  software even though most everyone else will recommend you don't use
  it:

  �  it makes the process of building and configuring the software a
     whole lot simpler. There are no patches to apply it is a simple
     matter of configuring and compiling a kernel with the appropriate
     options enabled.

  �  it is the most recent software and is most likely to provide the
     most satisfactory results.

  �  like all new software, it needs testing and bug reports. The more
     people that take the software and attempt to use it in their own
     configurations the more likely it will be that bugs are uncovered
     and the easier it will be to get the software debugged. Join the
     team, contribute bug reports and help everybody.

  Be warned though, this software is alpha and may have problem that you
  wouldn't otherwise encounter. Please take all the usual precautions
  and be sure to keep a working kernel as backup when testing new
  kernels. It is wise to test a new kernel by booting from it from
  floppy before actually installing it with lilo, though I haven't
  bothered for about 90 kernels revisions so I'm fairly confident you
  can pretty safely run with alpha kernels.
  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/v1.3/

  4.1.2.  The network tools:

  Not all of the changes to the AX.25 software have made it into all
  related software packages yet. While the kernel now comes standard
  with AX.25 and NetRom support the standard net-tools package doesn't
  yet support NetRom properly. Jonathon Naylor has made a package that
  does support it available until Bernd can put the modifications into
  the standard release.

  If you intend to use the NetRom protocol then the special net-tools
  package that supports NetRom can be found at:

  ftp.ucsd.edu

       /hamradio/packet/tcpip/incoming/net-tools-1.1.95d.tar.gz

  If you don't want to use NetRom then I strongly recommend you stick to
  the latest release of the standard net-tools package which can be
  found at:

  ftp.inka.de

       /pub/comp/Linux/networking/net-tools/

  or:

  ftp.linux.org.uk

       /pub/linux/Networking/PROGRAMS/NetTools/

  The latest ipfwadm package can be found at:

  ftp.xos.nl

       /pub/linux/ipfwadm/

  4.1.3.  The AX25 utilities:

  The AX.25 utility programs can be found at:

  sunsite.unc.edu

       /pub/Linux/apps/ham/ax25-utils-1.3.91a.tar.gz

  or:

  ftp.ucsd.edu

       /hamradio/packet/tcpip/incoming/ax25-utils-1.3.91a.tar.gz

  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
       # gzip -dc linux-1.3.93.tar.gz | tar xvofp -
       # cd linux

  After you have unpacked the kernel source into place 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:

  Networking support (CONFIG_NET) [Y/n/?]                             Y
  Loopback device support (CONFIG_BLK_DEV_LOOP) [N/y/m/?]             Y
  Network firewalls (CONFIG_FIREWALL) [N/y/?]
  TCP/IP networking (CONFIG_INET) [Y/n/?]                             Y
  IP: forwarding/gatewaying (CONFIG_IP_FORWARD) [N/y/?]
  IP: firewalling (CONFIG_IP_FIREWALL) [N/y/?] (NEW)
  IP: tunneling (CONFIG_NET_IPIP) [N/y/m/?] (NEW)
  Amateur Radio AX.25 Level 2 (CONFIG_AX25) [N/y/?]                   Y
  AX.25 over Ethernet (CONFIG_BPQETHER) [N/y/?] (NEW)
  Amateur Radio NET/ROM (CONFIG_NETROM) [N/y/?] (NEW)
  Kernel/User network link driver(ALPHA) (CONFIG_NETLINK) [N/y/?]
  Network device support (CONFIG_NETDEVICES) [Y/n/?]                  Y
  SLIP (serial line) support (CONFIG_SLIP) [N/y/m/?]
  Z8530 SCC kiss emulation driver for AX.25 (CONFIG_SCC) [N/y/m/?]
  Other ISA cards (CONFIG_NET_ISA) [N/y/?]
  Ottawa PI and PI/2 support (CONFIG_PI) [N/y/?] (NEW)
  Gracilis PackeTwin support (CONFIG_PT) [N/y/?] (NEW)
  Standard/generic serial support (CONFIG_SERIAL) [Y/n/?]

  The options I have flagged with a `Y' are those that you must must
  answer `Y' to. The rest are dependent on what hardware you have and
  what 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 run lilo to ensure that you actually boot from it.

  5.2.  The network configuration tools.

  After 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 release of the standard net-tools package includes support for
  AX.25 by the NetRom support isn't yet complete. Jonathon Naylor has
  produced an interim package which you should use if you intend to use
  the NetRom protocol, otherwise stick to the standard release.

  5.2.1.  Building the `Special' net-tools release

  I built Jonathons special release of net-tools with the following
  commands:

       # cd /usr/src
       # tar xvfz net-tools-1.1.95d.tar.gz
       # cd net-tools-1.1.95d

  There are a couple of things you now need to do. Firstly, the ipfw no
  longer works with new kernels, it has been replaced by the ipfwadm
  command described below. Trying to compile it will result in errors so
  you should edit the Makefile and place a `#' character before `ipfw'
  in the line beginning with `PROGS' as illustrated:

       PROGS   = ifconfig hostname arp netstat route slattach rarp plipconfig
               dnsdomainname #ipfw

  Now you can enter:

       # make

  At this stage you will be prompted with a series of simple questions
  to answer. Make sure you answer `Y' to AX.25 and NetRom support and
  also to Ethernet, SLIP and PPP if you need them.

  After answering the questions the software will begin to compile.

  I compiled the tools with the 1.3.93 kernel source online and ran
  across the following error in a number of different files:

       In file included from slip.c:26:
       /usr/include/linux/if_arp.h:119: `MAX_ADDR_LEN' undeclared here (not in a functi
       on)

  I solved this by modifying each of the files listed, in this case
  lib/slip.c, as follows:

  replace:

       #include <linux/if_arp.h>

  with:

       #include <linux/netdevice.h>
       #include <linux/if_arp.h>

  You should make this modification for each of these files, all in the
  lib subdirectory:

       ax25.c ether.c netrom.c slip.c

  and also these files in the top level directory:

       arp.c ifconfig.c rarp.c

  Newer kernels, or newer net-tools may not require this, so it is
  probably wise to try without modifying first.

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

       # make install

  command to install the programs in their proper place.

  5.2.2.  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.3.50-BETA6f.tar.gz
  # cd net-tools-1.3.50-BETA6f
  # make

  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 first question relates to NLS (National
  Language Support). I do not use this, and it will always be safe to
  answer `N' to, but if you require it then include it.

  I compiled the tools with the 1.3.93 kernel source online and ran
  across the following error in a number of different files:

       In file included from slip.c:26:
       /usr/include/linux/if_arp.h:119: `MAX_ADDR_LEN' undeclared here (not in a function)

  I solved this by modifying each of the files listed, in this case
  lib/slip.c, as follows:

  replace:

       #include <linux/if_arp.h>

  with:

       #include <linux/netdevice.h>
       #include <linux/if_arp.h>

  You should make this modification for each of these files, all in the
  lib subdirectory:

       arcnet.c    ax25.c ether.c netrom.c
       netrom_rt.c ppp.c  slip.c  tr.c
       tunnel.c

  and also these files in the top level directory:

       arp.c ifconfig.c rarp.c

  Newer kernels, or newer net-tools may not require this, so it is
  probably wise to try without modifying first.

  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/local
       # gzip -dc ax25-utils-1.3.91a.tar.gz | tar xvvof -
       # cd ax25-utils-1.3.91a
       # make install

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

  6.  Configuring a RAW AX.25 connected mode interface.

  The first stage to configuration of an AX.25 interface is to configure
  it to work as a `vanilla' AX.25 interface with no TCP/IP. There are
  two distinct parts to the configuration, configuring to allow outgoing
  connections and configuring to accepting incoming connections. They
  are described in turn.

  6.1.  Configuring to allow outgoing connections.

  The AX.25 software has been designed to work with a TNC in kiss mode
  or an Ottawa PI2 card/PacketTwin card.

  If you are using a KISS TNC then you will need to create the AX.25
  interface as it will not already exist. Creating an AX.25 port is very
  similar to creating a slip device. You will need to have the TNC
  preconfigured and connected to your serial port. You can use a comms
  program like minicom or seyon to configure the TNC into kiss mode if
  you wish.

  You use the axattach program in much the same way as you would use the
  slattach program (refer to the NET-2-HOWTO for more information on
  slattach and the other network software for Linux). For example:

       # /usr/local/sbin/axattach -s 4800 /dev/ttyS1 VK2KTJ-1 &
       # sleep 2

  would configure your /dev/ttyS1 serial device to be a kiss interface
  at 4800 bps, with the hardware address VK2KTJ-1. The sleep of 2
  seconds is necessary just to give the kernel a little time to do some
  housekeeping that it has to do before you try and change the
  interface.

  If you are using a PI or PacketTwin card then you should use the
  axsetcall command to change the callsign of the appropriate port to
  that which you intend to use. Refer to the PI/PacketTwin section for
  the names of the network devices to use.

  All this step has done is to actually activate the device in the
  kernel, you need to run other programs before you an actually make use
  of the port. The AX.25 ports have a configuration file that can be
  read by any program that wants to find information about an AX.25
  port. This file is called the:

       /usr/local/etc/axports

  file. The format of the file is as follows:

       callsign baudrate window label

  where:

     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.
     window
        is the AX.25 window (K) parameter. This is the same as the
        MAXFRAME setting of many tnc's.

     label
        is a name for the port.

  In my case, mine looks like:

       VK2KTJ-1 4800 1 radio

  Note that this file is line based, that is, the first entry is
  considered to describe `AX25 port 1' and the second line to describe
  `AX25 port 2'.  Some of the application programs need this `port
  number'. At this stage not all of this information is used, it will be
  picked up and used in later developments.

  You now should be able to make outgoing AX.25 connections. To test
  AX.25 connected mode you could use the call program as demonstrated:

       /usr/local/bin/call VK2DAY via VK2SUT

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

  Please refer to the man pages in /usr/local/man and the README file in
  ax25-utils-1.3.91a distribution for more information.

  6.2.  Configuring to accept incoming connections.

  Linux is a powerful operating system and offers a great deal of
  flexibility in how it is configured. With this flexibility comes a
  cost in configuring it to do what you want. When configuring your
  Linux machine to accept incoming AX.25 connections there are a number
  of questions you need to ask yourself.  The most important of which
  is: "What do I want users to see when they connect?". As detailed in
  the software list at the start of this document there are BBS systems
  that are being developed that you might want users to see when they
  connect, alternatively you might want to give users a login prompt so
  that they can make use of a shell account, or you might even have
  written your own program, such as a customised database or a game,
  that you want people to connect to. Whatever you choose, you must tell
  the AX.25 software about this so that it knows what software to run
  when it accepts an incoming AX.25 connection.

  You do this within the /usr/local/etc/ax25d.conf. This file is the
  configuration file for the ax25d AX.25 daemon which handles incoming
  AX.25 connections.

  The file is a little cryptic looking at first, but you'll soon
  discover it is very simple in practice, with a small trap for you to
  be wary of.

  The format of the ax25d.conf file is as follows:

       # This is a comment and is ignored by the ax25d program.
       [<interface_call>]
       <peer1>  window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
       <peer2>  window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
       defaults window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
       <peer3>  window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
       default  window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>

  Where:

     #  at the start of a line marks a comment and is completely ignored
        by the ax25d program.

     <interface_call>
        is the AX.25 callsign of the interface that this particular
        paragraph is for.

     <peer>
        is the callsign of the peer node that this particular
        configuration applies to. If you don't specify an SSID here then
        any SSID will match.

     window
        is the AX.25 Windows parameter (K) or MAXFRAME parameter for
        this configuration.

     T1 is the Frame retransmission (T1) timer in half second units.

     T2 is the amount of time the AX.25 software will wait for another
        incoming frame before preparing a response in 1 second units.

     T3 is the amount of time of inactivity before the AX.25 software
        will disconnect the session in 1 second units.

     N2 is the number of consecutive retransmissions that will occur
        before the connection is closed.

     <mode>
        provides a mechanism for determining certain types of general
        permissions. The modes are enabled or disabled by setting or
        resetting bits in an 8 bit map. You set that map by setting
        <mode> to the sum of the following values:

        1  Setup utmp, and run on a ptty (planned).

        2  UNUSED.

        4  UNUSED.

        8  UNUSED.

        16 UNUSED.

        32 UNUSED.

        64 Disallow digipeated uplinks, only allow direct connections.

        128
           Lockout, Barred, immediate disconnect.
     <uid>
        is the userid that the program to be run to support the
        connection should be run as.

     <cmd>
        is the full pathname of the command to be run, with no arguments
        specified.

     <cmd-name>
        is the text that should appear in a ps as the command name
        running (normally the same as <cmd> except without the directory
        path information.

     <arguments>
        are the command line argument to be passed to the <:cmd> when it
        is run. You pass useful information into these arguments by use
        of the following tokens:

        %U AX.25 callsign of the connected party without the SSID, in
           uppercase.

        %u AX.25 callsign of the connected party without the SSID, in
           lowercase.

        %S AX.25 callsign of the connected party with the SSID, in
           uppercase.

        %s AX.25 callsign of the connected party with the SSID, in
           lowercase.

  You need one section in the above format for each AX.25 interface you
  want to accept incoming AX.25 connections on.

  There are two special lines in the paragraph, one starts with the
  string `defaults' and other starts with the string `default' (yes
  there is a difference). These lines serve special functions.

  The `default' lines purpose should be obvious, this line acts as a
  catch-all, so that any incoming connection on the <interface_call>
  interface that doesn't have a specific rule will match the `default'
  rule. If you don't have a `default' rule, then any connections not
  matching any specific rule will be disconnected immediately without
  notice.

  The `defaults' line is a little more subtle, and here is the trap I
  mentioned earlier. In any of the fields for any definition for a peer
  you can use the `*' character to say `use the default value'. The
  `default' line is what sets those default values. The kernel software
  itself has some defaults which will be used if you don't specify any.
  The trap is that the these defaults apply only to those rules below
  the `default' line not to those above. You may have more than one
  `default' rule per interface definition, and in this way you may
  create groups of default configurations.

  Ok, an illustrative example:

  # ax25d.conf for VK2KTJ - 21/11/95
  # This configuration uses the AX.25 port defined earlier.
  [VK2KTJ-1]
  NOCALL     *     *  *  *  *   0    guest /usr/games/fortune
  defaults   1    10  *  *  *   0    root  /usr/local/sbin/axspawn axspawn %u +
  VK2XLZ-1   *     *  *  *  *   *      *     *         *
  VK2DAY-1   *     *  *  *  *   *      *     *         *
  default    1    10  5 100 5   0    root  /usr/lbbs/bin/bbsrx bbsrx -s %u
  #

  This example says that anybody connecting to the interface on my
  machine with the callsign VK2KTJ-1 will have the following rules
  applied:

  Anyone whose callsign is set to `NOCALL' should use the kernel default
  parameters and have the fortune program run as guest for them.

  The defaults line changes two parameters from the kernel defaults
  (Window and T1) and will run the /usr/local/sbin/axspawn program for
  them. Any copies of /usr/local/sbin/axspawn run this way will appear
  as axspawn in a ps listing for convenience. The next two lines
  definitions for two stations who will receive those permissions.

  The last line in the paragraph is the `catch all' definition that
  everybody else will get (including VK2XLZ and VK2DAY using any other
  SSID other than -1).  This definition sets all of the parameters
  implicitly and will cause the bbsrx program to run with a command line
  argument of the callsign of the connecting peer in lower case with no
  SSID.

  If you wanted to define rules for another interface, even a NetRom
  interface, 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.

  6.2.1.  Configuring axspawn.

  The axspawn program is a simple program that allows AX.25 stations who
  connect to be log 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
  /usr/local/etc/ax25d.conf file:

       default * * * * * 1 root /usr/local/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.

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

       # /usr/local/etc/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.

  7.  Configuring an AX.25 interface for tcp/ip.

  It is very simple to configure an AX.25 port to carry tcp/ip. You need
  to 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.

       # /sbin/ifconfig sl0 44.136.8.5
       # /sbin/ifconfig sl0 netmask 255.255.255.0
       # /sbin/ifconfig sl0 broadcast 44.136.8.255
       # /sbin/ifconfig sl0 arp mtu 256 up
       # /sbin/route add -net 44.136.8.0 sl0
       # /sbin/route add default sl0

  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.

  8.  Configuring an AX.25 interface for NetRom.

  To configure NetRom on an AX.25 interface you must configure two
  files.

  8.1.  Configuring /usr/local/etc/nrports

  The first is the /usr/local/etc/nrports file. This file describes the
  NetRom port.

  This file is formatted as follows:

       callsign  alias     description

  Where:

     callsign
        is the callsign that the NetRom traffic from this port will use.

     alias
        is the NetRom alias this port will have assigned to it.

     description
        is a free text description of the port.

  An example would look something like the following:

       VK2KTJ    MTCOLAH   NetRom Switch Port

  Note again that the first line refers to the first NetRom interface,
  the second line refers to the second NetRom interface and so on.

  8.2.  Configuring /usr/local/etc/nrbroadcast

  The second file is the /usr/local/etc/nrbroadcast file.

  This file is formatted as follows:

       port min_obs def_qual worst_qual verbose

  Where:

     port
        is the port number obtained from the /usr/local/etc/axports
        file. The first line in the file describes AX.25 port number
        one, the second describes port number two etc. If you do not
        have an entry in /usr/local/etc/nrbroadcasts for a port then
        this means that no NetRom routing will occur and any received
        NetRom broadcasts will be ignored for that port.

     min_obs
        is the minimum obselesence value for the port.

     def_qual
        is the default quality for the port.

     worst_qual
        is the worst quality value for the port, any routes under this
        quality will be ignored.

     verbose
        is a flag determining whether full NetRom routing broadcasts
        will occur from this port or only a routing broadcast
        advertising the node itself.

  An example would look something like the following:

  1    1       200      10         1
  2    1       200      10         1

  8.3.  Starting NetRom

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

       # /usr/local/sbin/netromd

  You should then be able to make NetRom connections with the call
  program to NetRom hosts.

  9.  Configuring IP on a NetRom interface.

  Configuring a NetRom interface for tcp/ip is almost identical to
  configuring an AX.25 interface for tcp/ip.

  Again you use the ifconfig and route commands, but you need to
  manually add arp entries for hosts you wish to route to because there
  is no mechanism available for your machine to learn what NetRom
  address it should use to reach a particular IP host.

  So, to configure your nr0 for IP with an IP address of 44.136.8.5 and
  a callsign of VK2KTJ-1 you would use something like:

       # ifconfig nr0 44.136.8.5 hw netrom VK2KTJ-1
       # route add 44.136.8.5 nr0

  Then for each IP host you wish to reach via NetRom you need to set
  route and arp entries. To reach a destination host with an IP address
  of 44.136.80.4 at NetRom address BBS:VK3BBS via a NetRom neighbour
  with callsign VK2SUT-0 you would use commands as follows:

       # route add 44.136.80.4 nr0
       # arp -t netrom -s 44.136.80.4 vk2sut-0
       # nrparms -nodes vk3bbs + BBS 120 6 sl0 vk2sut-0

  The `120' and `6' arguments to the nrparms command are the NetRom
  quality and obsolescence count values for the route.

  10.  Configuring an Ethernet device for AX.25 ala BPQ

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

  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 executed
  configuration commands similar to the following:

       # ifconfig eth0 44.136.8.5 netmask 255.255.255.248 up
       # ifconfig eth0 broadcast 44.136.8.103
       # route add -net 44.136.8.96 netmask 255.255.255.248 eth0

  To configure the BPQ support you need to associate an AX.25 callsign
  with your Ethernet hardware address. You should use the following:

       # axparms -dev eth0 vk2ktj-9

  This says that AX.25 callsign vk2ktj-9 is associated with the eth0
  device.

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

       BPQPARMS                             ; optional - only needed if you want
                                            ; to override the default target addr

               ETH_ADDR  FF:FF:FF:FF:FF:FF  ; Target address

  11.  Ottawa PI/PI2 card driver and Gracilis PacketTwin driver.

  The Ottawa PI and the Gracilis PacketTwin are Z8530 SCC based card for
  IBM PC type machines that are in common usage by Amateur Radio
  operators worldwide.  The PI card supports a high speed half duplex
  (single DMA channel) port, and a low speed (<9k6bps interrupt driven)
  half duplex port. The PI2 is a new version of the card that supports
  an on board radio modem and improved hardware design. The PacketTwin
  card supports two high speed port and is capable of accepting on board
  modems.

  The PI card driver was written by David Perry, <dp@hydra.carleton.edu>
  The PacketTwin card driver was written by Craig Small VK2XLZ,
  <csmall@triode.apana.org.au>.  Both drivers are a standard feature of
  the 1.3.xx kernel.

  Please refer to the AX.25 section above for details on how to
  configure the kernel to include the PI card or the PacketTwin card
  drivers.

  Once you have the appropriate driver configured into your kernel then
  you should reboot and when you do, you should see mention of the PI or
  PacketTwin card driver in the messages that appear on the screen while
  the kernel is booting. The drivers test each of the I/O port addresses
  that the card might be configured for and reports any that it finds.
  You should then look at the /proc/net/dev file and you should see
  reference to devices called pi0a and pi0b or pt0a and pt0b for the PI
  and PacketTwin cards respectively.

  If the devices don't appear then recheck that you have configured and
  compiled your kernel correctly and that you are in fact actually
  running your new kernel. If you still don't then this suggests that
  your PI or PacketTwin card was not detected by the kernel while it
  booted and may indicate that you have some sort of hardware
  conflicting with your PI/PT card that prevented it being detected.

  If all of the above went as planned then you will need to configure
  your PI/PT card for IP. The configuration of the PI/PT cards is
  virtually identical to that of any other IP interface. Something like
  the following should work ok for you:

       # /sbin/ifconfig pi0a 44.136.8.5
       # /sbin/ifconfig pi0a netmask 255.255.255.0
       # /sbin/ifconfig pi0a broadcast 44.136.8.255
       # /sbin/ifconfig pi0a arp mtu 256 up
       # /sbin/route add -net 44.136.8.0 pi0a
       # /sbin/route add default pi0a

  Note that pi0a refers to the `a' port on the first PI card found, and
  that pi0b would therefore refer to the `b' port on the first PI card
  found. pt0a would therefore be the first port on the first PacketTwin
  card detected.

  As usual, when this has been done you can test the interface with the
  ping or telnet command to ensure it is working.

  12.  Z8530 SCC Kiss Emulation

  Joerg Reuter, DL1BKE has developed generic support for Z8530 SCC based
  cards.  His driver is configurable to support a range of different
  types of cards and present an interface that looks like a KISS TNC so
  you can treat it as though it were a KISS TNC.

  12.1.  Obtaining and building the configuration tool package.

  The kernel driver is included in the standard kernel distribution, but
  there are a suite of configuration tools that you will need to obtain
  as well.

  To compile the kernel support you must be sure to answer `Y' to:
  `Z8530 SCC kiss emulation driver for AX.25' when asked during a kernel
  `make config'.

  You can obtain the configuration tools package from:

  ftp.ucsd.edu

       /hamradio/packet/tcpip/incoming/z8530drv-2.0.dl1bke.real.tar.gz

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

       # cd /usr/src
       # gzip -dc z8530drv-2.0.dl1bke.real.tar.gz | tar xvpofz -
       # cd z8530drv
       # rm gencfg sccinit sccstat
       # make dep
       # make utils
       # make install

  Note: I've not followed the instructions included because the version
  of driver in the 1.3.93 kernel is actually newer than that included in
  the package and the normal installation process would have overwritten
  the new kernel source with the older version.

  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.

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

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

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

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

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

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

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

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

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

  14.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: "
       /usr/local/sbin/axattach -s 4800 /dev/ttyS1 VK2KTJ-0 &
       sleep 2
       /sbin/ifconfig sl0 44.136.8.5 netmask 255.255.255.0 \
                       broadcast 44.136.8.255 mtu 512 up
       /sbin/route add 44.136.8.5 sl0
       /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 window 1024 sl0

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

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

iQCVAwUBMbYc2ntNTo2suu5NAQFxhAQAhwS2vMcEdoxw4k+Igjp27VD8RU5rdqf5
zFTLjEAziaE+TbD2w2rDE4xxozsJKouxWygRIsA5muXJJeH9n1ZlBGlsueFEa/x1
U6Ld47TTAOBuJiJXrXWb9uLoOhAnI83DijKsN86neIZlWKhsRY+INfJgugfOjiBJ
Vkgd0pOQww0=
=ZIYU
-----END PGP SIGNATURE-----