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 ...

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!

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!!!):

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.

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.)

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.

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.

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.