-This section describes the installation of DX Spider v1.46 on a
-<htmlurl url="http://www.redhat.com" name="RedHat"> Linux Distribution.
-Wherever possible I will try to include differences for other distributions.
-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
-installation guide that comes with the Spider distribution.
-
-<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">. Earlier versions of
-Spider required perl 5.004, however it is now <it>STRONGLY</it> recommended
-that you use at least version 5.005_03 as this is the version being used
-in the development of Spider.
-
-<P>In addition to the standard Red Hat distribution you will require the
-following modules from <htmlurl url="http://www.cpan.org/CPAN.html" name="http://www.cpan.org/CPAN.html"> ...
-
-<P>
-<itemize>
-
-<item> MD5-1.7.tar.gz
-<item> Data-Dumper-2.10.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.46 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.46.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.46
-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>
-
-or, if you wish your users to be able to use SSID's on their callsigns ..
-
-<tscreen><verb>
-default * * * * * * - sysop /spider/src/client client %s 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
-
-<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>
-
-<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 ...
-
-<tscreen><verb>
-'connect' ''
-</verb></tscreen>
+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>
+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>
+The new functionality introduced in version 1.48 allows 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>.
+
+<p>
+What this really means is that you can control more or less completely
+which user and node management PC protocol frames pass to each of your
+partner nodes. You can also limit what comes into your node from your
+partners. It is even possible to control the settings that your partner
+node has for the routing information that it sends to you
+(using the <it>rcmd</it> command).
+
+<sect1>Route Filters
+
+<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.
+
+<p>
+The first thing that you must do is determine whether you need to use
+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>
+To put it simply, you should not mix Isolation and Route Filtering. It
+will work, of sorts, but you will not get the expected results. If you
+are using Isolation sucessfully at the moment, do not get involved in
+Route Filtering unless you have a good supply of aspirin! Once you have
+started down the road of Route Filtering, do not use Isolation either.
+Use one or the other, not both.
+
+<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>
+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.
+
+<P>
+Anyway, without further discouragement, let me start the process
+of explanation.
+
+<sect1>The node_default filter
+
+<P>
+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>
+The generic commands are:-
+
+<tscreen><verb>
+reject/route node_default <filter_option>