Next Previous Contents

3. Description of the CLX Configuration Files

The CLX configuration files reside in the ~/config directory. Here is where you have to specify your configuration and make changes.

3.1 Obtaining a callsign string

Why an encrypted callsign? Well, we have taken this approach to keep track of who is using our software. That is, if you want to use CLX on the air you need to have a real callsign. This is when you have to contact us. You can install the software, make tests etc. with the default callsign ``XX0XX'' which is encrypted as ``WpbANhEOuh;''.

But then, when you need a real callsign, write an email message to [email protected] sending a screen dump of the startup messages to us. This will be accepted as a proof that you have put some work into the project and are now to be rewarded with a callsign.

How do you do a screen dump? Many people seem to have difficulties with that. So here is what we want: 

$ check   > proof.txt
$ clx -u >> proof.txt

Then mail this file to us, noting which callsign you want encrypted.

Email is also the best way to report bugs and problems and receive support. We use this means of communication because it is very fast and reliable and pretty common in the mean time. Writing letters and sending out disks is too much trouble for us.

As a good resource, you may also subscribe to the CLX mailing list. Thanks to Heikki Hannikainen, OH7LZB, for running the list server for us. If you wish to subscribe, simply send a message to [email protected] with an empty subject. In the message body put the following line: 

subscribe clx

From then on you will be on the list and receive any mail addressed to the mailing list address. Also you may send questions, proposals ideas to [email protected]. If you ever wish to unsubscribe from that list, again send a message to [email protected] with an empty subject line. The message body should contain one line like this: 

unsubscribe clx

Please read the documentation thoroughly before you start to ask questions.

Thanks to Heikki for providing this service for free!

Another good resource is the World Wide Convers Channel 9000 which is often populated with many Clusse or CLX sysops. We used to be on 4791 before but on February 25, 1998 we QSYed to the new channel 9000. If you have a WW-Convers node near you, join channel 9000, which is often entitled: CLX/Clusse SysOPs.

Ian, G0VGS, makes available the CLX Home page at http://www.lurpac.lancs.ac.uk/~clx. This page has links to all the interesting places, where to download the latest CLX, additional sources for databases, beta releases and an archive of the CLX Mailing List. Take a look!

3.2 CLX parameters in ~/config/clx_par

The parameter file is read at the start of CLX. It contains important information about your system configuration like callsign, SSIDs, communication interfaces etc. Please note that syntax checking for this file is almost non-existant. So if you make an error, expect strange things to happen. This hasn't been a problem in the past but please be careful.

These are the syntax rules for clx_par:

There are two types of parameters, that we call variant and invariant. The variant type can be changed at runtime while invariant types cannot. For them to take effect, CLX must be shut down and restarted.

Parameters are:

Here is a simple clx_par file: 

call:           WpbANhEOuh;     # Encrypted callsign
db_name:        clx_db          # name of the clx database
prot:           pc              # protocol type (pc, clx or aut)
hops:           dx/99   ann/10
                user/5  node/10
ssid:           8               # SSID to be used
mk_fwd:         all alle dx dxnews
dx_lim:         60              # no DX spots older than 60 minutes
wwv_lim:        180             # no WWV spots older than 3 hours
waz_ddd:        3 4 5 25        # ignode spots from these WAZ areas
bbs_lst:        db0pv db0aab    # BBS systems for mail forwarding
qsl_rr:         db0sdx/qsl      # remote QSL database fallback

3.3 Cluster network configuration in ~/config/cluster_par

The file ~/config/cluster_par contains information on which callsigns are nodes, which ones have to be actively connected and which ones build up the connect themselves. Additionally, the file contains routing information and of what type of node the system is. Moreover, there is a parameter to denote a link either ``active'' or ``passive''.

This file is similar to the NODES.DAT of the traditional PacketCluster software but it contains a little more information.

The format of this file has changed dramatically in version 4.00 of the CLX software. The name was changed too from ~/config/cluster to ~/config/cluster_par. We tried to make it a bit simpler and get away from the hard-readable link characteristic flags. We hope you appreciate that.

These are the syntax rules for this file:

There are a number of parameters for every single connection described below.

3.4 System messages in ~/config/adv_txt.language

This is the system messages file which may be used in its original form or it can be adapted to your local language. Its function is similar to MESSAGES.DAT of the original PacketCluster software.

The maximum length of the strings contained in every message is 512 characters. This may include \n and other printf-style symbols. You must put this into a single line, however, the message may be structured with additional \n's so the user will receive several lines in a single message.

The following macros are available: 

\call           = User's callsign
\ccntr          = Number of links currently established
\fulldate       = Full Date
\hcall          = User's callsign with here/nohere status showing
\n              = Newline
\ncntr          = Number of nodes reported in the network
\nodecall       = Your CLX callsign
\ring           = Bell character (ctrl-G)
\shrtdate       = Short Date
\since          = Time when CLX was started
\t              = Tabulator
\time           = Current time
\ualm           = The current alarm string (if any)
\ualv           = The current alive character
\uann           = Show if user has ANNOUNCEMENTS ON or OFF
\uansi          = Show if user has ANSI on
\ubeep          = Show if user has BEEP turned on
\uchs           = The character set selected
\ucntr          = Number of users logged in locally
\udxd           = Show if user has DXDEDX activated
\udxf           = list of filters currently active
\udx            = Show if user has DX spots on
\uex            = The current exit string
\ulog           = Show if user has Login/Logout messages on
\umax           = Maximum number of users logged in since last start
\uptime         = Uptime in days, hours, minutes and seconds - format 
                  string in adv_txt message 011.
\version        = CLX version number

Some message numbers have flags. These have the following meaning: 

*       This message only goes to the error log. It is always
        taken from adv_txt so there is no reason to translate it.

?       This message will not be displayed if there is no
        text.

The translated adv_txt files must be located in the ~/config directory and be named adv_txt.language. We have included several language files in this directory. adv_txt is a fallback file, which is used in case no specific language file is available or if the message number is marked with an asterisk. When the user has not specified any language, the file adv_txt.default is used. This should be a symbolic link to the language normally used on your system. If the user has specified a different language with the set/language command, then the file adv_txt.language is used.

Please check the files for completeness and send any corrections of it back to us to be included with future releases of CLX! Again, note that the messages having an asterisk are internal messages only and are always taken directly from adv_txt.

When you are translating or adapting a message file, it is convenient to have both the original and the translated messages near each other so that you can make a comparison. For this, we have included a tool called check_adv_txt in the ~/tools directory. Use this tools as follows: 

$ cd ~/config
$ check_adv_txt adv_txt.italian

With the command line switch -m you can force it to show only messages which are missing in the translated file.

3.5 Location data in ~/config/wpxloc.raw

The file ~/config/wpxloc.raw originates from the PacketCluster software and contains a huge number of detailed location information for different DXCC countries, islands states and regions of the earth.

The synax of this file is as follows: 

    ---------+-----------------------------------
      Column | Meaning
    ---------+-----------------------------------
           1 | Prefix or Prefixes
           2 | Full Country Name
           3 | DXCC country number
           4 | ITU zone
           5 | CQ zone
           7 | Time zone (negative means east)
        7-10 | Latitude (South is negative)
       11-14 | Longitude (East is negative)
          15 | Follow up flag (* - optional)
          16 | DXCC country flag (@ - optional)
    ---------+-----------------------------------

Comment lines are starting with !.

So the file looks like this: 

!Updated many times by DJ3IW, DK2OY, DB0SPC 1991,1992,1993,1994,1995
!
1A S.M.O.M.-1A           268 28 15 -1.0   41 54 0 N 12 24 0 E     @
1B NoDXCC-(illegal)      288 39 20 -2.0   35 0 0 N 33 0 0 E
1S Spratly-Is-1S         269 50 26 -8.0   8 48 0 N 111 54 0 E     @
3A Monaco-3A             270 27 14 -1.0   43 42 0 N 7 23 0 E      @

As many grown-up PacketCluster Sysops have put considerable work into maintaining this file, CLX continues to use this data in the SHOW/SUN and SHOW/HEADING commands. However, the data is converted into a slightly different form and then called ~/config/location.dat at the startup of CLX. ~/config/location.dat has the following format: 

    ---------+-----------------------------------
      Column | Meaning
    ---------+-----------------------------------
           1 | Prefix
           2 | Full Country Name
         3-5 | Latitude
         6-8 | Longitude
           9 | Time zone
    ---------+-----------------------------------

Whenever ~/config/wpxloc.raw is changed, however, ~/config/location.dat will be created anew. There is nothing you need to do about this, excepct adding new countries and regions from time to time if you so desire. Do not touch ~/config/location.dat as this will is generated automatically.

3.6 Special Characters in System messages and Help Files

CLX understands national characters and is able to transmit them depending on your character set. You must code the special characters according to the ISO 8559 conventions, that is ä for the letter ä etc. This should be familiar to everyone writing HTML code.

The special characters CLX understands are defined in the file ~/config/char_set. In that file the corresponding character codes for the different character sets available must also be specifed. Currently we have four, the Latin-ISO (used by Linux and MS-Windows), IBM (used by MS-DOS), DIN (which is using the rare characters {, }, |, [,],\ and ~ for national character encoding --- Baycom used this convention) and one with uses ASCII transcription.

Currently, the system messages in ~/config/adv_txt.default (which is a link to your default language file), the output of external programs and the help files will be transposed.

To switch languages, users may use the SET/LANGUAGE command, to switch character sets use SET/CHARSET. For more help take a look at the user help files.

3.7 Message of the day or ``notice''

CLX allows setting of a so-called "Message of the Day". This message is displayed to every user logging into the system. This feature makes it possible to announce meetings or special events to the users in a convenient way.

To enter a new message of the day, you should use the following commands: 

set/motd

    Now enter the new message

/exit

A new file motd gets created in the ~/box/info/etc directory.

It is possible to automatically set the MOTD with a program which is being called through cron every day at 00:01 UTC. An example of such a program is in the mk_motd script in the ~/tools directory. This script calculates the date of the regular DX meetings of the B.C.C. in both Nürnberg and München and sets the appropriate message. This way, club members are reminded well before the meeting happens. Feel free to expand this script to make it useful for you. Some time in the future, I will make a more general tool - currently all is pretty hard-coded in that file.

New users, who have not logged in any time before optionally are displayed the file ~/box/info/etc/motd_new if it exists. A new user is a user without a record in the database.

3.8 CLX unavailable

To inform your users of the node being temporarily unavailable, there is a file which is displayed when net_usr does not find CLX running. First, net_usr tries to find $HOME/config/clx_etxt, then /usr/local/etc/clx_etxt. If both fails, it will display the message clx unreachable.

Also users coming in via the clx daemon clxd (TCP/IP) will be sent this message when CLX is down.

3.9 Multiple Connects

A word about multiple connects: CLX accepts multiplie connects from the same callsign using different SSID's. In a CLX Cluster you may connect each of the single nodes using the same callsign (even the same SSID). However, connecting the same node twice with the same callsign is not possible. CLX is using the callsign as a communication channel identifier. What will happen, whenn you're connected as, let's say DL6RAI, and start up another session as DL6RAI? The old DL6RAI will receive the greeting message, the new DL6RAI will receive nothing. All commands he enters are answered to his first connection. And when he tries to log out, the nr. 1 connection is terminated.

3.10 Amateur Band Boundaries

Amateur band boundaries are defined in the ar_band database table. This information may change or may be different in your country. Make the appropriate corrections to the file ~/config/ar_band.cd and then issue the following command (as clx_us, with postmaster running): 

$ db_maint a

You may also add new modes and frequency boundaries. You must then follows these rules:

3.11 Configuring the AX.25 software

With the AX.25 utils after version 2.0.12, some changes were necessary from previous versions. Where CLX used to communicate directly with the kernel drivers, we have now ax25d as a super daemon launching applications such as axspawn, a personal messages system or --- in our case --- net_usr to connect to CLX. Please follow the instructions coming with the AX.25 utils package.

Using a KISS serial port

For a simple and plain CLX installation the following steps should be necessary:

  1. edit /etc/ax25/axports and put your callsign for outgoing connects there. Give the interface a name which you will refer to later. I called mine ``kiss''.
  2. edit /etc/ax25/ax25d.conf and put the following lines in it: 
    [kiss]
parameters   1 10   *   * *  0
default 7 10 2 900 * 15 - clx_us /usr/local/clx/bin/net_usr net_usr -x %s
    This boils down to: Whenever someone calls DL6RAI-7 on interface [kiss], start the program /usr/local/clx/bin/net_usr with the switch ``-x'' (which converts CR/LF) and his callsign including SSID as a parameter. The process is started under the UID of clx_us.
  3. Make a startup script in /etc/ax25 which is called when your system boots. My ax25startup looks as follows: 
    #! /bin/sh
set -x
echo -e "\015\015\033@K" > /dev/tnc
/usr/sbin/kissattach /dev/tnc kiss
/usr/sbin/ax25d -l
sleep 3
/usr/sbin/kissparms -p kiss -t 150
    The echo command switches my TNC into KISS mode. Then kissattach is being started on the TNC device. Then ax25d is started with the ``-l'' option which makes the AX.25 daemon send log messages to syslog. Then we must wait a little before changing KISS parameters with kissparms as was necessary here (TX delay). Also I have a script for shutting down the AX.25 programs: 
    #! /bin/sh
set -x
kill `/bin/ps aux | awk '/n\/ax25d/ {print $2}'`
kill `/bin/ps aux | awk '/n\/kissattach/ {print $2}'`
echo -e "\300\377\377\377\300" > /dev/tnc

Using AX.25 over Ethernet

Another way to use the AX.25 software is with the BPQ encapsulation. This allows us to send AX.25 packets via Ethernet and is compatible to Flexnet's ETHER.EXE module from DK7WJ (which additionally requires a packet driver) and probably software from G8BPQ. For this to work on the Linux side, you just add another line in the /etc/ax25/axports file looking like this: 

[ether]
ether           DB0CLX-1        19200   255     4       ethernet

Additionally, you must configure the ethernet port, in most cases eth0: 

# /usr/sbin/axparms -dev eth0 ether

And in the /etc/ax25/ax25d.conf file we should add the port ether to the configuration: 

[ether]                                                                         
NOCALL   * * * * * *  L                                                         
default  * * * * * *  - clx_us  /usr/local/clx/bin/net_usr net_usr -x %s

Now we can connect the CLX port DB0CLX-1 via ethernet.

3.12 WAMPES and CLX

Installing real WAMPES

At this point in previous releases of the CLX software, we had a chapter on how to get, compile and install WAMPES. We felt that this information was slightly outdated now. So we left it out. If you really have to use WAMPES for one reason or another, you will probably know better how to install it.

To make CLX run with WAMPES, you only specify one key word in the clx_par file, that is: 

wampes:

You may, if desirable, specify a port number after the colon. This will allow you to change the port number which CLX uses for communicating with WAMPES. The default WAMPES port is 4718 and need not to be specified.

It is also possible to specify a WAMPES host if your WAMPES installation is running elsewhere. For this use the keyword 

w_host:

in the clx_par file.

Due to WAMPES' philosophy, SSIDs are not reported down (or up?) to the application running on it. Due to this, when using WAMPES, node callsigns must be unique, there is no way to have DJ0ZY be a normal user and DJ0ZY-7 a CLX node. This is true only for incoming connects. When going out through WAMPES, you can chose any SSID you like.

This also leads to the problem that users' SSIDs are generally ignored and you cannot be connected to two adjacent nodes which have a link between them using the same root callsign.

This is a WAMPES ``feature'' and cannot be changed by CLX.

Using TNT's WAMPES socket feature

TNT, written by DL4YBG, is a very convenient packet hostmode program for Linux. New versions are available from http://www.snafu.de/~wahlm TNT runs on the Linux console as well as in an xterm under X11. One of the features of TNT is its ability to provide a WAMPES compatible socket interface for outgoing connects. This feature is also known as TNT's NETCMD interface. Along with the autostart feature, which makes TNT automatically start an application when a specific SSID is being connected from outside, TNT can be used as both an interface and a control terminal for CLX.

To enable CLX operation via TNT, you must specify the following two lines in the tnt.up file which is executed when TNT starts up: 

socket netcmd *:4718 dl6rai-7
autostrt on

The first line makes TNT listen on port 4718. If a connection is made, the application may use the command ``connect ax25 db0aab'' for example to establish a connection to DB0AAB. You can check this out yourself by simply doing a ``telnet localhost 4718''.

The second line enables the autostart feature for incoming connects. If --- for example --- the channel with the callsign DL6RAI-7 is being connected by DK2OY, TNT will set the environment variable $CALLSSID to dk2oy and spawn a shell running the script clx_sh. For this you create a file called autostrt.tnt in the TNT directory and add the line: 

dl6rai-7 run clx_sh

to it.

The file clx_sh is a shell script located in .../tnt/bin (or whichever is defined as the TNT run_dir) which should contain the following two lines: 

#!/bin/bash
exec /usr/local/clx/bin/net_usr ${CALLSSID}

Also you must have some channels programmed with that very callsign you like to use. You can do that by putting several lines like 

channel 1
mycall dl6rai-6
channel 2
mycall dl6rai-6
...

into your tnt.up file.

All of this is a little confusing. Again, these are the steps you have to do:

  1. Make TNT listen on a socket port
  2. enable the autostart feature
  3. Create autostrt.tnt
  4. Create a script called clx_sh in TNT run_dir (default: .../tnt/bin)
  5. Have some packet TNT channels programmed with the callsign you want to be connectible under

When using the w_host variable in clx_par and setting the $CLX_HOST shell variable or calling net_usr with the ``-h'' switch on the remote host, you might even have CLX and TNT running on different machines. DG4MMI reports that he got TNT and CLX running this way very nicely. DL1RF reported good success with TNT 1.1a3, DPBOX and CLX 2.07 all running on the same machine. net_usr is a statically linked program, it only needs libc.so.5. So the program may be used on a different computer.

The advantage of TNT+CLX is that you get control over each communication channel as you can see what's going on by switching TNT channels. You may watch the PC-PC communication going on or you can see how and why routing scripts work or fail. Generally it gives you more control over your CLX installation and makes it more transparent.

Thanks to DL4YBG for making this feature available!

DL4YBG has slightly extended the WAMPES socket interface so that after the target callsign, one can specify the source callsign to be used on an outgoing connect through TNT.

The new syntax is as follows: 

CONNECT <transport mode> <destination callsign> [source callsign]

If no source callsign is specified, the default callsign is taken from the NETCMD interface.

Additionally, when starting an outgoing connect via this interface, TNT uses its own routing table and after establishing the connection activates the socket interface. As a side note, this also automatically changes the source callsign of a AX.25-connection with this callsign already exists to the destination. So you just need not care about it at all.

The setup of the routing file (routes.tnt) is a little tricky. You must make sure that the destination callsign again shows up with a T> tag at the end, like in the following example: 

T>DB0SUE-7 CLX; F>db0aab N>db0bro N>db0il T>db0sue-7

If it doesn't, then CLX will never receive the final connect message and the connection will not be established. When setting this up first, try making a connect manually using :XCONNECT and watch the upper status line switching to the destination callsign when that is reached. In the above case it should look like this: 

Ch:05 Stat: IXF wid DB0SUE-7

3.13 Making CLX access available through telnet

With version 2.03 a new program clxd was included with the CLX software. This perl script allows you to connect directly to CLX via telnet (without first having to log in). This is achieved by putting the following entry into /etc/inetd.conf: 

clx stream tcp nowait root /usr/sbin/tcpd /usr/local/clx/bin/clxd clx

Also you must add to your /etc/services file something like this: 

clx             41112/tcp               # CLX Login

To make it really work, you must create an emtpy file called passwd in the directory ~/config: 

$ touch ~clx_us/config/passwd

This is all what you have to do. Now you must kick inetd to make it read its configuration file: 

# ps aux | grep inet
root       109  0.0  0.4   832    68  ?  S   12:27   0:00 (inetd)
# kill -1 109

Users can now log in via port 41112 with the command: 

$ telnet <your hostname> 41112

This is what will happen: 

Trying 192.0.0.2...
Connected to al7nj.
Escape character is '^]'.
Welcome at the clx gateway - you logged in from 192.0.0.1/1028.

Now you must enter your callsign. If you log in for the first time (i.e. ~/config/passwd contains nothing), a new password will be asked for. 

Enter new password:
Reenter password:

So a new entry is created in the passwd file. Otherwise you must enter the password which was used previously. 

Password:

The echo will not be suppressed so be careful when someone is watching you. I did not figure out how to do this in a clean way. However, the program tries to make sure that a valid amateur callsign is being used for login: 

Your callsign: wrdfl
Callsign invalid.
Your callsign:

The passwd file contains four fields, separated by colons. It contains callsign, password (encrypted), the IP address from where the connect was made and date/time of the first login. 

dl6rai:wroX0dhQ.42t:192.0.0.2/1044:27-Feb-96 2023z
df2rg:wr9y/v96xsF9:192.0.0.1/1029:29-Feb-96 1640z

This is a very rudimentary security check and we do not recommended that you put this on the Internet right away.

After successfully logging in, you will be treated like any other normal user. You can talk, you receive DX spots etc. There is no difference between normal users and users coming in via telnet.

In fact, you can also use this feature to provide an incoming node connection. You would need some interface to get over the login mechanism however. This could be done by a connect script described in section Connect Scripts.

As a special rule, clxd turns off the telnet echo when a known node callsign connects. This avoids problems due to reflected PC10 frames (looping talk messages) and circulating mail.

3.14 Using CLX with TNOS

CLX can be used with TNOS. The following information was received from Joni Bäcklund, OH2NJR and Andrea Fiorentino, N5KME/I0:

OH2NJR: ``I just don't see any reason to use TNOS with ax25 kernelcode anymore. With the latest ax25 kernel (2.0.30 with module13 and latest ax25 utils) I can do everything that TNOS does and save about 1.5MB of memory at the same time.''

The thing was done by attaching an ax25 kernelport to a pseudo ax25port on TNOS and then connecting the real TNC into another port in TNOS. Then we only had to use the rxecho command with TNOS to copy pakets from Linux's TNOS port to the TNC-TNOS port and vice versa. This was the way I used TNOS and Linux/CLX.'' 

+-----------------------------------+
|         linux kernel              |
| ax25 kernel port (CLX ax25 port)  +--------------+  /dev/ttypf
+-----------------------------------+              |
                                                   |    pseudo serial
                                                   |    connection
+-----------------------------+                    |
|                             |    TNOS port 1     |
|     TNOS with 2 ports       +--------------------+  /dev/ptypf
|       "rxecho" used         |                   
|       for kissbridge        +--------------------O  TNC port
|                             |    TNOS port 2
+-----------------------------+

It is done by using pseudo TTYs as ``wired serialports''. The kernel uses /dev/ttypf, TNOS uses /dev/ptypf to connect the kernel and after that TNOS uses another port for the KISS TNC etc. Take a look at OH2RBJ's current setup at http://www.clinet.fi/~njr/rbj.html

Here is some information frm I0/N5KME:

  1. attach a pseudo kiss device with kissattach: 
    kissattach /dev/ptypf link
    link is defined in /etc/ax25/axports as: 
    # <port name> <call> <speed> <paclen> <window size> <description>
link     N5KME-6 38400    255          7        clx <-> tnos
    Note that the call must be the same as in CLX
  2. configure clx for the correct device and speed in ~/clx_us/config/clx_par: 
    tnc_dev:      /dev/ptypf
tnc_baud:     38400
  3. configure in TNOS the link with CLX in the file autoexec.nos add: 
    attach asy ptypf - ax25 clx 2048 1024 38400
  4. Make the CLX port see everything a real radio port sees. My radio port for the PacketCluster link is named uhf. 
    ifconfig clx rxecho uhf

    ifconfig uhf rxecho clx
    Note: Only one radio port can be rxechoed or the CLX link will see a tremendous confusion.

3.15 Connect Scripts

To make establishing node connections under CLX very flexible, we included a connect script feature as a means to improve outgoing links to other nodes and sources of DX information. The concept is built around a program (which may be written in any language) which establishes a connection to a remote node and then, when the connection is established, switches into transparent mode. CLX uses pseudo TTYs as an interface to the scripts.

We have found the Expect package from Don Libes (available on the Internet on any Sunsite mirror in the directory /devel/lang/tcl) to be an ideal platform for such scripts as it already contains a great number of pattern matching functions and through its interact command is able to keep the connection alive after the script is done.

I downloaded the Expect package from ftp://ftp.leo.org/pub/comp/os/linux/sunsite/devel/lang/tcl/expect-5.18bin.tgz. Nowadays, Expect is usually available as part of the Linux distrubition and normally installs under /usr/bin.

Mike Sims, KA9KIM, who installed Slackware 3.5 in October 1998 reported that the version mentioned above is kind of old. Presently, the expect package is located at the expect.nist.gov web site. However, the newest version also needs Tcl version 7.4 which is also not included with that distribution so he had to get the Tcl 7.4 sources too and then recompile the expect package.

The conditions for the external programs building up the connection are simple and straightforward: After being called from CLX the program must either exit if the connection cannot be established, or the first line of text coming back through is understood as a successful connect.

Let's look at some examples which we have tested.

Shell Scripts as Connect Scripts

The first approach is a two-liner Bourne shell script. It uses the program call from the AX.25 utilities to establish the connection to F6KNL-3. This example was worked out together with Lucien Serrano, F1TE, to connect to F6KNL-3 via F6KNL-9 and a Rose node. The script is very simple, it does not even require Expect as there are just two commands: 

#!/bin/sh
read $something
/usr/bin/call -r ax0 f6knl-3 f6knl-9 833501

This script is a plain shell script as you an see in the first line (the #!/bin/sh means to the shell: start the program /bin/sh and then feed it with the rest of this script). The read command is necessary because CLX will send the string ``connect ax25 f6knl-3'' to the script after its start and this should simply be dropped and not screw up the next program or the remote node.

However, in a more general script you could make use of this information. With CLX version 4.00, the script receives command line parameters so now it is possible to provide you with a connect script for all occasions: 

# These parameters are taken from the command line
PROG=`basename $0`
MYCALL=$1; shift
PORT=$1 ; shift
DIGILIST="$*"

# Now we go process the 3rd parameter from STDIN
read conn
set -- $conn
logger -p local5.info "$PROG: /usr/sbin/ax25_call $PORT $MYCALL $3 $DIGILIST"
stty -echo raw
exec /usr/sbin/ax25_call $PORT $4 $3 $DIGILIST

The script is called with the outgoing callsign as the first parameter, followed by any additional parameters in the conn_path: entry for that destination.

After the script has started, it receives a line from con_ctl specifying the destination call as the third and optionally the outgoing callsign as the fourth parameter. So if the file ~/config/cluster_par contains these lines 

SECTION:        db0bcc
conn_call:      dl6rai-7

then con_ctl will in fact send the string 

connect ax25 db0bcc dl6rai-7

to the connect script.

These scripts work well in reality and are pretty straightforward and simple to understand. They have some disadvantages though:

Using TCP/IP for a connect

A rather elegant usage of net_usr allows linking CLX nodes via TCP/IP. net_usr has the -h option to allow specifying a CLX host. So net_usr -h al7nj dl6rai-7 will start a connection to CLX running on al7nj. So taking the same configuration as above, a simple script to connect another CLX node via TCP/IP would look like this: 

#!/bin/sh
read conn
set -- $conn
net_usr -h $3 $4

This assumes that the callsign you are connecting to (al7nj) is also a known IP hostname (by having it in your /etc/hosts for example).

A simple Expect Script

Here is another example, a little more complicated as it involves several steps. As a first step it connects DB0AAB and then tells DB0AAB to setup a link to DB0BCC. Finally the program goes into transparent mode with the command ``interact''. If either the first L2 or the L3 connect fail, the program aborts (``exit 1'' in the code). In the first line again you can see that an interpreter is called, this time the program /usr/bin/expect with the flag ``-f''. 

#!/usr/bin/expect -f
#
# Routing through Kernel AX.25
#
    
# --------------------- User configurable ---------------------
set digi db0aab
set port kiss
set destination db0bcc
set l2_timeout 10
set l3_timeout 30
# --------------------- User configurable ---------------------

set timeout 0
log_user 0

set timeout $l2_timeout

spawn /usr/bin/call -r $port $digi
expect "***Connected"

expect timeout { 
        send_user "\n### timed out waiting for '=>'\n" 
        exit 1
} "=>"
send "c $destination\n"

set timeout $l3_timeout
expect timeout { 
        send_user "\n### timed out waiting for '*** connected to'\n" 
        exit 1
} "*** connected to"

send_user "*** connected to $destination\n"
interact

Of course, the parameters in this file can be left out as you can specify them in the configuration file. Let's look at another more complicated script.

A more sophisticated Script

Here we dial up an Internet connection through cu, login, telnet across the Internet and login at the remote clxd port. We have not tested this script, so it may or may not run. But we hope you get the idea behind it. 

#!/usr/bin/expect -f
#
# Routing through cu, telnet
#

set timeout 60
log_user 0

# Use cu to dial up my Internet Service Provider
spawn /usr/bin/cu isp
expect timeout { 
        send_user "\n### timed out waiting for 'Connected.'\n" 
        exit 1
} "Connected."

# Unix Login
send "\n\n"
expect timeout {
    exit 1
} "ogin:"
send "name\n"
expect timeout {
    exit 1
} "sword:"

# Wait for shell prompt
send "MyPaSsWoRd\n"
expect timeout {
    exit 1
} "\$"

# Now telnet to my partner's clxd port
send "telnet 193.0.23.245 41112\n"
expect timeout {
    exit 1
} "Your callsign: "

# Login at the remote clxd
send "xx0xx\n"
expect timeout {
    exit 1
} "Password:"
send "my_login_passwd\n"
expect timeout {
    exit 1
} "*** connected to clx"

# OK, we're done
send_user "*** connected to $destination\n"

# Transparent mode
interact

A virtual one-way connection

As a last example, think of a program which does nothing else but listen to an AX.25 channel where PacketCluster spots are being transmitted. On a busy channel, some DXers are always maintaining a connection to some PacketCluster system. Or you could have a listen on 14.096 MHz where some PacketCluster activity is going on. Just imagine such a program as an interface to CLX. From within CLX you would simply configure this as a ``virtual'' connection to another node.

The program /usr/bin/listen from the AX.25 utils package allows us to listen to the different ax25 ports. With the ``-r'' option it outputs the monitored frames in a readable form which can then be scanned for any DX spots. Here is the script: 

#!/usr/bin/expect -f
#
# Listening on my radio port for spots
#

log_user 0
set timeout -1

spawn /usr/bin/listen -r

while (1) {
        expect -re "\[^\n]*DX de .*\[^\n\r]" {
                send_user "$expect_out(0,string)\n"
        }
}

This simply starts the program /usr/bin/listen and goes into filter mode. The complicated looking expression 

\[^\n]*DX de .*\[^\n\r]

is nothing else but a definition for a DX spot in expect's regular expression form.

For more information about expect, I recommend reading the book ``Exploring Expect'' from Don Libes, O'Reilly & Associates, Inc., ISBN 1-56592-090-2 available at any good computer book store.

Think of other ideas like this:

3.16 CLX and Callbook Data

Several interesting address sources are available on CDROM as well as on-line on the internet. Buckmaster Publishing was first to provide access for the Pavillion software to their address database. CLX does support the QRZ! Hamradio CDROM, the International (Flying Horse) Callbook CDROM and also a free data format into which you can configure your data.

The QRZ! Hamradio CDROM and other callbook data

From version 2.00 CLX allows you to use any callbook data available on your system. This feature enables you to directly access the QRZ! Hamradio CDROM from Walnut Creek (AA7BQ) and also your own data files if they are supplied in one of two data formats.

A new directory ~/callb must be created. This directory may contain any further subdirectories with callbook data. The data in this directory must comply with one of these formats:

  1. Sorted by suffix: 
    AA0A  ,Name...,,,,
AB0A  ,Name...,,,,
AC0A  ,Name...,,,,
AD0A  ,Name...,,,,
... 
AA1A  ,Name...,,,,
AB1A  ,Name...,,,,
...
AA0AA ,Name...,,,,
AB0AA ,Name...,,,,
AC0AA ,Name...,,,,
...
K 0AA ,Name...,,,,
K 1AA ,Name...,,,,
K 2AA ,Name...,,,,
...
  2. Sorted alpha-numerically: 
    AA0A  ,Name...,,,,
AA0B  ,Name...,,,,
AA0C  ,Name...,,,,
AA0D  ,Name...,,,,
...
AA1A  ,Name...,,,,
AA1B  ,Name...,,,,
AA1C  ,Name...,,,,
...
AA0AA ,Name...,,,,
AA0AB ,Name...,,,,
AA0AC ,Name...,,,,
...

Missing characters are replaced by blanks. Fields are separated by commas. The sort type is indicated by file name. 

<name>.s     sorted by suffix
<name>.c     sorted alpha-numerically

No other formats are available at this time. More to be done in the future.

Any available sources are supplied in the clx_par file. With the callb parameter you may specify any number of directories to search for callbook address information. The software searches each directory until the requested address is found. Then it stops. This way you may have directories with descending priority, for example a local directory where you put in very reliable information and as a second source the CDROM information. If the information is found in the local directory, the (probably wrong) information on the CDROM is not shown to the user.

There may be any number of files in the ~/callb/* subdirectories. The information must be mutually exclusive, i.e. you cannot have two files with Italian addresses in the same directory. This must either be in a single file or in two different directories.

CLX creates two index files in each subdirectory, one for the suffix oriented files and another for the alpha-numerically sorted files. These index files are being created when starting CLX. The indexing runs in the background so it might take a few minutes before you can access the data after the first start.

Whenever information is changed in these directories, CLX will realize that something has changed and rebuild the index files. The index files are named clx_idx.s and clx_idx.c. Their size is approx. 200 kB each.

The files may not be in that directory physically. It is OK to make symbolic links to the physical files, thus allowing you to keep your CDROM mounted under /cdrom or whatever.

Example:

You have two directories under callb: 

local
qrz_dx

local contains any local addresses, probably gained and converted from a club's roster, your private address database or something. So there is only a single file in local, named address.c. This file must be sorted alpha-numerically.

The qrz_dx directory contains a link to the QRZ! Hamradio CDROM mounted under /cdrom: 

all.s -> /cdrom/callbk/callbkc.dat

You can even keep the files on a different machine and mount them via NFS. We have put a sample file under ~/callb/local which is named bcc.c. It contains some entries from the BCC's club roster. This file will be used by CLX if you specify the directory 

callb:  local

in the clx_par file.

The user command to access the information is show/callbook. This is an internal command and it cannot be changed. The show/address command which was used here before is now free for your own database, probably importing from a PacketCluster .ful file (see also read-ak1a).

The Flying Horse CDROM Callbook

The data on the Flying Horse CDROM Callbook is provided through the use of a DOS program named calldos.exe. This program and a little Expect script is used to gather the data from the CDROM. To get this working, you must first get the DOS emulator going, preferrably by reading the supplied documentation and the DOSEMU-HOWTO document, available, for instance, from http://sunsite.unc.edu/mdw/HOWTO/DOSEMU-HOWTO.html.

You must be able to start the DOS Emulator and access the Callbook data from a drive letter. This drive letter must be defined in the CLX configuration file clx_par. Additionally, no printer must be defined in DOSEMU, as the program supports only LPT1: and we need to send its data to a file.

If all is working well, you could try running the program first from the clx_us shell prompt: 

$ ~/exec/command/show/cba dl6rai dk2oy

and you should get: 

Manfred Petersen, DK2OY
Hardtstr. 83
D-40629 Duesseldorf
Germany

The user command to access the Flying Horse callbook data is SHOW/CBA.

Using online address data from the Internet

Thanks for Matthew George and Erik Olson there another script is provided in the ~/exec/command/show directory allowing online access to Internet address data directly from www.qrz.com. You must have a continous Internet connection. The script is provided ``as is'', I have not tried it here but it is used in a production mode at NC7J. The script is named cba.internet and to make it easy for your users, you should rename cba to cba.cdrom and cba.internet to cba.

Next Previous Contents