Very Computer

I have developed an annoying(to say the least) problem with modem communication.When I call out, at the point I should be getting a login prompt the
process freezes.  Here is the output of cu:

119 denali:/tmp% cu -d paul
conn(paul)
Device Type ACU wanted
mlock ttyf3 succeeded
filelock: ok
fixline(5, 2400)
processdev: calling setdevcfg(cu, ACU)
gdial(hayes24) called
expect: ("")
got it
sendthem (PAUSE
<NO CR>????????)
expect: (OK)
ATe1q0&d3s2=128L0^M^M^JOKgot it
sendthem (<NO CR>????????)
expect: (CONNECT)
^M^Jatdt(num. goes here)^M^M^JCONNECTgot it
getto ret 5
device status for fd=5
F_GETFL=2,iflag=`12045',oflag=`0',cflag=`2273',lflag=`0',line=`1'
cc[0]=`177',[1]=`34' , [2]=`10' , [3]=`25' , [4]=`1' , [5]=`0' , [6]=`0' , [7]=`0' ,
call _mode(1)
Connected
_receive started
 2400

paul logintransmit started
~[denali].
call tilda(.)
call _quit(0)
call _bye(0)

Disconnected
call cleanup(0)
call _mode(0)

Trying uucico in debug mode, I get:
120 denali:/tmp% /usr/lib/uucp/uucico -r1 -x4 -spaul >& paul

mchFind called (paul)
name (paul) not found; return FAIL
conn(paul)
Device Type ACU wanted
mlock ttyf3 succeeded
processdev: calling setdevcfg(uucico, ACU)
gdial(hayes24) called
expect: ("")
got it
sendthem (PAUSE
<NO CR>????????)
expect: (OK)
ATe1q0&d3s2=128L0^M^M^JOKgot it
sendthem (<NO CR>????????)
expect: (CONNECT)
^M^Jatdt(num. here)^M^M^JCONNECTgot it
getto ret 6
expect: ("")
got it
sendthem (DELAY
????????)
expect: (ogin:)

expect: (ogin:)
Call Failed: LOGIN FAILED
exit code 101
Conversation Complete: Status FAILED

What's wrong?  Any help will be greatly appreciated.

Cheers,

STUFF DELETED...
        >expect: (ogin:)

        >expect: (ogin:)
        >Call Failed: LOGIN FAILED
        >exit code 101
        >Conversation Complete: Status FAILED

        One place to look is the gettydefs file on your target
        system. Your host is looking for (ogin:) out of your
        Systems file. If the target system describes the incoming
        getty (tty)  differently, ie never echos "login:" string,
        your cu could hang. Or I could be completely wrong.

                Later ... ed

Ed is wrong.  The System file "chat script" is used for uucico
connections.  When you use the cu command, the "chat script" is not
used . . . the caller gets the login prompt and must respond.  An
example of use of the the chat script would be to execute:

        /usr/lib/uucp/Uutry -r machine_name

With this you can watch the chat script.

Most of log deleted...

Well, your chat script is waiting for "ogin:" to come back from the
other machine, and it looks like it's not getting it.  Neither of the
examples you showed had the ":" on the end, and this one shows your
machine sending something before the one you're calling (paul) even gets
done spawning its getty.  cu that machine and make sure its actually
sending  "paul login:" and not "paul login".  They've customized their
/etc/gettydef file, so they may have a typo in it :-).  If its only
echoing "login", take the colon out of your Systems chat script so it
has "ogin--ogin" instead.  If paul *is* echoing "login:", ad some
"\r\d\r\d"'s before the "ogin:--ogin:" in the chat script.  This
will send a few carriage returns and pauses to give the machine you
are calling a chance to get its act together and get a getty really
going before your machine tries to log in to it.  Hope this helps.

--
David Breneman     Sys Admin, Tacoma*Products, Inc. |  ____  ____  ____

 ..!uunet!stephsf!tacoma!dcb |"Stainless steel bolts are  |  /   ____/ /
CompuServe: 75760,1232       | ferrous but non-magnetic!" |

The examples the original poster gave were the output from Uutry.
"expect: (ogin:)" and "Call Failed: LOGIN FAILED" do not show up on
any of our systems during the use of a "cu" :-) . I emailed a response
similar to Ed's to the original poster, assuming his citing of the
"cu" command was a typo.  If this isn't the case, maybe he could
post a followup clarifying the situation...

--
David Breneman     Sys Admin, Tacoma*Products, Inc. |  ____  ____  ____

 ..!uunet!stephsf!tacoma!dcb |"Stainless steel bolts are  |  /   ____/ /
CompuServe: 75760,1232       | ferrous but non-magnetic!" |

        >>>
        >>>>STUFF DELETED...
        >>>    >expect: (ogin:)

        >>>    >expect: (ogin:)
        >>>    >Call Failed: LOGIN FAILED
        >>>    >exit code 101
        >>>    >Conversation Complete: Status FAILED
        >>>    
        >>>    One place to look is the gettydefs file on your target
        >>>    system. Your host is looking for (ogin:) out of your
        >>>    Systems file. If the target system describes the incoming
        >>>    getty (tty)  differently, ie never echos "login:" string,
        >>>    your cu could hang. Or I could be completely wrong.
        >>
        >>>            Later ... ed
        >>
        >>Ed is wrong.  The System file "chat script" is used for uucico
        >>connections.  When you use the cu command, the "chat script" is not
        >>used . . . the caller gets the login prompt and must respond.  An
        >>example of use of the the chat script would be to execute:
        >>
        >>        /usr/lib/uucp/Uutry -r machine_name
        >>
        >>With this you can watch the chat script.

        >The examples the original poster gave were the output from Uutry.
        >"expect: (ogin:)" and "Call Failed: LOGIN FAILED" do not show up on
        >any of our systems during the use of a "cu" :-) . I emailed a response
        >similar to Ed's to the original poster, assuming his citing of the
        >"cu" command was a typo.  If this isn't the case, maybe he could
        >post a followup clarifying the situation...

        Sorry all, my "cu" was a typo. sometimes my mind does not
        communicate directly with my fingers, replace "uutry" for "cu"

                Tanks ... ed