The release notes are no longer in this manual. Please look for the files
called README_* in the ~/doc/sysop directory.
The following list comes from the original PacketCluster documentation. These are the messages used among PacketCluster and CLX nodes. Thanks to OE1TKW for originally collecting this information:
Internode communication between PacketCluster nodes is performed
by sending Information packets that begin with the string
``PC'', followed by an ACSII coded number between 10 and (currently) 51.
PC10 Talk mode
PC11 DX info
PC12 Announcement
PC13 Stn into CONF
PC14 Stn out of CONF
PC15 Conference mode
PC16 PC stn add
PC17 PC stn delete
PC18 Initialisation: RequestInit
PC19 Initialisation: NodeAdd
PC20 Initialisation: InitDone
PC21 Initialisation: NodeDelete
PC22 Initialisation: PCDone
PC23 WWV Info
PC24 Here status info
PC25 DX/WWV merge request
PC26 DX merge info
PC27 WWV merge info
PC28 mail: SendSubject
PC29 mail: SendText
PC30 mail: AckSubject
PC31 mail: AckText
PC32 mail: CompleteText
PC33 mail: AckCompleteText
PC34 Remote commands: Command *
PC35 Remote commands: Response *
PC36 Remote commands: Show command
PC37 Needs database update
PC38 Connected node list
PC39 NodeDelete w/disc
PC40 PC file forward
PC41 User info
PC42 Forwarding abort
PC43 PC-mail: External mail, Send subject
PC44 Remote DB request
PC45 Remote DB response
PC46 Remote DB complete
PC47 Remote DB update
PC48 Remote user DB update
PC49 Bulletin mail delete
PC50 Local user count
PC51 Ping request or answer
*) PC34 and PC35 are PC84 and PC85 for CLX-to-CLX remote commands.
PC10^from-stn^to-stn^msg^bell-flag^to-stn^from-pc^~
PC11^DXfreq^DXcall^DXmisc^Date^Time^logger^from-pc^hops^~
PC12^from-stn^to-PC^msg^sysop-flg^from-pc^wx-flg^hops^~
PC13^stn^hops^
PC14^stn^hops^
PC15^from-stn^msg^hops^
PC16^host^stn conf-mode here^stn conf-mode here^stn conf-mode here^...^...^hops^
PC17^stn^from-pc^hops^
PC18^cluster-info^ver^~
PC19^here^PC-stn^talk^version^hops^
PC20^
PC21^PC-stn^reason^hops^
PC22^
PC23^date^hour^SFI^A^K^forecast^logger^from-pc^hops^~
PC24^stn^here^hops^
PC25^merge-stn^from-stn^DX-cnt^WWV-cnt^
PC26^DXFreq^DXCall^date^time^info^logger^to-stn^~
PC27^date^hour^SFI^A^K^forecast^logger^to-stn^~
PC28^to-pc^from-pc^to-stn^from-stn^date^time^private-flag^subject^~
PC29^to-pc^from-pc^msg-#^text^~
PC30^to-pc^from-pc^msg-#^
PC31^to-pc^from-pc^msg-#^
PC32^to-pc^from-pc^msg-#^
PC33^to-pc^from-pc^msg-#^
PC34^to-pc^from-pc^cmd^~
PC35^to-pc^from-pc^cmd-resp^~
PC36^to-pc^from-pc^cmd^~
PC37^to-pc^from-pc^stream^command^~
PC38^node,node,node,...^~
PC39^stn^reason^
PC40^to-pc^from-pc^filename^bull-flag^line-cnt^
PC41^stn^type^info^hops^~
PC42^to-pc^from-pc^msg-#^
PC43^to-pc^from-pc^to-stn^date^time^private-flg^subject^line-cnt^~
PC44^to-pc^from-pc^stream^qualifier^key^user^
PC45^to-pc^from-pc^stream^info^~
PC46^to-pc^from-pc^stream^
PC47^to-pc^from-pc^user^qualifier^key^stream^type^
PC48^to-pc^from-pc^stream^qualifier^key^user^
PC49^stn^subject^hops^~
PC50^from-pc^usercnt^hops^
PC51^to-pc^from-pc^ping^
Legend
======
logger station that reports the info
bell-flag 1=bell, 0=no bell
merge-stn node that provides the info
DXCall DX station call
msg message text
DXFreq DX station frequency
PC-stn PacketCluster node
DXmisc DX misc text
stn Call of connected station
from-stn originating station
conf-mode *=conf, -= no conf
here 1=here, 0=no here
to-stn destination station
host Packet Cluster node call
ping 1=request, 0=answer
This is a table of PCxx messages which are currently handled by
the CLX software.
Msg process generate forward note
----------------------------------------------------------
PC0 error - - dj6rx
PC10 + + +
PC11 + + +
PC12 + + +
PC13 - - -
PC14 - - -
PC15 - - -
PC16 + + + 1)
PC17 + + + 1)
PC18 + +
PC19 + + + 1)
PC20 + +
PC21 + + + 1)
PC22 + +
PC23 + + +
PC24 + + +
PC25 + + +
PC26 + + +
PC27 + + +
PC28 + + +
PC29 + + +
PC30 + + +
PC31 + + + after 9999 lines
PC32 + + +
PC33 + + +
PC34 - - -
PC35 - - -
PC36 - - -
PC37 - - -
PC38 - -
PC39 + + -
PC40 - - -
PC41 + + -
PC42 - - -
PC43 - - -
PC44 + + -
PC45 - + +
PC46 - + +
PC47 - - -
PC48 - - -
PC49 - - -
PC50 + + -
PC51 + + +
----------------------------------------------------------
Notes:
+ means CLX processes this request.- means CLX ignores this request.The field forward has two meanings:
1) means: Due to compatibility issues with the Pavillion software,
this message is not being forwarded to a PacketCluster node.
This list has grown too big. Please refer to the file
/usr/local/clx/doc/misc/user.db for information
about current users of the CLX software.
Email addresses shown with an initial # did not work, so they
are probably out of date.
Numerous people have helped out with information, details, bug reports and other useful things in the years of the CLX development. Most of our communication was carried out via the Internet, some by Packet Radio. Thanks to all of you for your help, especially to:
Alan Cox, GW4PTS for putting the AX.25 code into the kernel
Jonathan Naylor, G4KLX, for maintaining the AX.25 code
Harm, DG7DAH for helping us with WAMPES configuration
Joni Bäcklund, OH2RBJ for lots of feedback, ideas and documentation
Christian Blattnik, DC0JI for providing a place for DB0CLX
Brigitte Blattnik, DH3MBJ for supporting DJ0ZY, DL6RAI and DC0JI
Robert Chalmas, HB9BZA, for a French version of adv_txt and help files
Diego Serafin, IK3HUK, for the first Italian version of adv_txt and help files
Jonny, DG4MMI, for the German version of adv_txt
Mark Wahl, DL4YBG, for putting special features into TNT
Andrea Fiorentino, I0/N5KME, for the second Italian version of adv_txt
Rich Schmelkin, AE4EJ for running the old CLX mailing list
Ian Maude, G0VGS for helping a lot with the user documentation
Jose Lopez, EA5SW, for a Spanish version of adv_txt
Ignacio Galiana, EA7FPE, for the new version of the Spanish adv_txt
Gerard Parat, F6FGZ for a French version of adv_txt and extensive user manual
Lutz Petschulat, DG0LP, for updating the CLX help files to version 3.02
Heikki Hannikainen, OH7LZB, for running the current CLX mailing list
Luca Palazzo, IW9EXL, for updating the Italian files
Luiz F. Catalan, PP5AQ, for a Portuguese version of adv_txt
Erwin Lemmers, PE1NMB, for a Dutch version of adv_txt and help files
Matthew (Max) George, NG7M, for picking up the FAQ maintenance
Peter Pfann, DL2NBU, for his work on the SHOW/SUN command family
Ulrich Müller, DK4VW, for his work on the German user manual
Arnold Bosch, PE2AB, for updating the Dutch version of adv_txt
Angel Claus, EA7WA, for his help on the Spanish adv_txt
Did I forget you? Please let me know! Want to show up in this list too? Ask for the list of jobs to be done! Many details and small jobs could be outsourced if we found the people to do it.
The following is a collection of frequently asked questions by users of the CLX software. The FAQ is now (as of September 1998) being maintained by Matthew (Max) George, NG7M. It will probably be left out from this document in the near future.
Q. What are the timings for CLX setting up connections to other CLX and/or Pavillion-nodes?
A. CLX usually measures the time for how long nothing has been received on a link connection. If this is longer than five minutes, CLX sends a ping (PC51) to the node. Then it waits for another 5 minutes. If nothing is received in return to the ping, it explicitly disconnects the link connection, waits one minute and starts to setup the link again.
Initially, after CLX has been brought up, the software will start making connections after a period of 60 seconds to allow all database activities to finish before the first node-to-node connection is established.
Q. Which services must be started on my system to run CLX?
A. Normally, this will be checked by the check script in the tools directory. Basically, you need syslogd, portmap and postmaster. postmaster must be running under UID=postgres, all others as root. Additionally you need one of the two communication packages, either Alan Cox's AX.25 driver or WAMPES. These must be running when CLX is started.
Q. CLX has no monitor. How can I see what my users are doing?
A.
$ tail -f ~/logs/io.log
Q. What Linux versions has CLX been tested on?
A. We have started CLX with Linux 1.1.50 and we are currently using it under 2.0.35.
Q. rpcinfo says:
rpcinfo: can't contact portmapper:
RPC: Remote system error - Connection refused
A. portmap is not running. Start it from the
rc.* script when booting Linux.
Q. In the postgres directory, many files have
permissions 600 (``-rw------'').
How can any program touch these files after all?
A. The Postgres database system does all its job via the postmaster process who is handling the communication with any external processes and programs. This is needed for serialisation so that every transaction is finished before the next one starts. Due to this, only the postgres user must have access to the database files. Any user permits etc. are treated internally by the postgres software.
Q. How come the kissinit command works
without specifying a speed?
A. 9600 is the default. If you are using another speed on your line, you must set this explicitly with the stty command.
Q. When starting up CLX it hangs right
at the beginning with clx_ctl. What's wrong?
A. Check if clx_ctl is really running
under UID clx_us and postmaster
under UID postgres. If this doesn't help, reboot. Sometimes the
shared memory gets screwed up when testing out CLX. This does not
happen under normal circumstances.
Q. When starting up CLX everything comes
up until con_ctl, which hangs
forever. What's wrong?
A. The two callsigns, the one
you specify with kissattch and the one which
is encrypted in ~/config/clx_par
must be identical. Otherwise con_ctl
will hang.
Q. SH/DX 20 no longer works, but SH/DX is
still OK. What's happened?
A. Most probably your DX database table has gone wild. This is a bug in Postgres which has not yet been cleared. We have observed a destroyed DX table many times at DB0CLX. Your only chance to correct the problem is destroying and building the table from scratch. Here is how:
$ cd ~/db
$ psql clx_db
clx_db=> drop table dx_data;
clx_db=> \i dx_data.cl
clx_db=> \q
$
Q. When I start CLX with clx -u, the last
process (con_ctl) says
con_ctl AX.25 interface .Invalid symbol in callsign.......
to the console and keeps writing dots to the terminal. Or, when starting up CLX, the callsign is shown as follows:
Reading /usr/local/clx/config/clx_par.
Decoding callsign.
*** CLX System Parameters ***
callsign: ?
database: clx_db
interface: AX25
A. You are using an old wrong libc version. Get libc.so.5.4.7! 5.3.12 and 5.2.18 definitely do not work with CLX 2.05 and later. Also the RedHat 5.1 Linux distribution comes with an outdated libc.so.5 version which needs to be replaced in order to make CLX work with it. A new version was available from ftp://sunsite.unc.edu/pub/Linux/libs at the time of this writing. Steve Meuse, W1MV, points out that the new version 5.4.38 was available from ftp://sunsite.unc.edu/pub/Linux/GCC/libc-5.4.38.bin.tar.gz.
Q. CLX doesn't seem to delete the nodes (in sh/conf) after
a disconnect. Is it because I'm using an external script? If not can
I do something for this?
A. The Nodes listing is a programming problem. I will try to explain:
CLX allows loops and multiple
connects within a PacketCluster/CLX network. If a node connection is lost
but another one still exists into the network, which of the nodes in the
list are then no longer "members of the network"? We have tried to solve this
question several times without success. So I think CLX currently just
follows the node connect/node disconnect (PC19/PC21) spots and as
long as
it still has a valid connection, displays all nodes in the network.
If you can provide us with a good solution to the problem we are ready to implement it.
Q. CLX does not report its own node connection list to other Pavillion PacketCluster nodes? This hides the network behind CLX to their users. Why don't you report this information (through PC38/PC39, PC19/PC21)?
A. The problem you describe (PC38) has in fact nothing to do with PC38. It is only a compatibility issue and for that reason, CLX is not sending any such information to a PacketCluster node. Here is why:
About 9 months ago CLX would send a list of connected nodes out to every active link. Due to CLX's special ability to make multiple connects into a network, some distant nodes already showed up in CLX's Node list. We had a configuration like this:
DB0ABH-15
|
DB0SPC +-----------DB0BCC--------------OE1XHB
| |
| +--DB0SDX------(A)-----DB0CLX
| | |
+-HB9W-8-----------(P)-------+
We found out that whenever DB0CLX reported that it had connected HB9W-8, DB0SDX would no longer try to establish its own connection to HB9W-8. Obviously, the PacketCluster software anticipated that the connection already existed.
We had this same situation between DB0BCC, DB0SDX and DB0CLX so it is certainly a bug/problem in the Pavillion software (which does not know about multiple links).
For this reason we decided that CLX would not report any network information to neighbouring Pavillion nodes. However, it does fully report to adjacent CLX nodes.
Q. Is there a CLX mailing list?
A. Yes! Thanks to Heikki Hannikainen, OH7LZB, CLX has its own mailing list. See CLX Mailing List for details on how to subscribe.
By the way, the current list of CLX users can be found elsewhere in this document in CLX User List.
Q. How can I restart CLX when a process has died? clx -s
followed by clx -u doesn't work.
A. The reason for this is that (a) one or more of the processes hung and did not clear its rpc port address, or (b) some of the shared memory areas is not free. What can you do?
There is now a -x to the CLX script which allows clearing
resources. Clearing rpc ports, however, requires root privileges.
$ clx -x
You must be root to clear rpc ports.
Password:
Now you should be able to restart CLX without rebooting the machine.
Q. My users seem to get disconnected after a certain period of inactivity. Is it CLX that disconnects users after a specific time?
A. No! CLX does not disconnect anyone due to inactivity. No such feature is in the software nor is it planned to implement it. This answer applies to you if you are using a 2.0.x kernel and the AX.25 driver in it.
In the 2.0.x unmodified Linux Kernel there is a problem with
the so-called IDLE Timer. The default value seems to be 60 minutes and
the maximum value which can be chosen in the ax25d.conf file is
99 minutes. I believe this problem is gone in 2.1 kernels and probably
also in the module-14 patch (a patch against kernel 2.0.31) which is
available now. To get around the problem, I modified the file
/usr/src/linux/net/ax25/ax25_timer.c, line 176:
Old:
176 if (ax25->idletimer > 0 && --ax25->idletimer == 0) {
New:
176 /* if (ax25->idletimer > 0 && --ax25->idletimer == 0) { */
177 if (0) {
and rebuilt the kernel. This patchwork is not necessary with Linux kernel version 2.0.35.
The ax25module-14b patch was available from ftp.funet.fi://pub/ham/unix/Linux/packet/ax25-utils/ax25-module.
Q. I have only a DOS machine on the Internet. How can I get the big CLX archive to my Linux box?
A. There are several ways. One that I have used often in the past
is by using PKZIP on the DOS and unzip on the Linux side.
Prerequisites: - PKZIP version 2.04 on DOS machine - unzip version 5.12 on Linux machine.
C:\TMP>dir *.tgz
CLX_301 TGZ 2,564,043 07-20-97 9:06p
C:\TMP>pkzip -& a:clx.zip clx_301.tgz
Creating ZIP: A:CLX.ZIP
Adding: CLX_301.TGZ Deflating ( 2%)
Insert disk #2 - Press a key when ready
, done.
C:\TMP>
clx1.zip and the file from disk 2
to clx2.zip:
$ mcopy a:clx.zip clx1.zip
Copying clx.zip
$ mcopy a:clx.zip clx2.zip
Copying clx.zip
clx.zip file:
$ cat clx1.zip clx2.zip > clx.zip
$ unzip clx.zip
Archive: clx.zip
warning [clx.zip]:
zipfile claims to be last disk of a multi-part archive;
attempting to process anyway, assuming all parts have been
concatenated together in order. Expect "errors" and warnings...
true multi-part support
doesn't exist yet (coming soon).
warning [clx.zip]: extra 1457664 bytes at beginning or within zipfile
(attempting to process anyway)
file #0: bad zipfile offset (local header sig): 1457668
(attempting to re-compensate)
inflating: CLX_301.TGZ
$ ll CLX_301.TGZ
-rw-r--r-- 1 ben users 2564043 Jul 20 21:06 CLX_301.TGZ
You should now have clx_301.tgz on your Linux box.
Q. The su command procedure to start up postmaster
and clx when booting Linux does not work. Why?
A. The following message was received from Per-Eric, SM6MNH. Maybe this is also your problem:
I've seen many messages about problems with the su command lately and I just want to say that I have the same problem. The problems began when I upgraded my Debian Linux installation from version 1.2 to 1.3.
Before the upgrade I could use the command
$ su - postgres -c "postmaster &"
but now I can't. So something changed and I don't like it...
Erwin Lemmers, PE1NWB, notes that some Linux distributions come with
a broken /bin/su command. He fixed the problem using the following
startup script:
echo "Loading postgres"
echo "postmaster > /dev/tty8 2>&1 &" | su - postgres
#
echo "Loading clx"
echo "clx -r > /dev/tty8 2>&1 &" | su - clx_us
#
For the default installation we recommend to start CLX using the
script ~/tools/startup as root.
Q. What do the occasional messages like
icl_com/us_ctrl.cc: Message is not correct "PC50"/
in my io.log mean?
A. PacketCluster knows a special type of external connections
using the -EXT switch in the node definition. Due to a bug in the
AK1A software, the PC50 will be sent in a different format which is
not understood by CLX.
Q. My system is crashing very often for unknown reasons. Other CLX sysops report that the version I am using is generally stable. What can I do?
A. We have found that once in a while, the postgres database can become slightly corrupted - probably due to previous crashes or other reasons. That means, the data is available and all looks OK but some datum deep in the database is broken and when CLX reads is (due to some innocent user command), a string variable may be exhausted, a float may be returned where an integer was expected etc. etc. As CLX is never checking the input data received from the database, a program may crash from this bad data.
What has cured the problem in the past several times was backing up the
database, destroying it completely, recreating it and re-reading the data.
How do you do it? First you need some time (maybe several hours, depending
on your data) and you need to shutdown CLX. Having done that, issue
the following commands (all as user clx_us):
$ bup_db -s
$ clx_db
$ bup_db -r
$ clx_idx
While backing up the files is normally pretty fast, re-reading the data may take a while.
This treatment was successful for DB0BCC when CLX version 4.00b turned out to be pretty stable elsewehere but not at DB0BCC. After re-reading the data, the system would stay up for up to 16 days.
Q. How can I turn off the screen blanker?
A. Use /bin/setterm -blank 0 in your Linux startup
scripts.
Q. What does the message "kernel: Unable to load interpreter"
mean? I find this in my log when CLX crashed.
A. This is a very definitive message from the operating system kernel saying that it cannot execute a new program because it cannot load the ELF interpreter. We have observed that with version 4.00 of CLX where a bug in one of the programs ate up more and more file descriptors (FDs) and in the end (after a few hours, sometimes days), there were no more FDs available. Then all kinds of strange things would happen. Fortunately this bug was found very quickly but when such a message ocurs again, you should check for the number of FDs currently used with the following command:
# echo /proc/[0-9]*/fd/* | wc -w
This command must be executed as root. When freshly started, CLX needs about 300 FDs. The limit in the unmodified Linux kernel is 1024.
Here is a list of known bugs in the current CLX software. If you happen to find a bug not listed here, please let us know.
show/configuration display even after they
were disconnected. This is a problem which needs a
concept. Due to CLX's ability to support multiple links,
it is unclear when a node is no longer available if
one link fails.REPLY to answer a mail message you
received from a station at a different node, your return
message will not be forwarded.
Nobody is perfect. So is this software. We have put a lot of work and energy into this project but yet some problems are left to be unleashed. CLX has been on the air at DB0CLX for more than three years now. In the mean time, many bugs were fixed, new ones introduced and fixed again. At this time we have reached a point where we believe there are no major bugs left (but you may prove us wrong).
If you find bugs, please try to describe them in a detailed way and let us know. Please be as specific as possible and include screen shots, logs etc. with your report. Send the report by email to [email protected].
Sometimes one of the CLX processes dies silently. You will see
that by inspecting io.log or error.log
and seeing a message like this:
snd_ctl/rpc_send.cc -> con_ctl, 0 - 1/dj0zy: Connection refused
This usually indicates that con_ctl has died and
snd_ctl is not
able to deliver a telegram to this process.
In such a case it is very valuable for us to have a copy of the
last 10-20 messages in the io.log. Please send
this together with your error report.
This software is developed by DJ0ZY and DL6RAI.
DJ0ZY is doing the C++ and Postgres core programming. So his
activities are mainly in the ~/bin and ~/db
directories. DL6RAI's job is maintaining the Perl scripts in
~/bin, ~/tools, ~/exec and the
documentation in ~/doc. This information should help you
to direct your bug reports either to Franta or to me. If in doubt, send your
message to
[email protected].
A list of features currently missing in CLX which are going to be implemented next.