IMPORTANT: -
What you'll be left with once you've followed these instructions -is (hopefully) a working DX Spider v1.47 system that is capable -of accepting or originating "internet" connections, plus inbound -AX.25 and TCP/IP radio connections. If the absence of outbound -radio connections is a serious limitation for you, it would be -better for you to wait a couple more weeks until this support has -been added. -
On the other hand, you may have an enquiring mind, or better yet, -may be looking for a useful way of connecting your current -(perhaps) AK1A cluster "to the internet" via some networking -mechanism (BPQEther, etc) or other. I won't be producing -instructions for the latter case, because I don't have an AK1A to -play with. But someone might ... -
Whatever, this document is intended to get you started with DX -Spider in a Microsoft Windows ™ environment. It's not -intended to teach you anything other than how to perform a -minimum configuration of a DX Spider installation and have it -able to connect across "the internet" to other DX Clusters, while -accepting inbound TELNET and radio connections. -
-
This is dealt with in the previous section +
+
+>From version 1.47 there is a new (more efficient) way of doing this +(see next section) but, if you prefer, the method of doing it described +here will continue to work just fine. +
+
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 .... +
+
+
+spdlogin 8000/tcp # spider anonymous login port
+
++
Then add a line in /etc/inetd.conf like this .... +
+
+
+spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
+
++
Once this is done, you need to restart inetd like this .... +
+
+
+killall -HUP inetd
+
++
Now login as sysop and cd spider/src. You can test that spider +is accepting telnet logins by issuing the following command .... +
+
+
+./client login telnet
+
++
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. +
+
Assuming all is well, then try a telnet from your linux console .... +
+
+
+telnet localhost 8000
+
++
You should now get the login prompt and be able to login as before. +
+
>From version 1.47 you can choose to allow the perl cluster.pl program to
+allow connections directly (i.e. not via the /spider/src/client
+interface program). If you are using Windows then this is the only method
+available of allowing incoming telnet connections.
+
+
To do this you need first to remove any line that you may previously have set +up in /etc/inetd.conf. Remember to:- +
+
+
+killall -HUP inetd
+
++
to make the change happen... +
+
Having done that, you need to copy the file +/spider/perl/Listeners.pm to /spider/local and +then edit it. You will need to uncomment the line containing "0.0.0.0" +and select the correct port to listen on. So that it looks like this:- +
+
+
+@listen = (
+ ["0.0.0.0", 8000],
+);
+
++
As standard, the listener will listen on all interfaces simultaneously. +If you require more control than this, you can specify each interface +individually:- +
+
+
+@listen = (
+ ["gb7baa.dxcluster.net", 8000],
+ ["44.131.16.2", 6300],
+);
+
++
This will only be successful if the IP addresses on each interface are static. +If you are using some kind of dynamic IP addressing then the 'default' method +is the only one that will work. +
+
Restart the cluster.pl program to enable the listener. +
+
One important difference with the internal listener is that no echoing +is done by the cluster program. Users will need to set 'local-echo' on in +their telnet clients if it isn't set automatically (as per the standards). +Needless to say this will probably only apply to Windows users. +
+
The very first things you're going to need are (in order of -importance):- +
AGW Engine is a Windows based ax25 stack. You can connect to an AGW engine +from Linux as well as Windows based machines. +
+
In order to enable access to an AGW Engine you need to copy +/spider/perl/AGWConnect.pm to /spider/local and edit it. +Specifically you must:-
$enable to 1.$login and $passwd to the values set up in your AGW installation.
+If you haven't set any there, then you should not touch these values.$addr
+and $port appropriately.
-
The platform I used to generate these instructions was a -"vanilla" Microsoft Windows Me 4.90.3000 system, with a 700MHz -AMD Athlon processor and 96 Mb memory. I've also personally -verified that it runs on my laptop (Pentium 266MHz, 32 Mb memory, -Windows 98 SE v4.10.2222 A) and a computer that I assembled from -a random pile of junk (AMD K6-2 333MHz, 64 Mb memory, Windows 98 -v4.10.1998). As a result, I have reason to believe that what I'm -about to describe will perform equally on any 32-bit MS Windows -environment with 32 Mb of memory. -
Because of the changes that have recently been made to the core -"cluster.pl" module and the introduction of a very lightweight -"winclient.pl", I have a sneaking suspicion that this will now -run on any platform that has reasonably complete support for -Perl. Is there someone out there with both an enquiring mind and -(say) a Macintosh, for instance? -
Please bear in mind, though, that my instructions relate solely -to how to get this going under a Microsoft Windows environment, -and I have zero intention of trying to make them say otherwise. -
-
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. +
+
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 ... +
+
+
+set/node (AK1A type)
+set/spider
+set/dxnet
+set/clx
+
++
For now, we will assume that the cluster we are going to connect to is an +AK1A type node. +
+
Start up the cluster as you did before and login as the sysop with client. +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 ... +
+
+
+set/node gb7baa
+
++
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. +
+
That is now set, it is as simple as that. To prove it, login on yet another +console as sysop, cd to spider/src and issue the command ... +
+
+
+./client gb7baa (using the callsign you set as a node)
+
++
You should get an initialisation string from DXSpider like this ... +
+
+
+./client gb7baa
+PC38^GB7MBC^~
+
+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. +
+
Sometimes you make a mistake... Honest, it does happen. If you want to make a node +back to being a normal user, regardless +of what type it is, do: +
+
+
+unset/node gb7baa
+
++
Install your chosen Perl environment. Unless you have a very good -reason for not doing so, I strongly suggest that you use -ActivePerl v5.6. For my testing & development, I used build 623. -You can get this from:- -http://www.activestate.com/Products/ActivePerl/Download.html
You will need to choose either the MSI or the AS package. My -recommendation is that you choose the MSI package and deal with -the consequences if your system isn't equipped with support for -the latest MS Installer; you'll be better off in the long run. -The build 623 download is 7,460 KB, so now is a really good time -to have some tea if you're on a slow dial-up connection. -
During installation, please ensure that you do choose the options -to "Add Perl to the PATH environment variable" and "Create Perl -file extension association"; it will make your life so much -easier. Once the installation is finished, be sure to reboot your -PC. You probably won't be told anywhere else that this needs to -be done now, but it does. Really. -
Once you've rebooted, open a "DOS box" (Start > Run > command -might do it, if you can't find it elsewhere) and from wherever it -lands, type PERL -v <ENTER> (it's better if that's a lower-case -'v', because an upper-case 'V' means something else. You should -be rewarded with some interesting information about your Perl -installation. If you're not, you must go back to the beginning -and discover what went wrong and fix it. It's pointless to -proceed unless this simple check is passed. Assuming it did work, -you may now move on. -
-
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. +
+
The connect scripts consist of lines which start with the following keywords +or symbols:- +
+
+
All lines starting with a # are ignored, as are completely
+blank lines.
+
+
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 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 followed by ax25, agw (for Windows users) 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 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]).
+
+
There are many possible ways to configure the script but here are three examples, +one for a NETRom/AX25 connect, one for AGW engines and one for tcp/ip. +
+
+
+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
+
++
+
+
+
+timeout 60
+abort (Busy|Sorry|Fail)
+# this does exactly the same as the previous example
+# the '1' is the AGW port number to connect thru for g1tlh
+connect agw 1 g1tlh
+'Connect' ''
+'Connect' 'c np7'
+'Connect' 'c gb7dxm'
+# you can leave this out if you call the script 'gb7dxm'
+client gb7dxm ax25
+
++
+
+
+
+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
+
++
Both these examples assume that everything is set up properly at the other end. +You will find other examples in the /spider/examples directory. +
+
Some extensions ("packages") need to be added to the base Perl -distribution, and we'll do this next. If you're using the Perl I -recommended, and don't know any better for yourself, then just -blindly following these instructions will work just fine. If that -didn't describe you, then you're on your own. -
Visit the following URL: +
You start the connection, from within a sysop enabled cluster login, by typing +in the word connect followed by a script name like this ....
-http://www.activestate.com/PPMPackages/zips/6xx-builds-only/
and download the following files:- +
+
+G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
+connection to GB7DJK-1 started
+G0VGS de GB7MBC 13-Dec-1998 2043Z >
+
++
This will start a connection using the script called gb7djk-1. You can
+follow the connection by watching the term or console from where you started
+cluster.pl. From version 1.47 onwards, you will need to set/debug connect first.
+You should see something like this ...
-Data-Dumper.zip
-Net-Telnet.zip
-TimeDate.zip
-Time-HiRes.zip
-DB_File.zip
+<- 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
Make yourself a convenient directory to unpack all of these zip -files into (I put mine in "D:\ppm>") and do the following (the -bits you type in are blue ). Note that where these files land -will be directly related to where you chose to install your -ActivePerl (mine, as you can probably guess from what follows, -went into "D:\Perl"):- +
+
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 +before 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 ...
-D:\ppm>ppm install Data-Dumper.ppd
-Installing package 'Data-Dumper.ppd'
-Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.bs
-Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.dll
-Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.exp
-Installing D:\Perl\site\lib\auto\Data\Dumper\Dumper.lib
-Installing D:\Perl\html\site\lib\auto\Data\Dumper\Dumper.html
-Installing D:\Perl\site\lib\Data\Dumper\Dumper.pm
-Writing D:\Perl\site\lib\auto\Data\Dumper\Dumper.packlist
-D:\ppm>
+'connect' ''
I'm not going to bother you with exhaustive details of the rest -of them, but suffice it to say you need to: +
+
In a script, this might look like ...
-ppm install DB_File.ppd
-ppm install Net-Telnet.ppd
-ppm install TimeDate.ppd
-ppm install Time-HiRes.ppd
+timeout 35
+abort (Busy|Sorry|Fail)
+connect telnet mary 3000
+'ogin:' 'gb7mbc'
+'>' 'telnet 44.131.93.96 7305'
+'connect' ''
If all that seemed to work OK, time to move along. Before anyone -who is familiar with PPM tells me that we didn't need to download -and keep those files locally, I knew that. I also knew that PPM -is sometimes awkward to configure via firewalls, and that -sometimes the repositories don't always work the way we'd hope. I -do it that way because it suits me.
-
Get the current version of the DX Spider distribution. This needs -to be v1.47 or later. You've got two ways (currently) of getting -this; either get a CVS update from sourceforge (if you don't know -what this is, then it isn't for you) or get my package from:- -
-http://www.dcc.rsgb.org/WinSpider.zip
or if you want the lastest CVS version (which is produced every night) -
-http://www.dxcluster.org/download/CVSlatest.tgz
If you went down the CVS route, then everything will be nicely -set out on your local disk. If you got the ZIP file, unpack it to -somewhere convenient. The following examples assume that you put -it on drive "C:\", for convenience. -
NOTE: This distribution method will go away as soon as the first -v1.47 tarball is released. You can use WinZip to unpack that, and -my life will be made easier by not needing to keep this .ZIP file -updated. +
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. +
+
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 7300, this negotiation does +not happen and therefore no echo should be present. +
+
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 ... +
+
+
+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' ''
+
++
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. +
+
+
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. It +would be much easier to have it start automatically. +
+
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. +
+
Login as root and bring up the /etc/inittab file in your favourite editor. Add +the following lines to the file near the end ... +
+
+
+##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
+
++
This line works fine for RedHat distributions. It is also fine for SuSE up to +7.0. From SuSE 7.1 you need to add runlevels 2 and 5 like this ... +
+
+
+DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
+
++
The line required for Slackware distributions is slightly different. My thanks to +Aurelio, PA3EZL for this information. +
+
+
+DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7
+
++
This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart +it should it crash for any reason. +
+
NB: It should be noted that /dev/tty7 is only an example. Some SuSE systems will +only accept upto tty6. It really does not matter which tty you run it on. +
+
As root type the command telinit q. DXSpider should start up +immediately. You will see the output on tty7 and if you login as sysop +you should find everything running nicely.