🚀 go-pugleaf

Archive-name: linux/howto/AX25-HOWTO/part1
Last-modified: 30 Jun 97

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

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

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

  Linux AX25-HOWTO, Amateur Radio.
  Terry Dawson, VK2KTJ, terry@perf.no.itg.telstra.com.au
  v1.4, 20 June 1997

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

  1.  Introduction.

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

  The Linux implementation of the amateur radio protocols is very
  flexible.  To people relatively unfamiliar with the Linux operating
  system the configuration process may look daunting and complicated. It
  will take you a little time to come to understand how the whole thing
  fits together. You will find configuration very difficult if you have
  not properly prepared yourself by learning about Linux in general. You
  cannot expect to switch from some other environment to Linux without
  learning about Linux itself.

  1.1.  Changes from the previous version

  Additions:
          Added the section missing from the BayCom configuration section.
          Added 'hdlcdrv' to the list of modules needed to 'insmod' for BayCom.
          Added Rose Uplink and Downlink configuration - thanks Rick

  Corrections/Updates:
          Added kernel compile options into low level configuration section.
          Removed that nasty axctl error.
          Many small changes here and there to the BayCom and SoundModem sections.
          Hopefully I've unconfused the kernel/tools issue.
          Updated the home ftp site.

  ToDo:
          Fix up the SCC section, this is probably wrong.
          Expand on the programming section.
          Add some references to AX.25 and NetRom source documentation.

  1.2.  Other related documentation.

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

  They are:

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

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

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

  and:

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

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

  2.  Where to obtain new versions of this document.

  The best place to obtain the latest version of this document is from a
  Linux Documentation Project archive. The Linux Documentation Project
  runs a Web Server and this document appears there as The AX25-HOWTO
  <http://sunsite.unc.edu/LDP/HOWTO/AX25-HOWTO.html>. You can always
  contact me, but I pass new versions of the document directly to the
  LDP HOWTO coordinator, so if it isn't there then chances are I haven't
  finished it.

  3.  The Packet Radio Protocols and Linux.

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

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

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

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

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

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

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

  3.1.  How it all fits together.

  The Linux AX.25 implementation is a brand new implementation. While in
  many ways it may looks similar to NOS, or BPQ or other AX.25
  implementations, it is none of these and is not identical to any of
  them. The Linux AX.25 implementation is capable of being configured to
  behave almost identically to other implementations, but the
  configuration process is very different.

  To assist you in understanding how you need to think when configuring
  this section describes some of the structural features of the AX.25
  implementation and how it fits into the context of the overall Linux
  structure.

  Simplified Protocol Layering Diagram

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

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

  Software module diagram on Linux Network Implementation

  ----------------------------------------------------------------------------
   User    | Programs  |   call        node    ||  Daemons | ax25d  mheardd
           |           |   pms         mheard  ||          | inetd  netromd
  ----------------------------------------------------------------------------
           | Sockets   | open(), close(), listen(), read(), write(), connect()
           |           |------------------------------------------------------
           |           |    AF_AX25   |  AF_NETROM  |   AF_ROSE   |  AF_INET
           |------------------------------------------------------------------
  Kernel   | Protocols |    AX.25     |   NetRom    |     Rose    | IP/TCP/UDP
           |------------------------------------------------------------------
           | Devices   |    ax0,ax1   |  nr0,nr1    | rose0,rose1 | eth0,ppp0
           |------------------------------------------------------------------
           | Drivers   |  Kiss   PI2   PacketTwin   SCC   BPQ     | slip ppp
           |           |      Soundmodem      Baycom              | ethernet
  ----------------------------------------------------------------------------
  Hardware | PI2 Card, PacketTwin Card, SCC card, Serial port, Ethernet Card
  ----------------------------------------------------------------------------

  This diagram is a little more general than the first. This diagram
  attempts to show the relationship between user applications, the ker�
  nel and the hardware.  It also shows the relationship between the
  Socket application programming interface, the actual protocol modules,
  the kernel networking devices and the device drivers. Anything in this
  diagram is dependent on anything underneath it, and in general you
  must configure from the bottom of the diagram upwards.  So for exam�
  ple, if you want to run the call program you must also configure the
  Hardware, then ensure that the kernel has the appropriate device
  driver, that you create the appropriate network device, that the ker�
  nel includes the desired protocol that presents a programming inter�
  face that the call program can use. I have attempted to lay out this
  document in roughly that order.

  4.  The AX.25/NetRom/Rose software components.

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

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

  4.1.  Finding the kernel, tools and utility packages.

  4.1.1.  The kernel source:

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

  ftp.funet.fi

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

  The current version of Jonathons upgrade patch is available at:

  ftp.pspt.fi

       /pub/linux/ham/ax25/ax25-module-14b.tar.gz

  4.1.2.  The network tools:

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

  ftp.inka.de

  /pub/comp/Linux/networking/net-tools/net-tools-1.33.tar.gz

  The latest ipfwadm package can be found at:

  ftp.xos.nl

       /pub/linux/ipfwadm/

  4.1.3.  The AX25 utilities:

  There are two different families of AX25-utilities. One is for the
  2.0.* kernels and the other will work with either the 2.1.* kernels or
  the 2.0.*+moduleXX kernels. The ax25-utils version number indicate the
  oldest version of kernel that they will work with. Please choose a
  version of the ax25-utils appropriate to your kernel. The following
  are working combinations.  You must use one of the following
  combinations, any other combination will not work, or will not work
  well.

       Linux Kernel            AX25 Utility set
       ---------------------   -------------------------
       linux-2.0.29            ax25-uitls-2.0.12c.tar.gz
       linux-2.0.28+module12   ax25-utils-2.1.22b.tar.gz
       linux-2.0.30+module14   ax25-utils-2.1.42.tar.gz
       linux-2.1.22++          ax25-utils-2.1.22b.tar.gz
       linux-2.1.42++          ax25-utils-2.1.42.tar.gz

  The AX.25 utility programs can be found at:

  ftp.pspt.fi <ftp://ftp.pspt.fi/pub/linux/ham/ax25/>

  or at:

  sunsite.unc.edu <ftp://sunsite.unc.edu/pub/Linux/apps/ham/>

  5.  Installing the AX.25/NetRom/Rose software.

  To successfully install AX.25 support on your linux system you must
  configure and install an appropriate kernel and then install the AX.25
  utilities.

  5.1.  Compiling the kernel.

  If you are already familiar with the process of compiling the Linux
  Kernel then you can skip this section, just be sure to select the
  appropriate options when compiling the kernel. If you are not, then
  read on.

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

       # mv linux linux.old
       # cd /usr/src
       # tar xvfz linux-2.0.30.tar.gz
       # tar xvfz /pub/net/ax25/ax25-module-14b.tar.gz
       # patch -p0 </usr/src/ax25-module-14b/ax25-2.0.30-2.1.42-5.diff
       # cd linux

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

       # make menuconfig

  You might also try:

       # make config

  I'm going to describe the full screen method (menuconfig) because it
  is easier to move around, but you use whichever you are most
  comfortable with.

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

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

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

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

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

       # make dep
       # make clean
       # make zImage

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

  5.1.1.  A word about Kernel modules

  I recommend that you don't compile any of the drivers as modules. In
  nearly all installations you gain nothing but additional complexity.
  Many people have problems trying to get the modularised components
  working, not because the software is faulty but because modules are
  more complicated to install and configure.

  If you've chosen to compile any of the components as modules, then
  you'll also need to use:

       # make modules
       # make modules_install

  to install your modules in the appropriate location.

  You will also need to add some entries into your /etc/conf.modules
  file that will ensure that the kerneld program knows how to handle the
  kernel modules. You should add/modify the following:

       alias net-pf-3     ax25
       alias net-pf-6     netrom
       alias net-pf-11    rose
       alias tty-ldisc-1  slip
       alias tty-ldisc-3  ppp
       alias tty-ldisc-5  mkiss
       alias bc0          baycom
       alias nr0          netrom
       alias pi0a         pi2
       alias pt0a         pt
       alias scc0         optoscc    (or one of the other scc drivers)
       alias sm0          soundmodem
       alias tunl0        newtunnel
       alias char-major-4 serial
       alias char-major-5 serial
       alias char-major-6 lp

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

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

     modularised
        the protocols and drivers have all been modularised so that you
        can insmod and rmmod them whenever you wish. This reduces the
        kernel memory requirements for infrequently used modules and
        makes development and bug hunting much simpler. That being said,
        it also makes configuration slightly more difficult.

     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. The Rose protocol is one important
        addition.

  5.2.  The network configuration tools.

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

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

  5.2.1.  Building the standard net-tools release.

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

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

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

  The tools will compile cleanly against the source after you remove the
  first line "usage und man page, info text von alexey" from the file
  arp.c.

  When the compilation is complete, you should 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 and utility programs.

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

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

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

  If this is a first time installation, that is you've never installed
  any ax25 utilities on your machine before you should also use the:

       # make installconf

  command to install some sample configuration files into the /etc/ax25/
  directory from which to work.

  If you get messages something like:

  gcc -Wall -Wstrict-prototypes -O2 -I../lib -c call.c
  call.c: In function `statline':
  call.c:268: warning: implicit declaration of function `attron'
  call.c:268: `A_REVERSE' undeclared (first use this function)
  call.c:268: (Each undeclared identifier is reported only once
  call.c:268: for each function it appears in.)

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

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

  Each AX.25 and NetRom port on your system must have a callsign/ssid
  allocated to it. These are configured in the configuration files that
  will be described in detail later on.

  Some AX.25 implementations such as NOS and BPQ will allow you to
  configure the same callsign/ssid on each AX.25 and NetRom port. For
  somewhat complicated technical reasons Linux does not allow this. This
  isn't as big a problem in practise as it might seem.

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

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

  2. TCP/IP will use the callsign/ssid of the AX.25 port it is being
     transmitted or received by, ie the one you configured for the AX.25
     interface in point 1.

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

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

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

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

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

  Not every AX.25 implementation is a TNC2. Linux uses nomenclature that
  differs in some respects from that you will be used to if your sole
  experience with packet is a TNC. The following table should help you
  interpret what each of the configurable items are, so that when you
  come across them later in this text you'll understand what they mean.

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

  6.2.  Run time configurable parameters

  The 2.1.* and 2.0.* +moduleXX kernels have a new feature that allows
  you to change many previously unchangable parameters at run time. If
  you take a careful look at the /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 in /proc/sys/net/ax25/<portname>/ is as
  follows:

  FileName              Meaning              Values                  Default
  ip_default_mode       IP Default Mode      0=DG 1=VC               0
  ax25_default_mode     AX.25 Default Mode   0=Normal 1=Extended     0
  backoff_type          Backoff              0=Linear 1=Exponential  1
  connect_mode          Connected Mode       0=No 1=Yes              1
  standard_window_size  Standard Window      1  <= N <= 7            2
  extended_window_size  Extended Window      1  <= N <= 63           32
  t1_timeout            T1 Timeout           1s <= N <= 30s          10s
  t2_timeout            T2 Timeout           1s <= N <= 20s          3s
  t3_timeout            T3 Timeout           0s <= N <= 3600s        300s
  idle_timeout          Idle Timeout         0m <= N                 20m
  maximum_retry_count   N2                   1  <= N <= 31           10
  maximum_packet_length AX.25 Frame Length   1  <= N <= 512          256

  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.

  The structure of the files in /proc/sys/net/netrom/ is as follows:

  FileName                       Values                  Default
  default_path_quality                                   10
  link_fails_count                                       2
  network_ttl_initialiser                                16
  obsolescence_count_initialiser                         6
  routing_control                                        1
  transport_acknowledge_delay                            50
  transport_busy_delay                                   1800
  transport_maximum_tries                                3
  transport_requested_window_size                        4
  transport_timeout                                      1200

  The structure of the files in /proc/sys/net/rose/ is as follows:

  FileName                       Values                  Default
  acknowledge_hold_back_timeout                          50
  call_request_timeout                                   2000
  clear_request_timeout                                  1800
  link_fail_timeout                                      1200
  maximum_virtual_circuits                               50
  reset_request_timeout                                  1800
  restart_request_timeout                                1800
  routing_control                                        1
  window_size                                            3

  To set a parameter all you need to do is write the desired value to
  the file itself, for example to check and set the Rose window size
  you'd use something like:

       # cat /proc/sys/net/rose/window_size
       3
       # echo 4 >/proc/sys/net/rose/window_size
       # cat /proc/sys/net/rose/window_size
       4

  7.  Configuring an AX.25 port.

  Each of the AX.25 applications read a particular configuration file to
  obtain the parameters for the various AX.25 ports configured on your
  Linux machine.  For AX.25 ports the file that is read is the
  /etc/ax25/axport file.  You must have an entry in this file for each
  AX.25 port you want on your system.

  7.1.  Creating the AX.25 network device.

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

  In the Linux AX.25 code there are a number of device drivers. The most
  common is probably the KISS driver, but others are the SCC driver(s),
  the Baycom driver and the SoundModem driver.
  Each of these device drivers will create a network device when it is
  started.

  7.1.1.  Creating a KISS device.

  Kernel Compile Options:

       General setup  --->
           [*] Networking support
       Network device support  --->
           [*] Network device support
           ...
           [*] Radio network interfaces
           [*] Serial port KISS driver for AX.25

  Probably the most common configuration will be for a KISS TNC on a
  serial port.  You will need to have the TNC preconfigured and
  connected to your serial port.  You can use a communications program
  like minicom or seyon to configure the TNC into kiss mode.

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

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

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

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

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

  Please refer to the man pages for more information.

  7.1.1.1.  Configuring for Dual Port TNC's

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

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

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

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

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

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

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

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

     -l enables logging of information to the syslog logfile.

  7.1.2.  Creating a Baycom device.

  Kernel Compile Options:

       Code maturity level options  --->
           [*] Prompt for development and/or incomplete code/drivers
       General setup  --->
           [*] Networking support
       Network device support  --->
           [*] Network device support
           ...
           [*] Radio network interfaces
           [*] BAYCOM ser12 and par96 driver for AX.25

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

  Your first step should be to determine the i/o and addresses of the
  serial or parallel port(s) you have Baycom modem(s) connected to.
  When you have these you must configure the Baycom driver with them.

  The BayCom driver creates network devices called: bc0, bc1, bc2 etc.
  when it is configured.

  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 hdlcdrv
       # insmod baycom mode="ser12*" iobase=0x3f8 irq=4

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

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

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

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

       # insmod hdlcdrv
       # insmod baycom

  or that you compiled the kernel with the driver inbuilt.

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

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

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

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

  7.1.3.  Configuring the AX.25 channel access parameters.

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

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

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

       # sethdlc -i bc0 -a txd 200 slot 100 ppersist 40 half

  Note that the timing values are in milliseconds.

  7.1.3.1.  Configuring the Kernel AX.25 to use the BayCom device

  The BayCom driver creates standard network devices that the AX.25
  Kernel code can use. Configuration is much the same as that for a PI
  or PacketTwin card.

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

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

  will assign the BayCom device bc0 the AX.25 callsign VK2KTJ-15.
  Alternatively you can use the axparms command, you'll still need to
  use the ifconfig command to bring the device up though:

       # ifconfig bc0 up
       # axparms -setcall bc0 vk2ktj-15

  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 BayCom 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. You
  can configure it for TCP/IP, add it to ax25d and run NetRom or Rose
  over it as you please.

  7.1.4.  Creating a SoundModem device.

  Kernel Compile Options:

       Code maturity level options  --->
           [*] Prompt for development and/or incomplete code/drivers
       General setup  --->
           [*] Networking support
       Network device support  --->
           [*] Network device support
           ...
           [*] Radio network interfaces
           [*] Soundcard modem driver for AX.25
           [?] Soundmodem support for Soundblaster and compatible cards
           [?] Soundmodem support for WSS and Crystal cards
           [?] Soundmodem support for 1200 baud AFSK modulation
           [?] Soundmodem support for 4800 baud HAPN-1 modulation
           [?] Soundmodem support for 9600 baud FSK G3RUH modulation

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

  The driver currently emulates 1200 bps AFSK, 4800 HAPN and 9600 FSK
  (G3RUH compatible) modem types. The only sound cards currently
  supported are SoundBlaster and WindowsSoundSystem Compatible models.
  The sound cards require some circuitry to help them drive the Push-To-
  Talk circuitry, and information on this is available from Thomas's
  SoundModem PTT circuit web page
  <http://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html>. There are
  quite a few possible options, they are: detect the sound output from
  the soundcard, or use output from a parallel port, serial port or midi
  port. Circuit examples for each of these are on Thomas's site.

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

  Note: the SoundModem driver competes for the same resources as the
  Linux sound driver. So if you wish to use the SoundModem driver you
  must ensure that the Linux sound driver is not installed. You can of
  course compile them both as modules and insert and remove them as you
  wish.

  7.1.4.1.  Configuring the sound card.

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

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

  So, for example, if you wished to configure a soundblaster card at i/o
  base address 0x388, irq 10 and DMA 1 you would use:
       # setcrystal -s 0x388 -i 10 -d 1

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

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

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

  7.1.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 hdlcdrv
       # insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1

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

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

       # insmod hdlcdrv
       # insmod soundmodem

  or that you compiled the kernel with the driver inbuilt.

  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

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

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

  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

  7.1.4.3.  Configuring the AX.25 channel access parameters.

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

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

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

       # sethdlc -i sm0 -a txd 100 slot 50 ppersist 128 full

  Note that the timing values are in milliseconds.

  7.1.4.4.  Setting the audio levels and tuning the driver.

  It is very important that the audio levels be set correctly for any
  radio based modem to work. This is equally true of the SoundModem.
  Thomas has developed some utility programs that make this task easier.
  They are called smdiag and smmixer.

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

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

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

       # smdiag -i sm0 -e

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

       # smmixer -i sm0

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

  The SoundModem driver creates standard network devices that the AX.25
  Kernel code can use. Configuration is much the same as that for a PI
  or PacketTwin card.

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

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

  will assign the SoundModem device sm0 the AX.25 callsign VK2KTJ-15.
  Alternatively you can use the axparms command, but you still need the
  ifconfig utility to bring the device up:

       # ifconfig sm0 up
       # axparms -setcall sm0 vk2ktj-15

  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. You
  can configure it for TCP/IP, add it to ax25d and run NetRom or Rose
  over it as you please.

  7.1.5.  Creating a PI card device.

  Kernel Compile Options:

       General setup  --->
           [*] Networking support
       Network device support  --->
           [*] Network device support
           ...
           [*] Radio network interfaces
           [*] Ottawa PI and PI/2 support for AX.25

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

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

  This command would configure the first port on the first PI card
  detected with the callsign VK2KTJ-15 and make it active. To use the
  device all you now need to do is to configure an entry into your
  /etc/ax25/axports file with a matching callsign/ssid and you will be
  ready to continue on.

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

  7.1.6.  Creating a PacketTwin device.

  Kernel Compile Options:

       General setup  --->
           [*] Networking support
       Network device support  --->
           [*] Network device support
           ...
           [*] Radio network interfaces
           [*] Gracilis PackeTwin support for AX.25

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

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

  This command would configure the first port on the first PacketTwin
  card detected with the callsign VK2KTJ-15 and make it active. To use
  the device all you now need to do is to configure an entry into your
  /etc/ax25/axports file with a matching callsign/ssid and you will be
  ready to continue on.

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

  7.1.7.  Creating a generic SCC device.

  Kernel Compile Options:

       General setup  --->
           [*] Networking support
       Network device support  --->
           [*] Network device support
           ...
           [*] Radio network interfaces
           [*] Z8530 SCC KISS emulation driver for AX.25

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

  7.1.7.1.  Obtaining and building the configuration tool package.

  While the kernel driver is included in the standard kernel
  distribution, Joerg distributes more recent versions of his driver
  with the suite of configuration tools that you will need to obtain as
  well.

  You can obtain the configuration tools package from:

  db0bm.automation.fh-aachen.de

       /incoming/dl1bke/

  or:

  insl1.etec.uni-karlsruhe.de

       /pub/hamradio/linux/z8530/

  or:

  ftp.ucsd.edu

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

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

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

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

       # cd /usr/src
       # gzip -dc z8530drv-2.4a.dl1bke.tar.gz | tar xvpofz -
       # cd z8530drv
       # make clean
       # make dep
       # make module         # If you want to build the driver as a module
       # make for_kernel     # If you want the driver to built into your kernel
       # make install

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

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

  If you chose to 'make for_kernel' then you will need to recompile your
  kernel. To ensure that you include support for the z8530 driver you
  must be sure to answer `Y' to: `Z8530 SCC kiss emulation driver for
  AX.25' when asked during a kernel `make config'.

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

  7.1.7.2.  Configuring the driver for your card.

  The z8530 SCC driver has been designed to be as flexible as possible
  so as to support as many different types of cards as possible. With
  this flexibility has come some cost in configuration.

  There is more comprehensive documentation in the package and you
  should read this if you have any problems. You should particularly
  look at doc/scc_eng.doc or doc/scc_ger.doc for more detailed
  information. I've paraphrased the important details, but as a result
  there is a lot of lower level detail that I have not included.

  The main configuration file is read by the sccinit program and is
  called /etc/z8530drv.conf. This file is broken into two main stages:
  Configuration of the hardware parameters and channel configuration.
  After you have configured this file you need only add:

       # sccinit

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

  7.1.7.2.1.  Configuration of the hardware parameters.

  The first section is broken into stanzas, each stanza representing an
  8530 chip. Each stanza is a list of keywords with arguments. You may
  specify up to four SCC chips in this file by default. The #define
  MAXSCC 4 in scc.c can be increased if you require support for more.

  The allowable keywords and arguments are:

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

     data_a
        this keyword is used to specify the address of the data port for
        the z8530 channel `A'. The argument is a hexadecimal number e.g.
        0x300

     ctrl_a
        this keyword is used to specify the address of the control port
        for the z8530 channel `A'. The arguments is a hexadecimal number
        e.g. 0x304

     data_b
        this keyword is used to specify the address of the data port for
        the z8530 channel `B'. The argument is a hexadecimal number e.g.
        0x301

     ctrl_b
        this keyword is used to specify the address of the control port
        for the z8530 channel `B'. The arguments is a hexadecimal number
        e.g. 0x305

     irq
        this keyword is used to specify the IRQ used by the 8530 SCC
        described in this stanza. The argument is an integer e.g. 5

     pclock
        this keyword is used to specify the frequency of the clock at
        the PCLK pin of the 8530. The argument is an integer frequency
        in Hz which defaults to 4915200 if the keyword is not supplied.

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

        PA0HZP
           the PA0HZP SCC Card

        EAGLE
           the Eagle card

        PC100
           the DRSI PC100 SCC card

        PRIMUS
           the PRIMUS-PC (DG9BL) card

        BAYCOM
           BayCom (U)SCC card

     escc
        this keyword is optional and is used to enable support for the
        Extended SCC chips (ESCC) such as the 8580, 85180, or the 85280.
        The argument is a character string with allowed values of `yes'
        or `no'. The default is `no'.

     vector
        this keyword is optional and specifies the address of the vector
        latch (also known as "intack port") for PA0HZP cards. There can
        be only one vector latch for all chips. The default is 0.

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

     option
        this keyword is optional and defaults to 0.

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

     BayCom USCC

          chip    1
          data_a  0x300
          ctrl_a  0x304
          data_b  0x301
          ctrl_b  0x305
          irq     5
          board   BAYCOM
          #
          # SCC chip 2
          #
          chip    2
          data_a  0x302
          ctrl_a  0x306
          data_b  0x303
          ctrl_b  0x307
          board   BAYCOM

     PA0HZP SCC card

     chip 1
     data_a 0x153
     data_b 0x151
     ctrl_a 0x152
     ctrl_b 0x150
     irq 9
     pclock 4915200
     board PA0HZP
     vector 0x168
     escc no
     #
     #
     #
     chip 2
     data_a 0x157
     data_b 0x155
     ctrl_a 0x156
     ctrl_b 0x154
     irq 9
     pclock 4915200
     board PA0HZP
     vector 0x168
     escc no

     DRSI SCC card

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

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

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

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

  will generate a skeleton configuration for the OptoSCC card.

  7.1.7.3.  Channel Configuration

  The Channel Configuration section is where you specify all of the
  other parameters associated with the port you are configuring. Again
  this section is broken into stanzas. One stanza represents one logical
  port, and therefore there would be two of these for each one of the
  hardware parameters stanzas as each 8530 SCC supports two ports.

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

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

     device
        this keyword must be the first line of a port definition and
        specifies the name of the special device file that the rest of
        the configuration applies to. e.g. /dev/scc0

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

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

        dpll
           normal halfduplex operation

        external
           MODEM supplies its own Rx/Tx clock

        divider
           use fullduplex divider if installed.

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

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

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

     bufsize
        this keyword specifies the size of the receive and transmit
        buffers. The arguments is in bytes and represents the total
        length of the frame, so it must also take into account the AX.25
        headers and not just the length of the data field. This keyword
        is optional and default to 384

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  7.1.7.4.  Using the driver.

  To use the driver you simply treat the /dev/scc* devices just as you
  would a serial tty device with a KISS TNC connected to it. For
  example, to configure Linux Kernel networking to use your SCC card you
  could use something like:

       # kissattach -s 4800 /dev/scc0 VK2KTJ

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

       attach asy scc0 0 ax25 scc0 256 256 4800

  7.1.7.5.  The sccstat and sccparam tools.

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

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

iQCVAwUBNDRVA3tNTo2suu5NAQHXdQP/VeRl2nD6+i/Um93l+WN8aDMFhuIkUUhd
XD6Nsu/XpflqjnaSnhd/jXSD+9y1jRJCbu298j/s3/ydXuutaZC0a6qToLp+mDg+
ug5nzQv7lyDk+xY1mXfXKUyfwHVZU8EJrgMxpUkYNEGIjaHXqiz6PSGZdQ4luAl0
4jnJU0PPx74=
=AvXx
-----END PGP SIGNATURE-----