Linux Amateur Radio AX.25 HOWTO

Jeff Tranter, VE3ICH

tranter@pobox.com

v2.0, 19 September 2001

The Linux operating system is perhaps the only operating system in the world that can boast native and standard support for the AX.25 packet radio protocol utilized by Amateur Radio operators worldwide. This document describes how to install and configure this support.


Table of Contents
1. Introduction
1.1. Changes from the previous version
1.2. Where to obtain new versions of this document
1.3. Other related documentation
2. The Packet Radio Protocols and Linux
2.1. How it all fits together
3. The AX.25/NET/ROM/ROSE software components
3.1. Finding the kernel, tools and utility packages
4. Installing the AX.25/NET/ROM/ROSE software
4.1. Compiling the kernel
4.2. The AX.25 library, tools, and application programs
5. A note on callsigns, addresses and things before we start
5.1. What are all those T1, T2, N2 and things ?
5.2. Run time configurable parameters
6. Configuring an AX.25 port
6.1. Creating the AX.25 network device
6.2. Creating the /etc/ax25/axports file
6.3. Configuring AX.25 routing
7. Configuring an AX.25 interface for TCP/IP
8. Configuring a NET/ROM port
8.1. Configuring /etc/ax25/nrports
8.2. Configuring /etc/ax25/nrbroadcast
8.3. Creating the NET/ROM Network device
8.4. Starting the NET/ROM daemon
8.5. Configuring NET/ROM routing.
9. Configuring a NET/ROM interface for TCP/IP
10. Configuring a ROSE port
10.1. Configuring /etc/ax25/rsports
10.2. Creating the ROSE Network device
10.3. Configuring ROSE Routing
11. Making AX.25/NET/ROM/ROSE calls
12. Configuring Linux to accept Packet connections
12.1. Creating the /etc/ax25/ax25d.conf file
12.2. A simple example ax25d.conf file
12.3. Starting ax25d
13. Configuring the node software
13.1. Creating the /etc/ax25/node.conf file
13.2. Creating the /etc/ax25/node.perms file
13.3. Configuring node to run from ax25d
13.4. Configuring node to run from inetd
14. Configuring axspawn
14.1. Creating the /etc/ax25/axspawn.conf file
15. Configuring the pms
15.1. Create the /etc/ax25/pms.motd file
15.2. Create the /etc/ax25/pms.info file
15.3. Associate AX.25 callsigns with system users
15.4. Add the PMS to the /etc/ax25/ax25d.conf file
15.5. Test the PMS
16. Configuring the user_call programs
17. Configuring the ROSE Uplink and Downlink commands
17.1. Configuring a ROSE downlink
17.2. Configuring a ROSE uplink
18. Associating AX.25 callsigns with Linux users
19. Configuring APRS
20. The /proc/ file system entries
21. AX.25, NET/ROM, ROSE network programming
21.1. The address families
21.2. The header files
21.3. Callsign mangling and examples
22. Some sample configurations
22.1. Small Ethernet LAN with Linux as a router to Radio LAN
22.2. IPIP encapsulated gateway configuration
22.3. AXIP encapsulated gateway configuration
22.4. Linking NOS and Linux using a pipe device
23. Summary of AX.25-related Linux commands
24. Where do I find more information about .... ?
24.1. Packet Radio
24.2. Protocol Documentation
24.3. Hardware Documentation
24.4. Linux Ham Radio Software
25. Discussion relating to Amateur Radio and Linux
26. Acknowledgements
27. Feedback
28. Distribution Policy

1. Introduction

Amateur radio is a non-profit, non-commercial activity enjoyed by hobbyists world-wide. Radio amateurs are licensed by government authorities to use portions of the radio spectrum allocated to them for non-commercial, non-profit activities including personal communication, public service, and technical experimentation. Packet Radio is a particular digital mode of communication that makes use of networking protocols to provide computer to computer communication.

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

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

  • Document has a new maintainer.

  • Converted to DocBook SGML format. Converted most tabular information to use tables.

  • Released under GNU FDL license.

  • Added information on new drivers for Baycom, YAM, 6PACK, and user mode soundmodem.

  • Added APRS section.

  • Many miscellaneous updates to reflect changes since document was last updated in 1997. There are likely still many errors or outdated information.


1.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. This document is also available in various formats from the Linux Documentation Project.

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.


1.3. 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 deeper insight into other possible configurations. They are:

You may come across references to a Linux HAM HOWTO. This document is obsolete and has been replaced by the Hamsoft Linux Ham Radio Applications and Utilities Database web site. More general Linux information may be found by referencing other Linux HOWTO documents.


2. 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 NET/ROM.

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

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

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

Alan Cox developed some early kernel based AX.25 software support for Linux. Jonathon Naylor has taken up ongoing development of the code, has added NET/ROM and ROSE support and is now the developer of the AX.25 related kernel code. DAMA support was developed by Joerg, DL1BKE. Baycom and Soundmodem support were added by Thomas Sailer. The AX.25 software is now maintained by a small team of developers on SourceForge.

The Linux code supports KISS and 6PACK based TNC's (Terminal Node Controllers), the Ottawa PI card, the Gracilis PacketTwin card and other Z8530 SCC based cards with the generic SCC driver, several parallel and serial port Baycom modems, and serial port YAM modems. Thomas Sailer's kernel soundmodem driver supports SoundBlaster and sound cards based on the Crystal chip set, and his newer user-mode soundmodem uses the standard kernel sound drivers, so it should work with any sound card supported under Linux.

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 NET/ROM protocol. Also included are an AX.25 server style program to handle and dispatch incoming AX.25 connections and a NET/ROM daemon which does most of the hard work for NET/ROM support.

There are utility programs to support APRS, including digipeating and gatewaying to the Internet.


2.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   |         |
|         |           |________     |         |
|         |   NET/ROM          |    | ROSE    |
|         |____________________|____|_________|
|            AX.25                            |
|_____________________________________________|


This diagram simply illustrates that NET/ROM, ROSE and TCP/IP all run directly on top of AX.25, but that each of these protocols is treated as a separate protocol at the programming interface. The `_' 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 NET/ROM, ROSE or TCP/IP devices.

Software Module Diagram of 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 kernel and the hardware. It also shows the relationship between the Socket application programming interface, the actual protocol modules, the kernel networking devices and the device drivers. Anything in this diagram is dependent on anything underneath it, and in general you must configure from the bottom of the diagram upwards. So for example, if you want to run the 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 kernel includes the desired protocol that presents a programming interface that the call program can use. I have attempted to lay out this document in roughly that order.


3. The AX.25/NET/ROM/ROSE software components

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

AX.25 support in the Linux kernel has been fairly stable since the 2.2 series of kernel versions. This document assumes you are using the most recent kernel, which as the time of writing was 2.4.9.

Note

Software versions listed in this document were the latest at the time of writing, but are subject to change. Check for newer versions when downloading them.


3.1. Finding the kernel, tools and utility packages

3.1.1. The kernel source

The kernel source can be found at www.kernel.org and ftp.kernel.org. For the 2.4.9 kernel it would be downloaded from ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.9.tar.gz.


3.1.2. The network tools

The latest release of the standard Linux network tools support AX.25 and NET/ROM and can be found at http://www.tazenda.demon.co.uk/phil/net-tools.

The latest ipchains package can be found at http://netfilter.filewatcher.org/ipchains.

Note

It is usually not necessary to download and install these as any recent Linux distribution should include them.


3.1.3. The AX.25 utilities

The old ax25-utils used with the 2.0 and 2.1 kernels is now obsolete and has been replaced with new packages hosted on SourceForge at http://sourceforge.net/projects/hams.

The software is distributed as three packages: the AX.25 library, tools, and applications. At the time of writing the most recent versions were the following:


4. Installing the AX.25/NET/ROM/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.

Tip

Rather than building and installing from source, you may prefer to install prebuilt binary packages for your system. Debian and RPM format packages are available on various archive sites including http://www.debian.org and http://rpmfind.net; look for "ax25". Incidently, the Debian Linux distribution is considered by many people to be one of the more "Amateur Radio friendly" distributions, and provides many amateur radio applications as Debian packages (one of the founders of the project is a ham).


4.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. You may also want to read the Linux Kernel HOWTO.

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:

# cd /usr/src
# mv linux linux.old
# tar xzvf linux-2.4.9.tar.gz
# cd linux


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

# make menuconfig


If you are running X you can get a graphical interface using:

# make xconfig


You might also try:

# make config


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

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  --->
    <*> UNIX domain sockets
    ...
    [*] TCP/IP networking
    ...
    [?] IP: tunneling
    ...
Amateur Radio Support --->
    --- Packet Radio protocols
    [*]   Amateur Radio AX.25 Level 2 protocol
    [?]     AX.25 DAMA Slave support
    [?]     Amateur Radio NET/ROM protocol
    [?]     Amateur Radio X.25 PLP (Rose)
    AX.25 network device drivers  --->
    <?> Serial port KISS driver
    <?> Serial port 6PACK driver
    <?> BPQ Ethernet driver
    <?> High-speed (DMA) SCC driver for AX.25
    <?> Z8530 SCC driver
    <?> BAYCOM ser12 fullduplex driver for AX.25
    <?> BAYCOM ser12 halfduplex driver for AX.25
    <?> BAYCOM picpar and par96 driver for AX.25
    <?> BAYCOM epp driver for AX.25
    <?> Soundcard modem driver
    [?]   soundmodem support for Soundblaster and compatible cards
    [?]   soundmodem support for WSS and Crystal cards
    [?]   soundmodem support for 1200 baud AFSK modulation
    [?]   soundmodem support for 2400 baud AFSK modulation (7.3728MHz crystal)
    [?]   soundmodem support for 2400 baud AFSK modulation (8MHz crystal)
    [?]   soundmodem support for 2666 baud AFSK modulation
    [?]   soundmodem support for 4800 baud HAPN-1 modulation
    [?]   soundmodem support for 4800 baud PSK modulation
    [?]   soundmodem support for 9600 baud FSK G3RUH modulation
    <?> YAM driver for AX.25


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

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

# make dep
# make clean
# make zImage


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


4.1.1. A word about kernel modules

Compiling drivers as modules is useful if you only use AX.25 occasionally and want to be able to load and unload them on demand to save system resources. However, some people have problems getting the modularized drivers working because they are more complicated to configure. If you've chosen to compile any drivers as modules, then you'll also need to run the commands:

# make modules
# make modules_install


to install your modules in the appropriate location.

You will also need to add some entries into your /etc/modules.conf file to ensure that the kerneld program knows how to locate 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


Tip

On Debian-based Linux systems these entries should go into the file /etc/modutils/aliases and then you need to run /sbin/update-mpodules.


4.2. The AX.25 library, tools, and application programs

After you have successfully compiled and booted your new kernel you need to compile and install the ax25 library, tools, and application programs.

To compile and install libax25 you should use a series of commands similar to the following:

# cd /usr/src
# tar xzvf libax25-0.0.7.tar.gz
# cd libax25-0.0.7
# ./configure --exec_prefix=/usr --sysconfdir=/etc --localstatedir=/var
# make
# make install


Tip

The arguments to the configure command ensure that the files will be installed in the "standard" places under the directory /usr in subdirectories bin, sbin, etc and man. If you simply run configure with no options it will default to putting all files under /usr/local. This can cause the situation where you have configuration files in both /usr and /usr/local. If you want to ensure that this can't happen you can make /usr/local/etc/ax25 a symbolic link to /etc/ax25 at the very beginning of the install process and then you won't have to worry about it.

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

# make installconf


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

You can now build install the AX.25 tools in a similar fashion:

# cd /usr/src
# tar xzvf ax25-tools-0.0.6.tar.gz
# cd ax25-tools-0.0.6
# ./configure --prefix=/usr  --sysconfdir=/etc --localstatedir=/var
# make
# make install
# make installconf (if you want to install the configuration files)


And finally you can install the AX.25 applications:

# cd /usr/src
# tar xzvf ax25-apps-0.0.4.tar.gz
# cd ax25-apps-0.0.4
# ./configure --prefix=/usr  --sysconfdir=/etc --localstatedir=/var
# make
# make install
# make installconf (if you want to install the configuration files)


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 package in the common locations, but some installations have it badly installed and it is unable to locate them.


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

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

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

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

  1. Each AX.25 and NET/ROM 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. NET/ROM will use the callsign/ssid specified for it in its configuration file, but this callsign is only used when your NET/ROM is speaking to another NET/ROM, this is not the callsign/ssid that AX.25 users who wish to use your NET/ROM `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.




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


5.2. Run time configurable parameters

The kernel allows you to change many 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 represent 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 .. 7 2
extended_window_size Extended Window 1 .. 63 32
t1_timeout T1 Timeout 1s .. 30s 10s
t2_timeout T2 Timeout 1s .. 20s 3s
t3_timeout T3 Timeout 0s .. 3600s 300s
idle_timeout Idle Timeout 0m or greater 20m
maximum_retry_count N2 1 .. 31 10
maximum_packet_length AX.25 Frame Length 1 .. 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, e.g. 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 Meaning 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 Meaning 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

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


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


6.1.1. Creating a KISS device

Kernel Compile Options:

Amateur Radio support  --->
    [*] Amateur Radio support
    --- Packet Radio protocols
    <*>   Amateur Radio AX.25 Level 2 protocol
    ...
    AX.25 network device drivers  --->
    --- AX.25 network device drivers
    <*> Serial port KISS driver
    ...


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


6.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/ttyq*), 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/ptyq*' and the slave ends are called `/dev/ttyq*'. There is a one to one relationship between masters and slaves, so /dev/ptyq0 is the master end of a pipe with /dev/ttyq0 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 separate 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/ptyq0 /dev/ptyq1
# /usr/sbin/kissattach /dev/ttyq0 port1 44.135.96.242
# /usr/sbin/kissattach /dev/ttyq1 port2 44.135.96.242


would create two pseudo-tty devices that each look like a normal single port TNC. You would then treat /dev/ttyq0 and /dev/ttyq1 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 summarized as follows:

-c

enables the addition of a one byte checksum to each KISS frame. This is not supported by most KISS implementations, it is supported by the G8BPG KISS ROM.

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


6.1.2. Creating a 6PACK device

Kernel Compile Options:

Amateur Radio support  --->
    [*] Amateur Radio support
    --- Packet Radio protocols
    <*>   Amateur Radio AX.25 Level 2 protocol
    ...
    AX.25 network device drivers  --->
    --- AX.25 network device drivers
    ...
    <*> Serial port 6PACK driver
    ...


6PACK is a protocol that is supported by some TNCs as an alternative to KISS. It is used in a similar fashion to the KISS driver, using the slattach command instead of kissattach.

A mini HOWTO on the 6PACK driver is included in the kernel source code as the file /usr/src/linux/Documentation/networking/6pack.txt.


6.1.3. Creating a Baycom device

Kernel Compile Options:

Amateur Radio support  --->
    [*] Amateur Radio support
    --- Packet Radio protocols
    <*>   Amateur Radio AX.25 Level 2 protocol
    ...
    AX.25 network device drivers  --->
    --- AX.25 network device drivers
    ...
    <?> BAYCOM ser12 fullduplex driver for AX.25
    <?> BAYCOM ser12 halfduplex driver for AX.25
    <?> BAYCOM picpar and par96 driver for AX.25
    <?> BAYCOM epp driver for AX.25
    ...


Thomas Sailer, 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.

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


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


6.1.4.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 NET/ROM or ROSE over it as you please.


6.1.5. Creating a kernel Soundmodem device

Kernel Compile Options:

Amateur Radio support  --->
    [*] Amateur Radio support
    --- Packet Radio protocols
    <*>   Amateur Radio AX.25 Level 2 protocol
    ...
    AX.25 network device drivers  --->
    --- AX.25 network device drivers
    ...
    <*> Soundcard modem driver
    [?]   soundmodem support for Soundblaster and compatible cards
    [?]   soundmodem support for WSS and Crystal cards
    [?]   soundmodem support for 1200 baud AFSK modulation
    [?]   soundmodem support for 2400 baud AFSK modulation (7.3728MHz crystal)
    [?]   soundmodem support for 2400 baud AFSK modulation (8MHz crystal)
    [?]   soundmodem support for 2666 baud AFSK modulation
    [?]   soundmodem support for 4800 baud HAPN-1 modulation
    [?]   soundmodem support for 4800 baud PSK modulation
    [?]   soundmodem support for 9600 baud FSK G3RUH modulation
    ...


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

The driver currently emulates 1200 bps AFSK, 4800 HAPN and 9600 FSK (G3RUH compatible) modem types. The only sound cards currently supported are SoundBlaster and Windows Sound System Compatible models. If you have a sound card of another type, you can try the user-mode soundmodem described later in this document.

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


6.1.5.1. Configuring the sound card

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

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 Window Sound System 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 synthesizer address, and the [-c dma2] parameter is to set the second DMA channel to allow full duplex operation.


6.1.5.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 command 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 Windows Sound System 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


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


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


6.1.5.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 NET/ROM or ROSE over it as you please.


6.1.6. Creating a user-mode Soundmodem device

Kernel Compile Options: not applicable

Thomas Sailer has written a sound modem driver that runs in user-mode using the kernel sound drivers, so it should work with any sound card supported under Linux.

The driver is implemented as the user-mode program soundmodem. The graphical soundmodemconfig program allows configuring and testing the soundmodem driver. As well as kernel sound support you need the kernel AX.25 mkiss driver.

The software and documentation can be downloaded from http://www.baycom.org/~tom/ham/soundmodem.


6.1.7. Creating a YAM device

Kernel Compile Options:

Amateur Radio support  --->
    [*] Amateur Radio support
    --- Packet Radio protocols
    <*>   Amateur Radio AX.25 Level 2 protocol
    ...
    AX.25 network device drivers  --->
    --- AX.25 network device drivers
    ...
    <?> YAM driver for AX.25
    ...


YAM is Yet Another Modem, a 9600 baud modem designed by Nico Palermo. Information on the Linux driver can be found at http://www.teaser.fr/~frible/yam.html while general information on the modem can be found at http://www.microlet.com/yam/


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


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


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


6.1.10.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: Joerg's web page, ftp://db0bm.automation.fh-aachen.de/incoming/dl1bke, ftp://insl1.etec.uni-karlsruhe.de/pub/hamradio/linux/z8530, ftp://ftp.ucsd.edu/hamradio/packet/tcpip/linux, or ftp://ftp.ucsd.edu/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 for 2.0.* kernels and z8530drv-utils-3.0.tar.gz for 2.1.6 or later kernels.

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

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


6.1.10.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 initialized according to the contents of the configuration file. You must do this before you attempt to use the driver.


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


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



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