Summary: uucico / cu / tip problems...
========================================
Hello Sunmanagers,
Last week, I sent a mail about uucp / uucico / tip problems to the list.
I received several answers. Most of them were very interesting, even if they
did not solve my problem.
I'll summarize all the answers, and add my own comments after ">>>" marks ...
Thanks to :
gc@fox.gsfc.nasa.gov (Gary Chatters)
"Andrew Luebker" <aahvdl@eye.psych.umn.edu>
Bob Beason <BEASON@geneseo.bitnet>
fabrice@sj.ate.slb.com (Fabrice Guerini) (2 times!!!)
Mike Raffety <miker@sbcoc.com>
cfoley@arsenic.cray.com (Chuck Foley)
seidc!gwolsk@mips.com (Guntram Wolski)
ray@isor.vuw.ac.nz (Ray Brownrigg )
By the way:
If anybody on the list has older summaries about uucp/uucico,
he may send them to me.
I'm intresetd in EVERY problem (and solution!!) regarding this subject,
since my experience is that you need a lot of tips and tricks to get some
connections work!!!
The ones that work 'by the book' are mostly an exception!
Problem description:
--------------------
"uucico" (or Uutry, cu -d, ...) to different foreign sites always returns
with a "timed out" the first time this command is executed.
When I immediately try a second time, it seems that information (=login
prompt, ..) from the previous session, interferes with the chat-script of
this uucico command.
Altough the first uucico returns with a "status failed", the modem succeeds
in making a good connection!
Here is the log of this first "cu -d" command:
> 1 franklin# cu -d redacbe
> conn(redacbe)
> Device Type ACUMTR wanted
> mlock cua1 succeeded
> fixline(6, 9600)
> processdev: calling setdevcfg(cu, ACUMTR)
> gdial(mtr) called
> expect: ("")
> got it
> sendthem (DELAY
> <NO CR>AT&W1Z^M)
> expect: (OK^M)
> AT&W1Z^M^M^JOK^Mgot it
> sendthem (ECHO CHECK ON
> <NO CR>A^JATTDDPP0000,,,,,,3311..............7711^M^M)
> expect: (CONNECT 9600 RELIABLE)
> timed out
> set interface UNIX
> getto ret -1
> Call Failed: CALLER SCRIPT FAILED
> Connect failed: CALLER SCRIPT FAILED
> call cleanup(1)
> call _mode(0)
> script done on Fri May 22 09:12:36 1992
>
IMMEDIATELY after the first cu, I tried a second time.... With following
strange results (Notice the mixture of this second cu-chat, with replies
from the remote computer, which was still connected from the previous
cu command!!!):
> cu -d redacDB
> conn(redacDB)
> Device Type ACUMTR wanted
> mlock cua1 succeeded
> fixline(6, 9600)
> processdev: calling setdevcfg(cu, ACUMTR)
> gdial(mtr) called
> expect: ("")
> got it
> sendthem (DELAY
> <NO CR>AT&W1Z^M)
> expect: (OK^M)
> ^M^JCONNECT 9600 RELIABLE^M^J^M^Jacb login:
> ^M^Jacb login:
> ^M^JTelephone number:^M^JTRY AGAIN^M^Jacb login: ^M^Jacb login: timed
out
> set interface UNIX
> getto ret -1
> Call Failed: CALLER SCRIPT FAILED
> Connect failed: CALLER SCRIPT FAILED^M
> call cleanup(1)^M
> call _mode(0)^M
A "tip" to that host, and with exactly the same parameters as specified in
the previous chat scripts works without any problem!
# tip cua1
connected
AT &W1Z = load the factory defaults, don't save in novram.
AT DP ...number... = dial the number with the factory default settings.
= No other specific settings changed!!!
(... after +- 50 sec. .....)
CONNECTED 9600 RELIABLE = a connection at 9600bd, MNP5
<CR>acb login: .....
Password: .....
Last logn: Wed May 13 11:58:07 on ttyd0
SunOS Release 4.1.1 (REDACBE-SL) #3: Mon Oct 7 10:53:09 MET 1991
...
===> THE CONNECTION WORKS ...
I can systematically reproduce this result. The first time always fails,
the second time, I see the "cu" commands interfering with the active
remote session from the previous cu command...
It seems to me that cu (and also uucico) has a built in timeout, so that
it disconnects from the modem (which is still trying to make a connection!)
with a "timed out" message, even before the modem fails (or succeeds!!).
The Answer:
-----------
There *IS* a time-out in all of the uucp (Uutry, cu ...) commands!!!
When a certain reply doesn't come fast enough, the command returns with the
message "timed out".
You can intercept the problem by changing the "expect-send" sequence!
As an example, the next expect-send sequence waits for the 'login:' prompt,
sends a Carriage-return/Linefeed if it doesn't get it, and waits again for
the new 'login:' prompt.
cuuxb Any ACU 1200 chicago8101242 in:--in: nuucp word: panzer
This is common use in the /etc/uucp/Systems file,
AND CAN ALSO BE USED IN THE /etc/uucp/Dialers FILE !!!!!!!!!!!
This was my OLD entry in the dialers file:
mtr =,-, "" \dAT&W1Z&E4\r\c OK\r \EATDP\T\r\c CONNECT\s9600\sRELIABLE
... and this is the new-one:
mtr =,-, "" \dAT&W1Z&E4\r\c OK\r \EATDP\T\r\c CONNECT\s9600\sRELIABLE-\c-CONNECT\s9600\sRELIABLE
It solves the problem!!!
When the "CONNECT 9600 RELIABLE" message didn't came fast enough, cu/uucico
returns with a "timed out".
By specifying the expect string a second (3rd, 4th, ..?...) time, you have
more chance receiving the modems return message.
Other suggestions:
------------------
From: gc@fox.gsfc.nasa.gov (Gary Chatters)
Dirk,
I don't know exactly what your problem is but I had a terrible
time setting up some UUCP connections. Here is what I traced it
to:
1. For an incoming connection uucico was crashing with a core dump.
This was caused by invalid lines in the /etc/passwd file, such
as blank lines or "comment" lines. (This does not seem like
it would have anything to do with your problem.)
2. For an outgoing connection uucico would connect, then do nothing.
After a timeout period it would say that the connection failed.
The modems would still be connected. This was solved by sending
a newline at the end of the chat script in /etc/uucp/Systems.
That is, insert \n after the password, which was the last
entry in the chat script. (This does seem to have some
similarity to your problem.)
Gary
------------------------------------------------------------------------
Gary Chatters Internet: gchatters@cen.com
Century Computing, Inc. UUCP: uunet!cen.com!gchatters
1014 West St. Voice: 301-953-3330
Laurel, MD 20707 FAX: 301-953-2368
------------------------------------------------------------------------
From: "Andrew Luebker" <aahvdl@eye.psych.umn.edu>
When the "cu" call fails, is the modem somehow set to respond
in "terse" (AT...V0) rather than "verbose" (AT...V1) mode?
That might explain why you never get the lengthy message
(CONNECT 9600 RELIABLE)
even though the connection is clearly established!
>>> Indeed, it can cause problems...
>>> To be sure, I checked it with a serial line analyzer what exactly was
>>> sent to the modem and what the modem sends back.
>>> The problem was not the message that didn't came trough, but that it
>>> came much too late.
Check for INITIALIZATION and "FINALIZATION" Hayes command
strings in both the "tip" and "cu" programs.
I think "tip" does some finalization that can be undesireable.
(Or maybe it was intialization?) For example, it re-sets
your modem to automatically answer on the 1st ring, etc.
>>> The line analyzer didn't show any initialization/finalization when I
>>> executed tip, but that is because I had a VERY SIMPLE /etc/remote
>>> entry (cua1:dev=/dev/cua1:br#9600:).
From: Mike Raffety <miker@sbcoc.com>
Other than the fact you say this modem already works with other
systems, I'd say your modem isn't getting the dropped DTR signal
that the Sun should be sending when you close the port (causing
the modem to hang up). Is this possible?
>>> YES, a modem should always respond to a dropping DTR, but this
>>> "lucky" incident proved me that a connection was succesfully established,
>>> and that the modem didn't cause the problem;
>>> That's why I suspected uucico/cu to cause the trouble...
>>> By the way, I am very anxious about the reason why it did not respond to
>>> DTR. It could become rather expensive if a call stays open during a
>>> week-end!
cfoley@arsenic.cray.com (Chuck Foley)
A number of high speed modems take more time to sync up then either tip or
cu allows. If you put "dialtimeout=120" in a ".tiprc" file, and the do the
tip as "root" (as a test), I bet you get the connection you are trying. The
problem is, that the "dialtimeout" option is only accepted in the ".tiprc"
file for root. We had, at one time, modified tip to expand this to all tip
users...
As far as the session continuing after tip/cu gives up, your modem is apparentlynot set up to reset after the Sun drops DTR...check the modem settings and or
cable pin-out.
Chuck
-----
Chuck Foley Voice: (301) 595-2624
Americas Network Manager FAX: (301) 595-2637
Cray Research, Inc. Home: (410) xxx-xxxx (Emergency)
4041 Powder Mill Road - Suite 600 Internet: cfoley@arsenic.cray.com
Calverton, MD 20705 UUCP: uunet!cray!arsenic!cfoley
From: fabrice@sj.ate.slb.com (Fabrice Guerini)
...
Observe the message: "CONNECTED 9600 RELIABLE"
...
Now, observe the *expected* message: "CONNECT 9600 RELIABLE"
May I point out the difference:
"CONNECTED 9600 RELIABLE"
"CONNECT 9600 RELIABLE"
This may be where your problem lies.
>>> Thanks for your sharp eye. It is indeed a common mistake to misspell
>>> these kind of things.
>>> I immediately checked my uucp-configuration files! ... they were correct!
>>> This time, I made the mistake in typing my mail.
>>> Some of the messages I gave were typed in manually, some of them were
>>> logged with a script command or with the Uutry command.
>>> These last ones were correct ...
...
...
There may be two possible kinds of delays introduced here. One of them,
you can do something about it. Your command reads:
> ...*... ATDP 00,,,31499893071
^^^
You may want to try to reduce the number of ',' or the value associated to it
in your modem. Of course, if you don't get the secondary dial tone soon
enough, you are doomed. If you do, then you will have reduced the total
delay accordingly. This may be enough.
The second delay could be related to what modem you are talking to. If you
call a Telebit that sends you PEP tones first before the V.32, your V.32
tones may come too late for 'cu' or 'uucico'.
Short of this, I don't know how to change the timeout value in these two
programs.
Hope it helps anyway.
Regards,
-- ,
Fabrice Guerini DOMAIN : fabrice@sj.ate.slb.com
Schlumberger Technologies - ATE UUCP : {amdahl,decwrl,uunet}!sjsca4!fabrice
San Jose, CA 95110 BELL : (408) 437-5114
From: seidc!gwolsk@mips.com (Guntram Wolski)
...
> Does anybody know about the existence of this timeout, and if yes,
> how can I change this value?
I suspect the same thing since I have encountered it as well when
waiting a long time for connects.... I'm going to be curious what
you find out (Especially if you have a workaround for uucico!)
--G
-- Guntram Wolski gwolsk@sei.com>>> ... Here's the summary ... I hope it will do ...
From: ray@isor.vuw.ac.nz ... I don't believe you can alter the timout for cu/uucico, but you can get around your particular problem by putting a pause into the send/receive script. This would be something like:
"" \dAT&W1Z&E4 OK atdp0,31499893071\r\d\d\d\d\d\c CONNECT ^^^^^^^^^^^^^^ This is the trick, you give the modem a carriage return, to let it get on with making the connection, but the 2-second delays (as many as you want), give the connection time to go through BEFORE the timout starts when looking for the CONNECT message.
Hope this helps
Ray Brownrigg ray@isor.vuw.ac.nz
>>> ... It works indeed!! I implemented it a bit differently in the >>> Dialers file, and it surely works!!! >>> THANKS A LOT.
>>> >>>Many thanks to all the people that responded... >>>
With kind regards, Dirk.
+------------------------------------------------------------+ | Dirk Somers, System Administrator Workstations. | | AGFA-Gevaert, R&D, EBS department. | | Mechelse Steenweg 430, B-2650 Edegem (Antwerp) BELGIUM | +------------------------------------------------------------+ | Tel.: +32 - 3 444.62.03 | d_somers@roam.agfa.be | | Fax.: +32 - 3 455.45.17 | frankli!d_somers | +------------------------------------------------------------+
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:42 CDT