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 ... +
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 ...
default * * * * * * - sysop /spider/src/client client %u ax25
or, if you wish your users to be able to use SSID's on their callsigns ..
-
+
+default * * * * * * - sysop /spider/src/client client %s ax25
+
+For most purposes this is not desirable. The only time you probably will need this is +when you need to allow other cluster nodes that are using SSID's in. In this case it +owuld probably be better to use the first example and then add a specific line for that +node like this: +
+
+
+GB7DJK-2 * * * * * * - sysop /spider/src/client client gb7djk-2 ax25
+default * * * * * * - sysop /spider/src/client client %u ax25
+
++
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 .... +
+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
+spdlogin 7300/tcp # spider anonymous login port
Then add a line in /etc/inetd.conf like this .... @@ -46,8 +70,7 @@ spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
-
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 .... +
Once this is done, you need to restart inetd like this ....
@@ -56,38 +79,132 @@ killall -HUP inetd
-
Now login as sysop and cd spider/perl. You can test that spider is accepting telnet logins by issuing the -following command .... +
Now login as sysop and cd spider/src. You can test that spider +is accepting telnet logins by issuing the following command ....
-client.pl login telnet
+./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. +
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
+telnet localhost 7300
You should now get the login prompt and be able to login as before.
-
From version 1.47 you can chose to allow the perl cluster.pl program to
+allow connections direct (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 then 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", 7300],
+);
+
++
As standard, the listener will listen on all interfaces simultaniously. If you require more +control than this, you can specify each interface individually:- +
+
+
+@listen = (
+ ["gb7baa.dxcluster.net", 7300],
+ ["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 which 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. +
+
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.+
+
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. +
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.
-
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 ... +
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 ...
@@ -95,14 +212,15 @@ 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. +
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 and issue the command ... +
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.pl gb7baa (using the callsign you set as a node)
+./client gb7baa (using the callsign you set as a node)
@@ -110,72 +228,102 @@ client.pl gb7baa (using the callsign you set as a node)
-client.pl gb7baa
+./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. +
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
+
++
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. +
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:- -
+
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.
+
-
-# 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]).
+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
+
-
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.
timeout 60
abort (Busy|Sorry|Fail)
-# don't forget to chmod 4775 netrom_call!
-connect ax25 /usr/sbin/netrom_call bbs gb7djk g1tlh
+# 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'
@@ -198,14 +346,14 @@ 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. +
Both these examples assume that everything is set up properly at the other end. +You will find other examples in the /spider/examples directory.
-
You start the connection, from within a sysop enabled cluster login, by typing in the word connect followed -by a script name like this .... +
You start the connection, from within a sysop enabled cluster login, by typing +in the word connect followed by a script name like this ....
@@ -214,8 +362,10 @@ 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. You should see something like this ... +
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 ...
@@ -242,15 +392,18 @@ 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^~
+<- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users Max users 0 Uptime
+0 00:00^5447^~
etc
-
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 +
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 ...
@@ -272,23 +425,24 @@ connect telnet mary 3000
-
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 8000, 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 ... +
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 ...
@@ -302,67 +456,15 @@ connect telnet mary.lancs.ac.uk
'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 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. -
-
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 will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart it should it crash for any reason. -
-
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. -
-
So far so good, now to automate script connections... -
-
Login as sysop 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) -
-
-
-# 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')
-
--
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. +
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.
-
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 -DXSpider website at the cron page where it is -explained more fully.