[Dxspider-support] Connect script problem

[g3orh]

OK. Thanks Dirk (and also Cees who replied)
This the current script which applies to the debug output below it:-
timeout 60
abort (Busy|Sorry|Fail)
connect ax25 /usr/sbin/netrom_call net gb7orh gb7cn
'connect' 'c 3 #dray'
'connect' 'c gb7wdx'

Note:- The first letter of "Connected to" from the requested node is always
upper case but I guess this doesn't matter as you say non of this is case
sensitive.

Now the debug for connects:-
The first 2 or 3 lines were lost since I have to physically write this as it
appears but these are similar to the first 3 lines of the script file. It
continues:-
Connecting to gb7cn
expecting "connect" received "Connecting to gb7cn"
got :"Connect" sending C 3 #dray
*** Connected     (as you can see it looks like the c 3 #dray is sent before
                              *** Connected is received from gb7cn. It
continues:-
expecting :"connect" received "*** Connected"
got : "Connect" Sending :"C gb7wdx"  < so this now looks out of sequence
                                                              as no
connection was received
from #dray. C gb7wdx becomes a connect request at gb7cn not at
#dray (the connect for which was ignored due to sequencing). The
timeout level of 1 minute (60 s) is more than adequate for responses
from gb7cn and #dray *but* the whole sequence transacted within approx
20 seconds without any pause (it seems) for any "Connected to" issued by the
requested nodes.

Bear in mind I am at a point where I am only connected now to gb7cn but the
script file has already issued C gb7wdx. The debug continues :-

DXchannel gb7wdx created (5)
< O gb7wdx ax25
> B gb7wdx 0
> E gb7wdx 0
gb7wdx channel func state 0 > init
< I gb7wdx CDN:GB7CN packet switch
< I gb7wdx CDN:GB7CN Downlink connect needs port number C P C/S
< I gb7wdx Ports  (and at this point gb7cn has sent an error with  next
connect request (which is our c gb7wdx) since node gb7wdx does not exist)
and has obviously ignored the previous C 3 #dray. CDN proceeds to send me it
's port detail which is the standard response to an unknown route connect
request.

Because DXChannel gb7wdx now exists and gb7wdx is shown connected at gb7orh
(even though it isn't) gb7orh commences sending init PC's which are
immediately rejected by gb7cn (because so far the other connect requests
have been ignored or misread and gb7cn see's gb7orh as only connected to it
and not to the remote nodes.

I do apologise for having to handwrite these debug things as to date I have
discovered no way of getting any file from the linux hdd onto the dos floppy
in such a way that it can be read on a dos machine (the windows box for
internet). Several Linux Guru's having told me the only way is to tar cvf
/dev/fd0 /dir/<filename> but this leaves the dos formatted floppy in an
unreadable state for a dos machine. (However that's another problem).

I think the crucial part is in the first 5 or 6 lines of the debug output ,
what node gb7cn sends me and the difference between that and what the script
file is looking for.

PHEW ! Note: set/debug connects was run from ./console.pl window and output
taken from ./cluster.pl window
- Regards Colin   (73's)
- g3orh at ic24.net

----- Original Message -----
From: Dirk Koopman <djk at tobit.co.uk>
To: <dxspider-support at dxcluster.org>
Sent: Sunday, August 19, 2001 2:19 PM
Subject: Re: [Dxspider-support] Connect script problem


> 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
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://www.tobit.co.uk/mailman/listinfo/dxspider-support