LinuxHam - User contributions [en]

TCP/IP

2006-04-18T19:59:19Z

Wb5aohpacket: stdout redirection to remote tcp/ip/udp listeners

==== NOTE to Ralf DL5RB: I don't have the slightest idea where this should go,
but it may be a useful application footnote someplace to tcp/ip over ax25 connection examples.
Place it where it may be appropriate. It isn't a main topic. -WB5AOH-

==============================================================================

Redirection of stdout to remote TCP, UDP or IP destinations:

Although not strictly limited to ax25 tcp/ip (it will work anywhere tcp/ip/udp will), this can at times be useful for odd jobs, usually pertaining to one-way datafeeds. The only place I have seen remote redirection documented is an obscure reference to it in the vast work that we know as the bash (1) manpage.

Synopsis:
/dev/tcp/host/port
/dev/udp/host/port
/dev/ip/host/protocol
(since at least kernel 2.2.x, maybe earlier)

TCP Example:

some-command parm1 parm2 > /dev/tcp/12.34.56.78/1234

will collect the redirectable stdout from the command, and open a tcp connection to the remote address 12.34.56.78 and port 1234, and deliver the redirected output to whatever process happens to be listening on that port at that remote address. If DNS is available, or if the reference is available in /etc/hosts, a hostname can certainly be used in place of the numeric address. Upon completion of the command, or other EOF/error condition, the connection will be closed down.

It is possible to create arbitrary listen sockets at destinations with netcat (sometimes aliased as nc) and the output from netcat can be redirected to about anything else you might need like file creation, screen display, tar, or whatever. Be careful to watch for security problems with open ports, depending on what you are doing with the destination host system (if you are running ax25 sockets you probably aren't running it on some highly valued host anyhow). You might want to restrict the possible ip addresses that the destination host can be reached from with an iptables filter rule entry. If you are using netcat as a listener, you might want to put the netcat listen command into an endless loop in a simple script, as the netcat listener will terminate on each connection close, if the process needs to take place repetitively.

UDP example:

some-command parm1 parm2 > /dev/udp/12.34.56.78/1234

Same as above, but since UDP is connectionless and stateless, the connection start and teardown process isn't applicable. Netcat has a udp mode as well, and see the netcat(1) documentation for a discussion on some of the fine points of udp listen socket behavior. Use the -u flag with netcat for UDP mode.

A useful example is to inject packets into the UDP listen port of aprsd, usually port 1315. In fact I have used this technique to forward aprs packets from a remote slave aprsd listener daemon to another aprsd process which can forward them to the main internet aprsd network, without the bidirectional overhead of the entire body of aprs traffic just to the remote listener aprsd. I am using it to add site diversity reception to a local aprsd server that feeds the internet aprsd net. Use the one-line script:

netcat localhost 14579 > /dev/udp/remotehost/1315

Netcat will connect to the localhost aprsd output process, and print the local ax25 aprs monitored packets onto stdout, which will be redirected over whatever the tcp/ip/udp medium is to what is expected to be another aprsd process at remotehost listening on udp port 1315. That destination aprsd process needs to be configured to recognize our sending ip address as a trusted source, and you can also put it into an iptables filter rule if you like. When the udp packet is consumed by aprsd, it will handle that packet as any other and forward it to the internet, and the terse tracing of aprsd will indicate that it arrived as a UDP input. There appears to be a subtle difference in the behavior of UDP listen socket behavior with aprsd as compared to netcat, and the aprsd behavior seems to be a little more stable over time, while netcat seems to appear to close the UDP listen socket arbitrarily. Your mileage may vary.

There also is /dev/ip/host/protocol. I haven't found anything useful for this yet, but it also exists. Possibly it could be useful to generate ip packets on protocol 93 or 94 and inject them into
ax25ipd or similar listeners. Whatever internal header the target protocol requires in addition to useful data would somehow have to be prepended/appended to each packets data by the process that generates the redirected data to begin with. Maybe pipe it through some intermediate process written for the purpose. It should also be stateless at the IP layer, the target protocol could be a stateful entity depending on what the protocol does.

See also: netcat(1), bash(1), aprsd docs, aprsd.conf

-WB5AOH-

Configuring an AX.25 port

2006-04-18T18:04:39Z

Wb5aohpacket: /* 6.1.1. Creating a KISS device */

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.

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

It is possible and occasionally useful to manually reissue the kissparms command, with your desired parameters as shown above, if you occasionally need to reload the specific parameters into a TNC that has had to be restarted or power-cycled, and the parameters are those that are not default for what the TNC comes up with when brought up cold. It can also be useful to include such a kissparms command on a crontab line so this happens periodically if the station is unattended and something goes wrong with the TNC. Kissparms output to the TNC also is displayed by the listen(1) monitoring command, if running with the -a switch which displays outgoing as well as incoming packets. -WB5AOH-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==== The sccstat and sccparam tools ====

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

# sccstat /dev/scc0

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

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

# sccparam /dev/scc0 txtail 0x8

=== Creating a BPQ ethernet device ===

Kernel Compile Options:

General setup --->
[*] Networking support
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[*] BPQ Ethernet driver for AX.25

Linux supports BPQ Ethernet compatibility. This enables you to run the AX.25 protocol over your Ethernet LAN and to interwork your linux machine with other BPQ machines on the LAN.

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

Configuration is quite straightforward. You firstly must have configured a standard Ethernet device. This means you will have compiled your kernel to support your Ethernet card and tested that this works. Refer to the Ethernet-HOWTO for more information on how to do this.

To configure the BPQ support you need to configure the Ethernet device with an AX.25 callsign. The following command will do this for you:

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

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

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

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

LINK SUPPORT

MAX STACKS 1
MAX BOARDS 1

LINK DRIVER E2000 ; or other MLID to suit your card

INT 10 ;
PORT 300 ; to suit your card

FRAME ETHERNET_II

PROTOCOL BPQ 8FF ETHERNET_II ; required for BPQ - can change PID

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

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

== Creating the /etc/ax25/axports file ==

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

portname callsign baudrate paclen window description

where:

portname

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

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

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

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

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

is a textual description of the port.

In my case, mine looks like:

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

Remember, you must assign unique callsign/ssid to each AX.25 port you create. Create one entry for each AX.25 device you want to use, this includes KISS, Baycom, SCC, PI, PT and Soundmodem ports. Each entry here will describe exactly one AX.25 network device. The entries in this file are associated with the network devices by the callsign/ssid. This is at least one good reason for requiring unique callsign/ssid.

== Configuring AX.25 routing ==

You may wish to configure default digipeaters paths for specific hosts. This is useful for both normal AX.25 connections and also IP based connections. The axparms command enables you to do this. Again, the man page offers a complete description, but a simple example might be:

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

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

Some sample configurations

2006-04-18T17:42:30Z

Wb5aohpacket: /* A typical /etc/ax25/ax25ipd.conf file */

== Some sample configurations ==

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

=== Small Ethernet LAN with Linux as a router to Radio LAN ===

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

<pre>
. . . . . .
___ _________ .
| Network / \ . Network
| 44.136.8.96/29| | . 44.136.8/24 \ | /
| | Linux | . \|/
| | | . _____ __________ |
| eth0 | Router | . / \ / \ |
|_______________| |_____| TNC |____| Radio |__/
| 44.136.8.97 | and | . \_____/ \__________/
| | | sl0
| | Server | 44.136.8.5
| | | .
| | | .
| \_________/ .
_|_ . . . . . .
</pre>

<pre>
#!/bin/sh
# /etc/rc.net
# This configuration provides one KISS based AX.25 port and one
# Ethernet device.

echo "/etc/rc.net"
echo " Configuring:"

echo -n " loopback:"
/sbin/ifconfig lo 127.0.0.1
/sbin/route add 127.0.0.1
echo " done."

echo -n " ethernet:"
/sbin/ifconfig eth0 44.136.8.97 netmask 255.255.255.248 \
broadcast 44.136.8.103 up
/sbin/route add 44.136.8.97 eth0
/sbin/route add -net 44.136.8.96 netmask 255.255.255.248 eth0
echo " done."

echo -n " AX.25: "
kissattach -i 44.136.8.5 -m 512 /dev/ttyS1 4800
ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.8.255
route add -host 44.136.8.5 sl0
route add -net 44.136.8.0 window 1024 sl0

echo -n " NET/ROM: "
nrattach -i 44.136.8.5 netrom

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

# end
</pre>

/etc/ax25/axports

<pre>
# name callsign speed paclen window description
4800 VK2KTJ-0 4800 256 2 144.800 MHz
</pre>

/etc/ax25/nrports

<pre>
# name callsign alias paclen description
netrom VK2KTJ-9 LINUX 235 Linux Switch Port
</pre>

/etc/ax25/nrbroadcast

<pre>
# ax25_name min_obs def_qual worst_qual verbose
4800 1 120 10 1
</pre>

* You must have IP_FORWARDING enabled in your kernel.
* The AX.25 configuration files are pretty much those used as examples in the earlier sections, refer to those where necessary.
* I've chosen to use an IP address for my radio port that is not within my home network block. I needn't have done so, I could have easily used 44.136.8.97 for that port too.
* 44.136.8.68 is my local IPIP encapsulated gateway and hence is where I point my default route.
* Each of the machines on my Ethernet network have a route:
<pre>
route add -net 44.0.0.0 netmask 255.0.0.0 \
gw 44.136.8.97 window 512 mss 512 eth0
</pre>

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

* I also run my smail, http, ftp and other daemons on the router machine so that it needs to be the only machine to provide others with facilities.
* The router machine is a lowly 386DX20 with a 20Mb hard drive and a very minimal linux configuration.

=== IPIP encapsulated gateway configuration ===

''Warning''

Some information here on tunnelling is out of date. The setup has changed since the 2.0.x kernel, now the "ip" command from the iproute2 package should be used, as described in the Advanced Routing HOWTO.

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

A typical configuration would look similar to the following.

<pre>
. . . . . .
___ _________ .
| Network / \ . Network
| 154.27.3/24 | | . 44.136.16/24 \ | /
| | Linux | . \|/
| | | . _____ __________ |
| eth0 | IPIP | . / \ / \ |
___|_______________| |_____| TNC |____| Radio |___/
| 154.27.3.20 | Gateway | . \_____/ \__________/
| | | sl0
| | | 44.136.16.1
| | | .
| | | .
| \_________/ .
_|_ . . . . . .
</pre>

The configuration files of interest are:

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

and:

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

/etc/ax25/axports

<pre>
# name callsign speed paclen window description
4800 VK2KTJ-0 4800 256 2 144.800 MHz
</pre>

Some points to note here are:

* The new tunnel driver uses the gw field in the routing table in place of the pointopoint parameter to specify the address of the remote IPIP gateway. This is why it now supports multiple routes per interface.
* You can configure two network devices with the same address. In this example both the sl0 and the tunl0 devices have been configured with the IP address of the radio port. This is done so that the remote gateway sees the correct address from your gateway in encapsulated datagrams sent to it.
* The route commands used to specify the encapsulated routes can be automatically generated by a modified version of the munge script. This is included below. The route commands would then be written to a separate file and read in using the bash source /etc/ipip.routes command (assuming you called the file with the routing commands /etc/ipip.routes) as illustrated. The source file must be in the NOS route command format.
* Note the use of the window argument on the route command. Setting this parameter to an appropriate value improves the performance of your radio link.

The new tunnel-munge script:

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

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

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

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

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

=== AXIP encapsulated gateway configuration ===

Many Amateur Radio Internet gateways encapsulate AX.25, [[NET/ROM]] and [[ROSE]] in addition to TCP/IP. Encapsulation of AX.25 frames within IP datagrams is described in RFC1226 by Brian Kantor. Mike Westerhof wrote an implementation of an AX.25 encapsulation daemon for UNIX in [[1991]]. The [[ax25-utils]] package includes a marginally enhanced version of it for Linux.

An AXIP encapsulation program accepts AX.25 frames at one end, looks at the destination AX.25 address to determine what IP address to send them to, encapsulates them in a tcp/ip datagram and then transmits them to the appropriate remote destination. It also accepts tcp/ip datagrams that contain AX.25 frames, unwraps them and processes them as if it had received them directly from an AX.25 port. To distinguish IP datagrams containing AX.25 frames from other IP datagrams which don't, AXIP datagrams are coded with a protocol id of 4 (or 94 which is now deprecated). This process is described in RFC 1226.

The [[ax25ipd]] program included in the ax25-utils package presents itself as a program supporting a KISS interface across which you pass AX.25 frames, and an interface into the tcp/ip protocols. It is configured with a single configuration file called /etc/ax25/ax25ipd.conf.

==== AXIP configuration options ====

The ax25ipd program has two major modes of operation. "digipeater" mode and "tnc" mode. In "tnc" mode the daemon is treated as though it were a kiss TNC, you pass KISS encapsulated frames to it and it will transmit them, this is the usual configuration. In "digipeater" mode, you treat the daemon as though it were an AX.25 digipeater. There are subtle differences between these modes.

In the configuration file you configure "routes" or mappings between destination AX.25 callsigns and the IP addresses of the hosts that you want to send the AX.25 packets too. Each route has options which will be explained later.

Other options that are configured here are:

* the tty that the ax25ipd daemon will open and its speed (usually one end of a pipe)
* what callsign you want to use in "digipeater" mode
* beacon interval and text
* whether you want to encapsulate the AX.25 frames in IP datagrams or in UDP/IP datagrams. Nearly all AXIP gateways use IP encapsulation, but some gateways are behind firewalls that will not allow IP with the AXIP protocol id to pass and are forced to use UDP/IP. Whatever you choose must match what the tcp/ip host at the other end of the link is using.

==== A typical /etc/ax25/ax25ipd.conf file ====

<pre>
#
# ax25ipd configuration file for station floyd.vk5xxx.ampr.org
#
# Select axip transport. 'ip' is what you want for compatibility
# with most other gateways.
#
socket ip
#
# Set ax25ipd mode of operation. (digi or tnc)
#
mode tnc
#
# If you selected digi, you must define a callsign. If you selected
# tnc mode, the callsign is currently optional, but this may change
# in the future! (2 calls if using dual port kiss)
#
#mycall vk5xxx-4
#mycall2 vk5xxx-5
#
# In digi mode, you may use an alias. (2 for dual port)
#
#myalias svwdns
#myalias2 svwdn2
#
# Send an ident every 540 seconds ...
#
#beacon after 540
#btext ax25ip -- tncmode rob/vk5xxx -- Experimental AXIP gateway
#
# Serial port, or pipe connected to a kissattach in my case
#
device /dev/ttyq0
#
# Set the device speed
#
speed 9600
#
# loglevel 0 - no output
# loglevel 1 - config info only
# loglevel 2 - major events and errors
# loglevel 3 - major events, errors, and AX.25 frame trace
# loglevel 4 - all events
# log 0 for the moment, syslog not working yet ...
#
loglevel 2
#
# If we are in digi mode, we might have a real tnc here, so use param to
# set the tnc parameters ...
#
#param 1 20
#
# Broadcast Address definition. Any of the addresses listed will be forwarded
# to any of the routes flagged as broadcast capable routes.
#
broadcast QST-0 NODES-0
#
# ax.25 route definition, define as many as you need.
# format is route (call/wildcard) (ip host at destination)
# ssid of 0 routes all ssid's
#
# route <destcall> <destaddr> [flags]
#
# Valid flags are:
# b - allow broadcasts to be transmitted via this route
# d - this route is the default route
#
route vk2sut-0 44.136.8.68 b
route vk5xxx 44.136.188.221 b
route vk2abc 44.1.1.1
#
#
</pre>

==== ax25ipd.conf variation for use with UDP instead of IP ====
(just the pertinent changes to above for UDP)

<pre>
#
# Select axip transport. 'ip' is what you want for compatibility
# with most other gates ...
#
# Note: the SOCKET statement specifies the overall mode,
# and ALSO the listen port if using UDP.
# port 10093 is considered standard UDP use, but can be any port desired by
# common agreement between all destinations on the specific axip network.
socket udp 10093
#socket ip
#

# above socket definition for UDP must also be reflected below in ROUTING:
# Route statement also specifies the port which must match the destination listen port,
# just in case you have some strange use for asymetrical port assignments.

route t1ni 192.168.254.162 udp 10093
#
route wb5aoh 192.168.254.135 udp 10093
route w5ka 192.168.254.135 udp 10093
route w5tq 192.168.254.135 udp 10093
route kd5rju 192.168.254.135 udp 10093
route aohpms 192.168.254.135 udp 10093
#

# Note that there could be a problem in the parser making it either
# obscure, or maybe impossible, to include the b and/or d flags with
# a UDP specified route. This probably is a loose end bug in the program.
# In my simple applications I haven't found it to be a problem. -WB5AOH-

</pre>

=== Running ax25ipd ===

Create your /etc/ax25/axports entry:

<pre>
# /etc/ax25/axports
#
axip VK2KTJ-13 9600 256 AXIP port
#
</pre>

Run the kissattach command to create that port:

<pre>
/usr/sbin/kissattach /dev/ptyq0 axip 44.135.96.242
</pre>

Run the ax25ipd program:

<pre>
/usr/sbin/ax25ipd &
</pre>

Test the AXIP link:

<pre>
call axip vk5xxx
</pre>

==== Some notes about the routes and route flags ====

The "route" command is where you specify where you want your AX.25 packets encapsulated and sent to. When the ax25ipd daemon receives a packet from its interface, it compares the destination callsign with each of the callsigns in its routing table. If if finds a match then the ax.25 packet is encapsulated in an IP datagram and then transmitted to the host at the specified IP address.

There are two flags you can add to any of the route commands in the ax25ipd.conf file. The two flags are:

; b : traffic with a destination address matching any of those on the list defined by the "broadcast" keyword should be transmitted via this route.
; d : any packets not matching any route should be transmitted via this route.

The broadcast flag is very useful, as it enables informations that is normally destined for all stations to a number of AXIP destinations. Normally axip routes are point-to-point and unable to handle 'broadcast' packets.

=== Linking NOS and Linux using a pipe device ===

Many people like to run some version of NOS under Linux because it has all of the features and facilities they are used to. Most of those people would also like to have the NOS running on their machine capable of talking to the Linux kernel so that they can offer some of the linux capabilities to radio users via NOS.

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

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

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

Once you have chosen a pipe device pair to use you should allocate the master end to you linux kernel and the slave end to the NOS program, as the Linux kernel starts first and the master end of the pipe must be opened first. You must also remember that your Linux kernel must have a different IP address to your NOS, so you will need to allocate a unique address for it if you haven't already.

You configure the pipe just as if it were a serial device, so to create the slip link from your linux kernel you can use commands similar to the following:

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

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

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

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

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