[Dxspider-support] Connect script problem

[Dirk Koopman]

On 19 Aug 2001 10:20:21 +0100, g3orh wrote:
> Hi Ian,
> 
>                Since my last emails on this subject I haven't had chance to
> play further. The timeout value is currently set to 60 sec's though. In
> truth this possibly needs to be around 420 secs to cater for variable condx
> over the 4 mtr path. However , the script process (looking at debug) seems
> confused by the step by step results it gets and I put this down to sending
> connect commands out of sequence with the remote (intermediate) nodes. I
> will try setting a higher timeout value.
> 
> One thing you might be able to help with is the identification (as shown in
> the manual section "connects") of G1TLH and in the connect scripting of
> C NP7  ?   I am having to guess at this but is NP7 the alias for G1TLH ? If
> so then it could answer some things. I think the inclusion of "Format"
> commands would help and indeed a complete list of script commands available
> would do the same.

I find myself in a bit of a difficulty here, probably because I know
both how and that it works and because I appear not to have explained it
properly in the documentation.

That was one of the main reasons why I wanted other people to contribute
or even do documentation (Thank you Ia(i)n's).

Let me try to explain how it works in some other words.

Please look at the following script (which is not real but
it will do for discussion). The line numbers on the LHS of each line are
there only to allow me to refer to the line YOU DON'T PUT THEM IN THE
SCRIPT!!!

1: timeout 60
2: abort (Busy|Sorry|fail|abort)
3: connect ax25 /usr/sbin/netrom_call net gb7orh cdn
4: 'connected to' 'c #dray'
5: 'linked to' 'c gb7wdx'
6: '*** connected' ''

Line 1 says that it will wait for up to 60 seconds between each line of
the following script - if the next line takes more than 60secs to happen
then the whole script will abort.

Line 2 says that if any of the strings between the ( | ) characters are
seen then the whole script immediately aborts. The strings are not case
sensitive.

Line 3 initiatates the physical connection process for the type of
connection in use. In this case it starts the program 'netrom_call' to
act as an interface for ax25. Netrom_call (and ax25_call) require you to
use the callsign (or netrom name) of THE FIRST HOP as the callsign that
you connect to. Think about how you would do the connection manually and
whatever the first connection would be, use that.

Line 4 is the first 'expect' - 'do' line. What it is doing is waiting
for the string 'connected to' and when (and only when) it see that
string - it sends 'c #dray'.

Line 5 (for illustrative purposes only) is waiting for the string
'linked to' (sometimes used by KAM type nodes), when (and only when) it
sees that does it send 'c gb7wdx'.

Line 6 waits for the string '*** connected' (which should be sent by the
final hop when it connects) and then does NOTHING and, as this was the
final line, exits the script. This line, in effect, just waits for the
final connect to gb7wdx. 

Each of the last 3 lines is an 'expect this string' - 'send this string'
command - each line waits for the LH string to appear in the input from
the connection and when it sees it, sends the RH string with the
appropriate style of line ending character (carriage return for ax25,
carriage return + line feed for telnet). THESE ARE 'waitfor' commands,
that is the whole point of them.

In order to debug connect scripts what you should do is: 

set/debug connect

in a console window and then either watch the STDOUT of the cluster.pl
program or run /spider/perl/watchdbg in other window or console and
watch that. Look for 'significant' or unique strings in each stage of
the conversation and put those on the LH side of the expect/send line
together with the command that will kick off the next hop.

unset/debig connect

will stop the connect script debugging.

Does this help at all?

If not please cut and paste the latest version of your connect
conversation from the debugging I will see if I can fix it.

Dirk