-
-
- timeout 15
- connect telnet dirkl.tobit.co.uk
- # 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.
-
-
- 3\b3.\b.5\b5.\b. S\bSt\bta\bar\brt\bti\bin\bng\bg t\bth\bhe\be c\bco\bon\bnn\bne\bec\bct\bti\bio\bon\bn
-
- You start the connection, from within a sysop enabled cluster login,
- by typing in the word _\bc_\bo_\bn_\bn_\be_\bc_\bt followed by a script name like this ....
-
-
-
- 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 _\bg_\bb_\b7_\bd_\bj_\bk_\b-_\b1. You
- can follow the connection by watching the term or console from where
- you started _\bc_\bl_\bu_\bs_\bt_\be_\br_\b._\bp_\bl. You should see something like this ...
-
-
-
- <- 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
-
-
-
-
-
- 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 _\bb_\be_\bf_\bo_\br_\be 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 ...
-
-
- In a script, this might look like ...
-
-
-
- timeout 35
- abort (Busy|Sorry|Fail)
- connect telnet mary 3000
-
-
-
-
-
- 3\b3.\b.6\b6.\b. T\bTe\bel\bln\bne\bet\bt e\bec\bch\bho\bo
-
- 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 ...
-
-
-
- timeout 35
- abort (Busy|Sorry|Fail)
- connect telnet mary.lancs.ac.uk
-
-
-
-
- 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.
-
-
-
- 4\b4.\b. A\bAu\but\bto\bom\bma\bat\bti\bin\bng\bg t\bth\bhi\bin\bng\bgs\bs
-
- 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.
-
-
- 4\b4.\b.1\b1.\b. A\bAu\but\bto\bos\bst\bta\bar\brt\bti\bin\bng\bg t\bth\bhe\be c\bcl\blu\bus\bst\bte\ber\br
-
- 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 _\bt_\be_\bl_\bi_\bn_\bi_\bt _\bq. DXSpider should start up
- immediately. You will see the output on tty7 and if you login as
- _\bs_\by_\bs_\bo_\bp you should find everything running nicely.
-
-
- So far so good, now to automate script connections...
-
-
- 4\b4.\b.2\b2.\b. T\bTh\bhe\be c\bcr\bro\bon\bnt\bta\bab\bb f\bfi\bil\ble\be
-
- Login as _\bs_\by_\bs_\bo_\bp 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.
-
-
- 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.
-
-
- 5\b5.\b. H\bHo\bop\bp c\bco\bon\bnt\btr\bro\bol\bl
-
- 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).
-
-
- 5\b5.\b.1\b1.\b. B\bBa\bas\bsi\bic\bc h\bho\bop\bp c\bco\bon\bnt\btr\bro\bol\bl
-
- 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 ...
-
-
-
- #
- # 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,
- },
- };
-
-
-
- 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.
-
-
- You can alter this file at any time, including whilst the cluster is
- running. If you alter the file during runtime, the command _\bl_\bo_\ba_\bd_\b/_\bh_\bo_\bp_\bs
- will bring your changes into effect.
-
-
- 5\b5.\b.2\b2.\b. I\bIs\bso\bol\bla\bat\bti\bin\bng\bg n\bne\bet\btw\bwo\bor\brk\bks\bs
-
- It is possible to isolate networks from each other on a "gateway" node
- using the _\bs_\be_\bt_\b/_\bi_\bs_\bo_\bl_\ba_\bt_\be _\b<_\bn_\bo_\bd_\be_\b__\bc_\ba_\bl_\bl_\b> command.
-
-
- 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.
-
-
- 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.
-
-
- 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
- ....
-
-
-
- $in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
- ];
-