<!-- Title information -->
-<title>The DXSpider Installation and Administration Manual
-<author>Ian Maude, G0VGS, (ianmaude@btinternet.com)
-<date>Version 1.33 (Revision 3) February 2001
+<title>The DXSpider Administration Manual v1.48</title>
+<author>Ian Maude, G0VGS, (ianmaude@btinternet.com)</author>
+<date>Version 1.48 August 2001 revision 1.1</date>
+
<abstract>
A reference for SysOps of the DXSpider DXCluster program.
</abstract>
<!-- Begin the document -->
-<sect>Installation (Original version by Iain Phillips, G0RDI)
+<sect>Routing and Filtering
<sect1>Introduction
<P>
-This section describes the installation of DX Spider v1.35 on a
-<htmlurl url="http://www.redhat.com" name="RedHat"> Linux Distribution.
-I do not intend to try and cover the installation of Linux or the setup
-of the AX25 utilities. If you need help on this then read Iains original
-HOWTO on the <htmlurl url="http://www.dxcluster.org" name="DXSpider">
-website.
-
-<P>
-I am assuming a general knowledge of Linux and its commands. You should
-know how to use <em>tar</em> and how to edit files using your favourite editor.
-
-<P>
-The crucial ingredient for all of this is
-<htmlurl url="http://www.perl.org" name="Perl 5.004">. Now I know Perl 5.005
-is out and this will almost certainly work with it, but
-<htmlurl url="http://www.redhat.com" name="RedHat 5.1"> comes with 5.004.
-<em>Be Warned</em>, earlier versions of
-<htmlurl url="http://www.redhat.com" name="RedHat"> <bf>do not</bf> come
-with 5.004 as standard, you need to
-<htmlurl url="ftp://upgrade.redhat.com" name="upgrade">
-
-<P>In addition to the standard Red Hat distribution you will require the
-following <htmlurl url="http://www.cpan.org/CPAN.html" name="CPAN"> modules: -
-
-<P>
-<itemize>
-
-<item> MD5-1.7.tar.gz
-<item> Data-Dumper-2.10.tar.gz
-<item> FreezeThaw-0.3.tar.gz
-<item> MLDBM-2.00.tar.gz
-<item> TimeDate-1.08.tar.gz
-<item> IO-1.20.tar.gz
-<item> Net-Telnet-3.02.tar.gz
-<item> Curses-1.05.tar.gz
-<item> Time-HiRes-01.20.tar.gz
-
-</itemize>
-
-<P>
-
-<em>Do</em> get the latest versions of these packages and install them
-but use the above list as the earliest versions usable.
-
-<sect1>Preparation
-
-<P>
-I will assume that you have already downloaded the latest tarball of
-the DXSpider software and are ready to install it. I am assuming version
-1.35 for this section but of course you would use the latest version.
-
-<P>
-Login as root and create a user to run the cluster under. <bf><it>UNDER
-NO CIRCUMSTANCES USE ROOT AS THIS USER!</it></bf>. I am going to use
-the name <em>sysop</em>. You can call it anything you wish. Depending
-on your security requirements you may wish to use an existing user,
-however this is your own choice.
-
-<P>
-<tscreen><verb>
-# adduser -m sysop
-</verb></tscreen>
-
-<P>
-Now set a password for the user ...
-
-<tscreen><verb>
-# passwd sysop
-# New UNIX password:
-# Retype new UNIX password:
-passwd: all authentication tokens updated successfully
-</verb></tscreen>
-
-<sect1>Installing the software
-
-<P>
-Now to unpack the DX Spider distribution, set symbolic links and group
-permissions. Copy the tarball to /home/sysop and do the following.
-
-<tscreen><verb>
-# cd ~sysop
-# tar xvfz spider-1.35.tar.gz
-# ln -s ~sysop/spider /spider
-# groupadd -g 251 spider (or another number)
-</verb></tscreen>
-
-If you do not have the command <em>groupadd</em> available to you simply
-add a line in /etc/group by hand.
-
-<tscreen><verb>
-# vi /etc/group (or your favorite editor)
-</verb></tscreen>
-
-You also need to add some others to the group, including your own callsign
-(this will be used as an alias) and root. The finished line in /etc/group
-should look something like this
-
-<tt>
-spider:x:251:sysop,g0vgs,root
-</tt>
-
-<P>
-The next step is to set the permissions on the Spider directory tree and files ....
-
-<tscreen><verb>
-# chown -R sysop.spider spider
-# find . -type d -exec chmod 2775 {} \;
-# find . -type f -exec chmod 775 {} \;
-</verb></tscreen>
-
-<P>
-This last step allows various users of the group <em>spider</em> to have
-write access to all the directories. This is not really needed just yet
-but will be useful when web interfaces start to appear.
-
-<P>
-Finally, you need to fix the permissions on the ax25_call and netrom_call
-programs. Check where they are with the <em>locate</em> command and alter
-the permissions with the <em>chmod</em> command like this ..
-
-<tscreen><verb>
-# chown root ax25_call netrom_call
-# chmod 4775 ax25_call netrom_call
-</verb></tscreen>
-
-<sect1>Setting callsigns etc
-
-<P>
-Now login to your machine as the user you created earlier. In my case that
-user is called <em>sysop</em>. Once logged in, issue the following commands ....
-
-<tscreen><verb>
-$ cd /spider
-$ mkdir local
-$ mkdir local_cmd
-$ cp perl/DXVars.pm.issue local/DXVars.pm
-$ cd local
-$ vi DXVars.pm (or your favourite editor)
-</verb></tscreen>
-
-<P>
-Using the distributed DXVars.pm as a a template, set your cluster callsign,
-sysop callsign and other user info to suit your own environment. Note that
-this a perl file which will be parsed and executed as part of the cluster. If
-you get it wrong then perl will complain when you start the cluster process.
-It is important only to alter the text of any section. Some of the lines look
-a little odd. Take this line for example ....
-
-<tt>
-$myemail = "ianmaude\@btinternet.com";
-</tt>
-
-<P>
-There appears to be an extra slash in there. However this has to be there
-for the file to work so leave it in.
-
-<P><bf>PLEASE USE CAPITAL LETTERS FOR CALLSIGNS</bf>
-
-<P>
-DON'T alter the DXVars.pm (or any other file) in /spider/perl, they are
-overwritten with every release. Any files or commands you place in /spider/local
-or /spider/local_cmd will automagically be used in preference to the ones in
-/spider/perl EVEN while the cluster is running!
-
-<P>
-Save the new file and change directory to ../perl ....
-
-<tscreen><verb>
-$ cd ../perl
-</verb></tscreen>
-
-<P>
-Now type the following command which creates the basic user file with you as
-the sysop.
-
-<tscreen><verb>
-$ create_sysop.pl
-</verb></tscreen>
-
-<sect1>Starting up for the first time
-
-<P>
-We can now bring spider up for the first time and see if all is well or not!
-It should look something like this ...
-
-<tscreen><verb>
-$ cluster.pl
-DXSpider DX Cluster Version 1.35
-Copyright (c) 1998 Dirk Koopman G1TLH
-loading prefixes ...
-loading band data ...
-loading user file system ...
-starting listener ...
-reading existing message headers
-reading cron jobs
-orft we jolly well go ...
-</verb></tscreen>
-
-<P>
-If all is well then login on another term or console as <em>sysop</em> and
-cd to /spider/perl. Now issue the following command ...
-
-<tscreen><verb>
-$ client.pl
-</verb></tscreen>
-
-<P>
-This should log you into the cluster as the sysop under the alias callsign we
-set earlier. In this case the callsign is G0VGS. The cluster callsign is set
-in the DXVars.pm file in /spider/local. In this case we will assume that this
-was set as GB7MBC. You should therefore see this when you login ....
-
-<tscreen><verb>
-G0VGS de GB7MBC 19-Nov-1999 2150Z >
-</verb></tscreen>
-
-If you do, congratulations! If not, look over the instructions again, you
-have probably missed something out. You can shut spider down again with the
-command ....
-
-<tscreen><verb>
-shutdown
-</verb></tscreen>
-
-<P>
-and both the cluster and the client should return to Linux prompts.
-
-<sect>The Client program
-
-<P>
-In earlier versions of Spider, all the processes were Perl scripts. This
-was fine but with a lot of users your computer memory would soon be used up.
-To combat this a new client was written in "C". This client only works for
-<em>incoming</em> connects at the moment. Before you can use it though it
-has to be "made". CD to /spider/src and type <em>make</em>. You
-should see the output on your screen and hopefully now have a small C program
-called <em>client</em>. Leave it in this directory.
-
-<sect>Configuration
-
-<sect1>Allowing ax25 connects from users
-
-<P>
-As stated previously, the aim of this document is not to tell you how to
-configure Linux or the ax25 utilities. However, you do need to add a line
-in your ax25d.conf to allow connections to DXSpider for your users. For
-each interface that you wish to allow connections on, use the following format ...
-
-<tscreen><verb>
-default * * * * * * - sysop /spider/src/client client %u ax25
-</verb></tscreen>
-
-<sect1>Allowing telnet connects from users
-
-<P>
-Allowing telnet connections is quite simple. Firstly you need to add a line
-in /etc/services to allow connections to a port number, like this ....
-
-<tscreen><verb>
-spdlogin 8000/tcp # spider anonymous login port
-</verb></tscreen>
-
-Then add a line in /etc/inetd.conf like this ....
-
-<tscreen><verb>
-spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
-</verb></tscreen>
-
-<P>
-This needs to be added above the standard services such as ftp, telnet etc.
-Once this is done, you need to restart inetd like this ....
-
-<tscreen><verb>
-killall -HUP inetd
-</verb></tscreen>
-
-
-<P>Now login as <em>sysop</em> and cd spider/perl. You can test that spider
-is accepting telnet logins by issuing the following command ....
-
-<tscreen><verb>
-client.pl login telnet
-</verb></tscreen>
-
-You should get a login prompt and on issuing a callsign, you will be given
-access to the cluster. Note, you will not get a password login. There seems
-no good reason for a password prompt to be given so it is not asked for.
-
-<P>
-Assuming all is well, then try a telnet from your linux console ....
-
-<tscreen><verb>
-telnet localhost 8000
-</verb></tscreen>
-
-<P>
-You should now get the login prompt and be able to login as before.
-
-<sect1>Setting up node connects
-
-<P>
-In order to allow cluster node connections, spider needs to know that the
-connecting callsign is a cluster node. This is the case whether the connect
-is incoming or outgoing. In spider this is a simple task and can be done in
-runtime.
-
-<P>
-Later versions of Spider can distinguish different software and treat them
-differently. For example, the WCY beacon cannot be handles by AK1A type
-nodes as AK1A does not know what to do with PC73. There are 4 different
-types of node at present and although they may not have any major
-differences at the moment, it allows for compatibility. The 4 types are ...
-
-<tscreen><verb>
-set/node (AK1A type)
-set/spider
-set/dxnet
-set/clx
-</verb></tscreen>
-
-<P>
-For now, we will assume that the cluster we are going to connect to is an
-AK1A type node.
-
-<P>
-Start up the cluster as you did before and login as the sysop with client.pl.
-The cluster node I am wanting to make a connection to is GB7BAA but you would
-obviously use whatever callsign you required. At the prompt type ...
-
-<tscreen><verb>
-set/node gb7baa
-</verb></tscreen>
-
-<P>
-The case does not matter as long as you have a version of DXSpider later than
-1.33. Earlier versions required the callsign to be in upper case.
-
-<P>
-That is now set, it is as simple as that. To prove it, login on yet another
-console as sysop and issue the command ...
-
-<tscreen><verb>
-client.pl gb7baa (using the callsign you set as a node)
-</verb></tscreen>
-
-<P>
-You should get an initialisation string from DXSpider like this ...
-
-<tscreen><verb>
-client.pl gb7baa
-PC38^GB7MBC^~
-</verb></tscreen>
-
-If the callsign you just set up as a cluster node is for an incoming connect,
-this is all that needs to be done. If the connection is to be outgoing then
-a connection script needs to be written.
-
-<sect1>Connection scripts
-
-<P>
-Because DXSpider operates under Linux, connections can be made using just about
-any protocol; AX25, NETRom, tcp/ip, ROSE etc are all possible examples.
-Connect scripts live in the /spider/connect directory and are simple ascii files.
-Writing a script for connections is therefore relatively simple.
-
-<P>
-The connect scripts consist of lines which start with the following keywords
-or symbols:-
-
-<verb>
-
-# All lines starting with a # are ignored, as are completely
- blank lines.
-
-timeout timeout followed by a number is the number of seconds to wait for a
- command to complete. If there is no timeout specified in the script
- then the default is 60 seconds.
-
-abort abort is a regular expression containing one or more strings to look
- for to abort a connection. This is a perl regular expression and is
- executed ignoring case.
-
-connect connect followed by ax25 or telnet and some type dependent
- information. In the case of a telnet connection, there can be up to
- two parameters.
- The first is the ip address or hostname of the computer you wish to
- connect to and the second is the port number you want to use (this
- can be left out if it is a normal telnet session).
- In the case of an ax25 session then this would normally be a call to
- ax25_call or netrom_call as in the example above. It is your
- responsibility to get your node and other ax25 parameters to work
- before going down this route!
-
-' ' is the delimiting character for a word or phrase of an expect/send
- line in a chat type script. The words/phrases normally come in pairs,
- either can be empty. Each line reads input from the connection until
- it sees the string (or perl regular expression) contained in the
- left hand string. If the left hand string is empty then it doesn't
- read or wait for anything. The comparison is done ignoring case.
- When the left hand string has found what it is looking for (if it is)
- then the right hand string is sent to the connection.
- This process is repeated for every line of chat script.
-
-client client starts the connection, put the arguments you would want here
- if you were starting the client program manually. You only need this
- if the script has a different name to the callsign you are trying to
- connect to (i.e. you have a script called other which actually
- connects to GB7DJK-1 [instead of a script called gb7djk-1]).
-</verb>
-
-
-There are many possible ways to configure the script but here are two examples,
-one for a NETRom/AX25 connect and one for tcp/ip.
-
-<tscreen><verb>
-timeout 60
-abort (Busy|Sorry|Fail)
-# don't forget to chmod 4775 netrom_call!
-connect ax25 /usr/sbin/netrom_call bbs gb7djk g1tlh
-'Connect' ''
-'Connect' 'c np7'
-'Connect' 'c gb7dxm'
-# you can leave this out if you call the script 'gb7dxm'
-client gb7dxm ax25
-</verb></tscreen>
-
-<P>
-
-<tscreen><verb>
-timeout 15
-connect telnet dirkl.tobit.co.uk
-'login' 'gb7djk'
-'word' 'gb7djk'
-# tell GB7DJK-1 that it is connected to GB7DJK
-# you can leave this out if you call this script 'gb7djk'
-client gb7djk telnet
-</verb></tscreen>
-
-<P>
-Both these examples assume that everything is set up properly at the other end.
-You will find other examples in the /spider/examples directory.
-
-<sect1>Starting the connection
+From DXSpider version 1.48, major changes were introduced to the way
+node connections are treated. This is part of an ongoing process to
+remove problems with loops and to enable talk and other functions to
+propagate across the whole of the worldwide cluster network. In fact,
+in a Spider network, it would be useful, perhaps even necessary to
+have loops. This would give real resilience to the network, meaning
+that if a link dropped, the information flow would simply come in and
+go out via a different route. Of course, we do not have a complete
+network of Spider nodes, there are other programs out there. Some of
+these do not have any protection from loops. Certainly AK1A does not
+handle loops well at all. It is therefore necessary to have some form
+of protection for these nodes.
<P>
-You start the connection, from within a sysop enabled cluster login, by typing
-in the word <em>connect</em> followed by a script name like this ....
-
-<tscreen><verb>
-G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
-connection to GB7DJK-1 started
-G0VGS de GB7MBC 13-Dec-1998 2043Z >
-</verb></tscreen>
-
-This will start a connection using the script called <em>gb7djk-1</em>. You can
-follow the connection by watching the term or console from where you started
-<em>cluster.pl</em>. You should see something like this ...
-
-<tscreen><verb>
-<- D G1TLH connect gb7djk-1
--> D G1TLH connection to GB7DJK-1 started
--> D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z >
-timeout set to 15
-CONNECT sort: telnet command: dirkl.tobit.co.uk
-CHAT "login" -> "gb7djk"
-received "
-Red Hat Linux release 5.1 (Manhattan)
-Kernel 2.0.35 on an i586
-"
-received "login: "
-sent "gb7djk"
-CHAT "word" -> "gb7djk"
-received "gb7djk"
-received "Password: "
-sent "gb7djk"
-Connected to GB7DJK-1, starting normal protocol
-<- O GB7DJK-1 telnet
--> B GB7DJK-1 0
-GB7DJK-1 channel func state 0 -> init
-<- D GB7DJK-1
-<- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1
-<- D GB7DJK-1 PC38^GB7DJK-1^~
-<- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users Max users 0 Uptime
-0 00:00^5447^~
- etc
-
-</verb></tscreen>
+In fact DXSpider has had a simple system for some time which is called
+<it>isolation</it>. This is similar to what, in other systems such as
+<bf>clx</bf>, is called <it>passive mode</it>. A more detailed explanation
+of <it>isolation</it> is given further below. This system is still available
+and, for simple networks, is probably all that you need.
<P>
-With later versions of Spider there is a set/login command for users. This
-tells them when a user or node logs in or out. If you do not add a line to
-your scripts after the final line (or before the client line which should always
-be last if needed) then the login/logout information will be sent to users
-<it>before</it> the login actually completes. This means if a node is
-unreachable, it will continue sending logins and logouts to users even though it
-is not actually connecting. To avoid this use the following line ...
+The new functionality introduced in version 1.48 is filtering the node
+and user protocol frames on a "per interface" basis. We call this
+<it>route filtering</it>. This is used <bf>instead of</bf>
+<it>isolation</it>.
-<tscreen><verb>
-'connect' ''
-</verb></tscreen>
+<p>
+What this really means is that you can control more or less completely
+which PC protocol frames, to do with user and node management, pass to
+each of your partner nodes. You can also limit what comes into your
+node from your partners. You can even control the settings that your
+partner node has for the routing information that it sends to you
+(using the <it>rcmd</it> command).
-<P>
-In a script, this might look like ...
+<sect1>Route Filters
-<tscreen><verb>
-timeout 35
-abort (Busy|Sorry|Fail)
-connect telnet mary 3000
-'ogin:' 'gb7mbc'
-'>' 'telnet 44.131.93.96 7305'
-'connect' ''
-</verb></tscreen>
+<p>
+Initially when route filters were being tested we generated a
+"default" filter. Unfortunately it quickly became apparent that this
+might suit the UK cluster network but didn't really fit anybody else.
+However using a default filter is an appropriate thing to do. How, is
+explained further on.
-<sect1>Telnet echo
+<p>
+The first thing that you must do is determine whether you need to do route filtering <bf>at all</bf>. If you are a "normal" node with two or three partners
+and you arranged in an "official" non-looping tree type network, then <bf>you do
+not need to do route filtering</bf> and you will feel a lot better for not
+getting involved. If you are successfully using <it>isolation</it> then you
+also probably don't need to use route filtering.
-<P>
-Cluster links in particular suffer greatly from the presence of telnet echo.
-This is caused by the telnet negotiation itself and can create at worst severe
-loops. At best it creates unnecessary bandwidth and large logfiles! There are
-things that can be done to limit this problem but will not always work dependent
-on the route taken to connect.
+<p>
+You will only require this functionality if you are
+"well-connected". What that means is that you are connected to several
+different parts of (say) the EU cluster and, at the same time, also
+connected to two or three places in the US which, in turn are
+connected back to the EU. This is called a "loop" and if you are
+seriously looped then you need filtering.
<P>
-Telnet echo itself should only be a problem if the connection is being made to
-the telnet port (23). This port uses special rules that include echo negotiation.
-If the connection is to a different port, such as 8000, this negotiation does
-not happen and therefore no echo should be present.
-
-<P>
-Sometimes it is not possible to make a direct connection to another node and this
-can cause problems. There is a way of trying to suppress the telnet echo but
-this will not always work, unfortunately it is difficult to be more specific.
-Here is an example of what I mean ...
-
-<tscreen><verb>
-timeout 35
-abort (Busy|Sorry|Fail)
-connect telnet mary.lancs.ac.uk
-'ogin:' 'gb7mbc'
-'word:' 'mypasswd'
-'\$' 'stty -echo raw'
-'\$' 'telnet 44.131.93.96'
-'connect' ''
-</verb></tscreen>
+I should at this stage give a little bit of background on filters. All
+the filters in Spider work in basically the same way. You can either
+accept or reject various options in order to create the filter rules
+you wish to achieve. Some filters are user settable, others can only
+be altered by the sysop. Route filtering can only be done by the sysop.
-So, the first connection is made by Spider. This is fine as Spider uses the
-Net_Telnet script from within perl. This actually uses TCP rather than TELNET
-so no negotiation will be done on the first connection. Once connected to
-mary.lancs.ac.uk, the command is sent to suppress echo. Now a telnet is made
-to a cluster node that is accepting connections on port 23. The problem with
-this link is that the negotiation is made by the remote machine, therefore you
-have no control over it. The chances are that this link will create echo and
-there will be no way you can stop it.
+<P>
+Anyway, without further discouragement, let me start the process
+of explanation.
-
-<sect>Automating things
-
-<P>
-Ok, you should now have DXSpider running nicely and allowing connects by cluster
-nodes or users. However, it has to be shutdown and restarted manually and if
-connection scripts fail they have to be started again manually too, not much use
-if you are not at the console! So, in this section we will automate both.
-Firstly starting the cluster.
-
-<sect1>Autostarting the cluster
+<sect1>The node_default filter
<P>
-This is not only a way to start the cluster automatically, it also works as a
-watchdog, checking the sanity of DXSpider and respawning it should it crash for
-any reason. Before doing the following, shutdown the cluster as you did earlier.
+All normal systems should have a default routing filter and it should
+usually be set to send only the normal, unlooped, view of your
+"national" network. Here in the UK that means nodes from the UK and
+Eire, in EU it is more complex as the networks there grew up in a more
+intertwined way.
-<P>
-Login as root and bring up the /etc/inittab file in your favourite editor. Add
-the following lines to the file near the end ...
+<p>
+The generic commands are:-
<tscreen><verb>
-##Start DXSpider on bootup and respawn it should it crash
-DX:3:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
-</verb></tscreen>
+reject/route node_default <filter_option>
-<P>
-This line works fine for RedHat and SuSE distributions. The line required for
-Slackware distributions is slightly different. My thanks to Aurelio, PA3EZL for
-this information.
+or
-<tscreen><verb>
-DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7
+accept/route node_default <filter_option>
</verb></tscreen>
-<P>
-This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart
-it should it crash for any reason.
-
-<P>
-As root type the command <em>telinit q</em>. DXSpider should start up
-immediately. You will see the output on tty7 and if you login as <em>sysop</em>
-you should find everything running nicely.
-
-<P>
-So far so good, now to automate script connections...
-
-<sect1>The crontab file
-
-<P>
-Login as <em>sysop</em> and create a file in /spider/local_cmd called crontab.
-Edit it with your favourite editor and add a line like this (I have included
-a comment)
+where filter_option is one of the following ...
<tscreen><verb>
-# check every 10 minutes to see if gb7xxx is connected and if not
-# start a connect job going
-
-0,10,20,30,40,50 * * * * start_connect('gb7xxx') if !connected('gb7xxx')
+call <prefixes>
+call_dxcc <numbers>
+call_itu <numbers>
+call_zone <numbers>
+channel <prefixes>
+channel_dxcc <numbers>
+channel_itu <numbers>
+channel_zone <numbers>
</verb></tscreen>
-<P>
-The callsign involved will be the callsign of the cluster node you are
-going to connect to. This will now check every 10 minutes to see if
-gb7xxx is connected, if it is then nothing will be done. If it is not,
-then a connect attempt will be started.
-
-<P>
-There are probably lots of other things you could use this crontab file for.
-If you want to know more about it, look at the
-<htmlurl url="http://www.dxcluster.org/cron.html" name="DXSpider"> website
-at the cron page where it is explained more fully.
-
-<sect>Hop control
-
-<P>
-Starting with version 1.13 there is simple hop control available on a per
-node basis. Also it is possible to isolate a network completely so that you
-get all the benefits of being on that network, but can't pass on information
-from it to any other networks you may be connected to (or vice versa).
-
-<sect1>Basic hop control
+Please be careful if you alter this setting, it will affect
+<bf><it>ALL</it></bf> your links!
-<P>
-In /spider/data you will find a file called hop_table.pl. This is the file
-that controls your hop count settings. It has a set of default hops on the
-various PC frames and also a set for each node you want to alter the hops for.
-You may be happy with the default settings of course, but this powerful tool
-can help to protect and improve the network. The file will look something
-like this ...
+<p>
+For the default routing filter then you have two real choices: either
+a "national" view or the "safe" option of only your own
+callsign. Examples of each (for my node: GB7DJK) are:-
<tscreen><verb>
-#
-# hop table construction
-#
-
-package DXProt;
-
-# default hopcount to use
-$def_hopcount = 5;
-
-# some variable hop counts based on message type
-%hopcount =
-(
- 11 => 10,
- 16 => 10,
- 17 => 10,
- 19 => 10,
- 21 => 10,
-);
-
-
-# the per node hop control thingy
-
-
-%nodehops =
-
- GB7ADX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
-
- GB7UDX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
- GB7BAA => {
- 11 => 5,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
-};
+acc/route node_default call_dxcc 61,38
+acc/route node_default call gb7djk
</verb></tscreen>
-<P>
-Each set of hops is contained within a pair of curly braces and contains a
-series of PC frame types. PC11 for example is a DX spot. The figures here
-are not exhaustive but should give you a good idea of how the file works.
-
-<P>
-You can alter this file at any time, including whilst the cluster is running.
-If you alter the file during runtime, the command <em>load/hops</em> will
-bring your changes into effect.
-
-<sect1>Isolating networks
+GB7DJK uses the first of these. The DXCC countries can be obtained from the
+<it>show/prefix</it> command.
-<P>
-It is possible to isolate networks from each other on a "gateway" node using the
- <em>set/isolate <node_call></em> command.
-
-<P>
-The effect of this is to partition an isolated network completely from another
-nodes connected to your node. Your node will appear on and otherwise behave
-normally on every network to which you are connected, but data from an isolated
-network will not cross onto any other network or vice versa. However all the
-spot, announce and WWV traffic and personal messages will still be handled
-locally (because you are a real node on all connected networks), that is locally
-connected users will appear on all networks and will be able to access and
-receive information from all networks transparently. All routed messages will
-be sent as normal, so if a user on one network knows that you are a gateway for
-another network, he can still still send a talk/announce etc message via your
-node and it will be routed across.
+<p>
+The example filters shown control <it>output</it> <bf>TO</bf> all your
+partner nodes unless they have a specific filter applied to them (see
+next section).
-<P>
-The only limitation currently is that non-private messages cannot be passed down
-isolated links regardless of whether they are generated locally. This will change
-when the bulletin routing facility is added.
-
-<P>
-If you use isolate on a node connection you will continue to receive all
-information from the isolated partner, however you will not pass any information
-back to the isolated node. There are times when you would like to forward only
-spots across a link (maybe during a contest for example). To do this, isolate
-the node in the normal way and put in a filter in the /spider/filter/spots
-directory to override the isolate. This filter can be very simple and consists
-of just one line ....
+<p>
+It is also possible to control the <it>incoming</it> routing
+information that you are prepared to accept <bf>FROM</bf> your partner
+nodes. The reason this is necessary is to make sure that stuff like
+mail, pings and similar commands a) go down the correct links and b)
+don't loop around excessively. Again using GB7DJK as an example a typical
+default input filter would be something like:
<tscreen><verb>
-$in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
-];
+rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38
</verb></tscreen>
-<P>
-There is a lot more on filtering in the next section.
+What this does is accept node and user information for our national
+network from nodes that are in our national network, but rejects such
+information from anyone else. Although it doesn't explicitly say so,
+by implication, any other node information (not from the UK and Eire)
+is accepted.
-<sect>Filtering (Old Style upto v1.44)
-
-<P>
-Filters can be set for spots, announcements and WWV. You will find the
-directories for these under /spider/filter. You will find some examples in
-the directories with the suffix <em>.issue</em>. There are two types of
-filter, one for incoming information and one for outgoing information.
-Outgoing filters are in the form <em>CALLSIGN.pl</em> and incoming filters
-are in the form <em>in_CALLSIGN.pl</em>. Filters can be set for both nodes
-and users.
-
-<P>
-All filters work in basically the same way. There are several elements
-delimited by commas. There can be many lines in the filter and they are
-read from the top by the program. When writing a filter you need to think
-carefully about just what you want to achieve. You are either going to write
-a filter to <em>accept</em> or to <em>reject</em>. Think of a filter as
-having 2 main elements. For a reject filter, you would have a line or multiple
-lines rejecting the things you do not wish to receive and then a default line
-accepting everything else that is not included in the filter. Likewise, for an
-accept filter, you would have a line or multiple lines accepting the things you
-wish to receive and a default line rejecting everthing else.
-
-<P>
-In the example below, a user requires a filter that would only return SSB spots
-posted in Europe on the HF bands. This is achieved by first rejecting the CW
-section of each HF band and rejecting all of VHF, UHF etc based on frequency.
-Secondly, a filter rule is set based on CQ zones to only accept spots posted in
-Europe. Lastly, a default filter rule is set to reject anything outside the filter.
+<p>
+As I imagine it will take a little while to get one's head around all of this you
+can study the effect of any rules that you try by watching the debug output
+after having done:-
<tscreen><verb>
-$in = [
- [ 0, 0, 'r', # reject all CW spots
- [
- 1800.0, 1850.0,
- 3500.0, 3600.0,
- 7000.0, 7040.0,
- 14000.0, 14100.0,
- 18068.0, 18110.0,
- 21000.0, 21150.0,
- 24890.0, 24930.0,
- 28000.0, 28180.0,
- 30000.0, 49000000000.0,
- ] ,1 ],
- [ 1, 11, 'n', [ 14, 15, 16, 20, 33, ], 15 ], #accept EU
- [ 0, 0, 'd', 0, 1 ], # 1 = want, 'd' = everything else
-];
+set/debug filter
</verb></tscreen>
-<P>
-The actual elements of each filter are described more fully in the following
-sections.
-
-<sect1>Spots
-
-<P>
-The elements of the Spot filter are ....
+After you have got tired of that, to put it back the way it was:-
<tscreen><verb>
-[action, field_no, sort, possible_values, hops]
+unset/debug filter
</verb></tscreen>
-<P>
-There are 3 elements here to look at. Firstly, the action element. This is
-very simple and only 2 possible states exist, accept (1) or drop (0).
+<sect1>General route filtering
<P>
-The second element is the field_no. There are 13 possiblities to choose from
-here ....
+Exactly the same rules apply for general route filtering. You would
+use either an accept filter or a reject filter like this ...
<tscreen><verb>
- 0 = frequency
- 1 = call
- 2 = date in unix format
- 3 = comment
- 4 = spotter
- 5 = spotted dxcc country
- 6 = spotter's dxcc country
- 7 = origin
- 8 = spotted itu
- 9 = spotted cq
- 10 = spotter's itu
- 11 = spotter's cq
- 12 = callsign of the channel on which the spot has appeared
-</verb></tscreen>
+reject/route <node_call> <filter_option>
-<P>
-The third element tells us what to expect in the fourth element. There are
-4 possibilities ....
-
-<tscreen><verb>
- n - numeric list of numbers e.g. [ 1,2,3 ]
- r - ranges of pairs of numbers e.g. between 2 and 4 or 10 to 17 - [ 2,4, 10,17 ]
- a - an alphanumeric regex
- d - the default rule
-</verb></tscreen>
-
-<P>
-The fifth element is simply the hops to set in this filter. This would only
-be used if the filter was for a node of course and overrides the hop count in
-hop_table.pl.
-
-<P>
-So, let's look at an example spot filter. It does not matter in the example
-who the filter is to be used for. So, what do we need in the filter? We need
-to filter the spots the user/node requires and also set a default rule for
-anything else outside the filter. Below is a simple filter that stops spots
-arriving from outside Europe.
-
-<tscreen><verb>$in = [
- [ 0, 4, 'a', '^(K|N|A|W|VE|VA|J)'], # 0 = drop, 'a' = alphanumeric
- [ 1, 0, 'd', 0, 1 ], # 1 = want, 'd' = everything else
- ];
-</verb></tscreen>
-
-<P>
-So the filter is wrapped in between a pair of square brackets. This tells
-Spider to look in between these limits. Then each line is contained within
-its own square brackets and ends with a comma. Lets look carefully at the first
-line. The first element is 0 (drop). Therefore anything we put on this line
-will not be accepted. The next element is 4. This means we are filtering by
-the spotter. The third element is the letter "a" which tells the program to
-expect an alphanumeric expression in the fourth element. The fourth element
-is a list of letters separated by the pipe symbol.
-
-<P>
-What this line does is tell the program to drop any spots posted by anyone in
-the USA, Canada or Japan.
-
-<P>
-The second line is the default rule for anything else. The "d" tells us this
-and the line simply reads... accept anything else.
-
-<P>
-You can add as many lines as you need to complete the filter but if there are
-several lines of the same type it is neater to enclose them all as one line.
-An example of this is where specific bands are set. We could write this like
-this ....
+or
-<tscreen><verb>
-[ 0,0,'r',[1800.0, 2000.0], 1],
-[ 0,0,'r',[10100.0, 10150.0], 1],
-[ 0,0,'r',[14000.0, 14350.0], 1],
-[ 0,0,'r',[18000.0, 18200.0], 1],
+accept/route <node_call> <filter_option>
</verb></tscreen>
<P>
-But the line below achieves the same thing and is more efficient ....
-
-<tscreen><verb>
- [ 0, 0, 'r',
- [
- 1800.0, 2000.0, # top band
- 10100.0, 10150.0, # WARC
- 14000.0, 14350.0, # 20m
- 18000.0, 18200.0, # WARC
- [ ,1 ],
-</verb></tscreen>
-
-
-<sect1>Announcements
+Here are some examples of route filters ...
-<P>
<tscreen><verb>
-
-# This is an example announce or filter allowing only West EU announces
-#
-# The element list is:-
-# 0 - callsign of announcer
-# 1 - destination * = all, <callsign> = routed to the node
-# 2 - text
-# 3 - * - sysop, <some text> - special list eg 6MUK, ' ', normal announce
-# 4 - origin
-# 5 - 0 - announce, 1 - wx
-# 6 - channel callsign (the interface from which this spot came)
-
-$in = [
- [ 1, 0, 'a', '^(P[ABCDE]|DK0WCY|G|M|2|EI|F|ON)' ],
- [ 0, 0, 'd', 0 ]
-];
+rej/route gb7djk call_dxcc 61,38 (everything except UK+EIRE nodes)
+rej/route all (equiv to [very] restricted mode)
+acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
+acc/route gb7djk call gb7djk (equiv to SET/ISOLATE)
</verb></tscreen>
-In this example, only the prefixes listed will be allowed. It is possible to
-be quite specific. The Dutch prefix "P" is followed by several secondary
-identifiers which are allowed. So, in the example, "PA" or "PE" would be ok
-but not "PG". It is even possible to allow information from a single callsign.
-In the example this is DK0WCY, to allow the posting of his Aurora Beacon.
-
-<sect1>WWV
-
-<P>
-<tscreen><verb>
-
-# This is an example WWV filter
-#
-# The element list is:-
-# 0 - nominal unix date of spot (ie the day + hour:13)
-# 1 - the hour
-# 2 - SFI
-# 3 - K
-# 4 - I
-# 5 - text
-# 6 - spotter
-# 7 - origin
-# 8 - incoming interface callsign
-
-# this one doesn't filter, it just sets the hop count to 6 and is
-# used mainly just to override any isolation from WWV coming from
-# the internet.
+In practice you will either be opening the default filter out for a
+partner by defining a specific filter for that callsign:-
+
+<tscreen><verb>
+acc/route gb7baa all
+acc/route gb7baa input all
+</verb></tscreen>
-$in = [
- [ 1, 0, 'd', 0, 6 ]
-];
+or restricting it quite a lot, in fact making it very nearly like an <it>isolated</it> node, like this:-
+<tscreen><verb>
+acc/route pi4ehv-8 call gb7djk
+rej/route pi4ehv-8 input call_dxcc 61,38
</verb></tscreen>
-<P>
-It should be noted that the filter will start to be used only once a user/node
-has logged out and back in again.
-<P>
-I am not going to spend any more time on these filters now as they will become
-more "comprehensive" in the near future.
+This last example takes everything except UK and Eire from PI4EHV-8
+but only sends him my local configuration (just a PC19 for GB7DJK and
+PC16s for my local users).
+
+<p>
+It is possible to do <bf>much</bf> more complex rules, there are up to 10
+accept/reject pairs per callsign per filter. For more information see the
+next section.
-<sect>Filtering (New Style v1.45 and later)
<sect1>General filter rules
DXSpider system. They all use the same general mechanism.
<P>
-In general terms you can create a 'reject' or an 'accept' filter which can have
+In general terms you can create a "reject" or an "accept" filter which can have
up to 10 lines in it. You do this using, for example ...
<tscreen><verb>
to the accept line, which lets through everything else on HF. The next filter line
lets through just VHF/UHF spots from EU.
+<sect1>Basic hop control
+
+<P>
+In /spider/data you will find a file called hop_table.pl. This is the file
+that controls your hop count settings. It has a set of default hops on the
+various PC frames and also a set for each node you want to alter the hops for.
+You may be happy with the default settings of course, but this powerful tool
+can help to protect and improve the network. The file will look something
+like this ...
+
+<tscreen><verb>
+#
+# hop table construction
+#
+
+package DXProt;
+
+# default hopcount to use
+$def_hopcount = 5;
+
+# some variable hop counts based on message type
+%hopcount =
+(
+ 11 => 10,
+ 16 => 10,
+ 17 => 10,
+ 19 => 10,
+ 21 => 10,
+);
+
+
+# the per node hop control thingy
+
+
+%nodehops =
+
+ GB7ADX => { 11 => 8,
+ 12 => 8,
+ 16 => 8,
+ 17 => 8,
+ 19 => 8,
+ 21 => 8,
+ },
+
+ GB7UDX => { 11 => 8,
+ 12 => 8,
+ 16 => 8,
+ 17 => 8,
+ 19 => 8,
+ 21 => 8,
+ },
+ GB7BAA => {
+ 11 => 5,
+ 12 => 8,
+ 16 => 8,
+ 17 => 8,
+ 19 => 8,
+ 21 => 8,
+ },
+};
+</verb></tscreen>
+
+<P>
+Each set of hops is contained within a pair of curly braces and contains a
+series of PC frame types. PC11 for example is a DX spot. The figures here
+are not exhaustive but should give you a good idea of how the file works.
+
+<P>
+You can alter this file at any time, including whilst the cluster is running.
+If you alter the file during runtime, the command <em>load/hops</em> will
+bring your changes into effect.
+
+<sect1>Hop Control on Specific Nodes
+
+<p>You can set a callsign specific hop count for any of the standard filter
+options so:-
+
+<tscreen><verb>
+set/hops gb7djk spot 4
+set/hops node_default route 10
+set/hops gb7baa wcy 5
+</verb></tscreen>
+
+all work on their specific area of the protocol.
+
+<p>
+The <em>set/hops</em> command overrides any hops that you have set otherwise.
+
+<p>
+You can set what hops have been set using the <em>show/hops</em> command.
+
+<sect1>Isolating networks
+
+<P>
+It is possible to isolate networks from each other on a "gateway" node using the
+ <em>set/isolate <node_call></em> command.
+
+<P>
+The effect of this is to partition an isolated network completely from another
+node connected to your node. Your node will appear on and otherwise behave
+normally on every network to which you are connected, but data from an isolated
+network will not cross onto any other network or vice versa. However all the
+spot, announce and WWV traffic and personal messages will still be handled
+locally (because you are a real node on all connected networks), that is locally
+connected users will appear on all networks and will be able to access and
+receive information from all networks transparently. All routed messages will
+be sent as normal, so if a user on one network knows that you are a gateway for
+another network, he can still still send a talk/announce etc message via your
+node and it will be routed across.
+
+<P>
+If you use isolate on a node connection you will continue to receive
+all information from the isolated partner, however you will not pass
+any information back to the isolated node. There are times when you
+would like to forward only spots across a link (maybe during a contest
+for example). To do this, isolate the node in the normal way and use
+an <em>acc/spot >call< all</em filter in the
+to override the isolate.
<sect>Other filters
the other cluster nodes that we are linked to. This is usually because of
rules and regulations pertaining to items for sale etc in a particular country.
-<sect1>Filtering DX callouts (Depricated)
-<P>
-<bf><it>From version 1.47, this method is replaced by the command set/baddx</it></bf>
+<sect1>Filtering words from text fields in Announce, Talk and DX spots
-<P>
-In the same way as mail, there are some types of spot we do not wish to pass on
-to users or linked cluster nodes. In the /spider/data directory you will find
-a file called baddx.pl.issue. Rename this to baddx.pl and edit the file. The
-original looks like this ....
+<p>
+From version 1.48 onwards the interface to this has changed. You can now
+use the commands <em>set/badword</em> to add words that you are not prepared
+to see on the cluster, <em>unset/badword</em> to allow that word again and
+<em>show/badword</em> to list the words that you have set.
-<tscreen><verb>
+<p>
+If you have a previous <em>/spider/data/badwords</em>, the first time you start
+the node, it will read and convert this file to the new commands. The old style
+file will then be removed.
-# the list of dx spot addresses that we don't store and don't pass on
+<sect1>Stopping (possibly bad) DX Spots from Nodes or Spotters
+<p>
+There are a number of commands that control whether a spot progresses
+any further by regarding it as "bad" in some way.
-package DXProt;
+<p>
+A DX Spot has a number of fields which can checked to see whether they
+contain "bad" values, they are: the DX callsign itself, the Spotter and
+the Originating Node.
-@baddx = qw
-
- FROG
- SALE
- FORSALE
- WANTED
- P1RATE
- PIRATE
- TEST
- DXTEST
- NIL
- NOCALL
-);
-</verb></tscreen>
+<p>
+There are a set of commands which allow the sysop to control whether a
+spot continues:-
-<P>
-Again, this is simply a list of names we do not want to see in the spotted
-field of a DX callout.
+<tscreen><verb>
+set/baddx
+set/badspotter
+set/badnode
+</verb></tscreen>
+These work in the same as the <em>set/badword</em> command, you can add
+any words or callsigns or whatever to the appropriate database. For
+example, to stop a spot from a particular node you do:
-<sect1>Filtering words from text fields in Announce, Talk and DX spots
+<tscreen><verb>
+set/badnode gb7djk gb7dxc
+</verb></tscreen>
-<P>
-Create a file in /spider/data called <em>badwords</em>. The format is quite
-simple. Lines beginning with # are ignored so comments can be added. An
-example file is below ...
+a bad spotter:
<tscreen><verb>
-# Below is a list of words we do not wish to see on the cluster
-grunge grunged grunging
-splodge splodger splodging
-grince
-fluffle
+set/badspotter b0mb p1rat nocall
</verb></tscreen>
-Multiple words can be used on the same line as shown. Obviously these
-are just examples :-)
+and some bad dx:
-<P>
-You can reload the file from the cluster prompt as sysop with load/badwords.
+<tscreen><verb>
+set/baddx video wsjt
+</verb></tscreen>
+
+You can remove a word using the appropriate unset command
+(<em>unset/baddx, unset/badspotter, unset/badnode</em>) or list them
+using one of <em>show/baddx, show/badspotter</em> and
+<em>show/badnode</em>.
<sect>Mail
Make sure you only send mail to the clusters that want it by using the
Forward.pl file very carefully.
+<sect>Scripts
+
+<p>
+From 1.48 onwards it will become increasingly possible to control DXSpider's
+operation with scripts of various kinds.
+
+<p>
+In the first instance, in 1.48, the sysop can create, with their favorite
+text editor, files in the directory <em>/spider/scripts</em> which contain
+any legal command for a callsign or class of connection which will be executed
+at logon.
+
+<p>
+The filename are the callsign of the connection that you want the script to
+operate on, eg: <em>/spider/scripts/g1tlh</em>. The filenames are always in
+lower case on those architectures where this makes a difference.
+
+<p>
+In addition to the callsign specific scripts there are three others:-
+
+<tscreen><verb>
+startup
+user_default
+node_default
+</verb></tscreen>
+
+The <em>startup</em> script is executed immediately after all
+initialisation of the node is done, but before any connections are
+possible.
+
+<p>
+The <em>user_default</em> script is executed for every user that does
+<bf>NOT</bf> already have a specific script.
+
+<p>
+The <em>node_default</em> script is executed for every node that doesn't
+have a specific script.
+
+<p>
+There are a couple of examples in the <em>/spider/scripts</em> directory.
+
<sect>Databases
<P>
nested under directories. One use for this would be to store DX bulletins
such as the OPDX bulletins. These can be listed and read by the user.
To keep things tidy, make a directory under /spider/packclus called
-<em>bulletins</em>. Now copy any OPDX or similar bulletins into it. These
+<em>bulletin</em>. Now copy any OPDX or similar bulletins into it. These
can be listed by the user in the same way as above using the <em>show/files</em>
-command with an extension for the bulletins directory you have just created,
+command with an extension for the bulletin directory you have just created,
like this ....
<tscreen><verb>
-show/files bulletins
+show/files bulletin
</verb></tscreen>
<P>
<tscreen><verb>
sh/files
-bulletins DIR 20-Dec-1999 1715Z news 1602 14-Dec-1999 1330Z
+bulletin DIR 20-Dec-1999 1715Z news 1602 14-Dec-1999 1330Z
</verb></tscreen>
You can see that in the files area (basically the packclus directory) there is a
-file called <em>news</em> and a directory called <em>bulletins</em>. You can
+file called <em>news</em> and a directory called <em>bulletin</em>. You can
also see that dates they were created. In the case of the file <em>news</em>,
you can also see the time it was last modified, a good clue as to whether the
file has been updated since you last read it. To read the file called
type news
</verb></tscreen>
-To look what is in the bulletins directory you issue the command ....
+To look what is in the bulletin directory you issue the command ....
<tscreen><verb>
-show/files bulletins
+show/files bulletin
opdx390 21381 29-Nov-1999 1621Z opdx390.1 1670 29-Nov-1999 1621Z
opdx390.2 2193 29-Nov-1999 1621Z opdx391 25045 29-Nov-1999 1621Z
opdx392 35969 29-Nov-1999 1621Z opdx393 15023 29-Nov-1999 1621Z
You can now read any file in this directory using the type command, like this ....
<tscreen><verb>
-type bulletins/opdx391
+type bulletin/opdx391
Ohio/Penn DX Bulletin No. 391
The Ohio/Penn Dx PacketCluster
DX Bulletin No. 391
<P>
In later versions of Spider a simple console program is provided for the sysop.
This has a type ahead buffer with line editing facilities and colour for spots,
-announces etc. To use this program, simply use console.pl instead of client.pl.
+announces etc. To use this program, simply use console.pl instead of client.
<P>
To edit the colours, copy /spider/perl/Console.pl to /spider/local and edit the
accept/ann user_default by G,M,2
</verb></tscreen>
+<sect1>accept/route (8)
+
+<P>
+<tt>
+<bf>accept/route <call> [0-9] <pattern></bf> Set an 'accept' filter line for routing
+</tt>
+
+<P>
+Create an 'accept this routing PC Protocol' line for a filter.
+
+<P>
+An accept filter line means that if a PC16/17/19/21/24/41/50 matches this filter
+it is passed thru that interface. See HELP FILTERING for more info. Please read this
+to understand how filters work - it will save a lot of grief later on.
+
+<P>
+You can use any of the following things in this line:-
+
+<tscreen><verb>
+ call <prefixes> the callsign of the thingy
+ call_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
+ call_itu <numbers>
+ call_zone <numbers>
+ origin <prefixes> really the interface it came in on
+ origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
+ origin_itu <numbers>
+ origin_zone <numbers>
+</verb></tscreen>
+
+<P>
+some examples:-
+
+<tscreen><verb>
+ acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
+ acc/route gb7djk call gb7djk (equiv to SET/ISOLATE)
+</verb></tscreen>
+
+<P>
+You can use the tag 'all' to accept everything eg:
+
+<tscreen><verb>
+ acc/route all
+</verb></tscreen>
+
<sect1>accept/spots (0)
<P>
<P>
Send an announcement to LOCAL users only, where <text> is the text
-of the announcement you wish to broadcast
+of the announcement you wish to broadcast. If you do not wish to receive
+announces, use the <em>set/noannounce</em> command. Any announces made by
+a sysop will override set/noannounce.
<sect1>announce full (0)
do this if you change this file whilst the cluster is running in order for the
changes to take effect.
-
-<sect1>load/baddx (9)
-
-<P>
-<tt>
-<bf>load/baddx</bf> Reload the bad DX table
-</tt>
-
-<P>
-Reload the /spider/data/baddx.pl file if you have changed it manually whilst
-the cluster is running. This table contains the DX Calls that, if spotted,
-will not be passed on. FR0G and TEST are classic examples.
-
<sect1>load/badmsg (9)
<P>
expressions which are searched for in the fields targetted of each message.
If any of them match then that message is immediately deleted on receipt.
-<sect1>load/badwords (9)
-
-<P>
-<tt>
-<bf>load/badwords</bf> Reload the badwords file
-</tt>
-
-<P>
-Reload the /spider/data/badwords file if you have changed it manually whilst
-the cluster is running. This file contains a list of words which, if found
-on certain text portions of PC protocol, will cause those protocol frames
-to be rejected. It will all put out a message if any of these words are
-used on the announce, dx and talk commands. The words can be one or
-more on a line, lines starting with '#' are ignored.
-
<sect1>load/bands (9)
<P>
reject/ann user_default by G,M,2
</verb></tscreen>
+<sect1>reject/route (8)
+
+<P>
+<tt>
+<bf>reject/route <call> [0-9] <pattern></bf> Set an 'reject' filter line for routing
+</tt>
+
+<P>
+Create an 'reject this routing PC Protocol' line for a filter.
+
+<P>
+An reject filter line means that if a PC16/17/19/21/24/41/50 matches this filter
+it is NOT passed thru that interface. See HELP FILTERING for more info. Please
+read this to understand how filters work - it will save a lot of grief later on.
+You can use any of the following things in this line:-
+
+<tscreen><verb>
+ call <prefixes> the callsign of the thingy
+ call_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
+ call_itu <numbers>
+ call_zone <numbers>
+ origin <prefixes> really the interface it came in on
+ origin_dxcc <numbers> eg: 61,62 (from eg: sh/pre G)
+ origin_itu <numbers>
+ origin_zone <numbers>
+</verb></tscreen>
+
+<P>
+some examples:-
+
+<tscreen><verb>
+ rej/route gb7djk call_dxcc 61,38 (everything except UK+EIRE nodes)
+</verb></tscreen>
+
+<P>
+You can use the tag 'all' to reject everything eg:
+
+<tscreen><verb>
+ rej/route all (equiv to [very] restricted mode)
+</verb></tscreen>
+
<sect1>reject/spots (0)
<P>
<P>
Add a beep to DX and other terminal messages.
+<sect1>set/bbs (5)
+
+<P>
+<tt>
+<bf>set/bbs <call> [<call>..]</bf>Make <call> a BBS
+</tt>
+
<sect1>set/clx (5)
<P>
<P>
<tt>
-<bf>show/badspotter</bf>Show all the bad spotters in the system
+<bf>show/badspotter</bf> Show all the bad spotters in the system
</tt>
<P>
Display all the bad spotter's callsigns in the system, see SET/BADSPOTTER
for more information.
+<sect1>show/configuration (0)
+
+<P>
+<tt>
+<bf>show/configuration [<node>]</bf> Show all visible nodes and their users
+</tt>
+
+<P>
+This command allows you to see all the users that can be seen
+and the nodes to which they are connected. With the optional <em>node</em>,
+you can specify a particular node to look at.
+
+This command is normally abbreviated to: sh/c
+
+BE WARNED: the list that is returned can be VERY long
+
+<sect1>show/configuration/node (0)
+
+<P>
+<tt>
+<bf>show/configuration/node</bf> Show all the nodes connected
+</tt>
+
+<P>
+Show all the nodes connected locally and the nodes they have connected.
+
+<sect1>show/connect (1)
+
+<P>
+<tt>
+<bf>show/connect</bf> Show all the active connections
+</tt>
+
+<P>
+This command shows information on all the active connections known to
+the node. This command gives slightly more information than WHO.
+
<sect1>show/date (0)
<P>
This command shows the internal status of a message and includes information
such as to whom it has been forwarded, its size, origin etc etc.
+<P>
+If no message number is given then the status of the message system is
+displayed.
+
+<sect1>stat/route_node (5)
+
+<P>
+<tt>
+<bf>stat/route_node <callsign></bf> Show the data in a Route::Node object
+</tt>
+
+<sect1>stat/route_user (5)
+
+<P>
+<tt>
+<bf>stat/route_user <callsign></bf> Show the data in a Route::User object
+</tt>
+
<sect1>stat/user (5)
<P>
projects / spider.git / blobdiff