Troubleshooting uupc sessions

Symptom:  uupc can't place a phone call to your neighboring site.

Possible cause:  Systems file is malformed.  Re-read the documentation and
check the file.  If necessary, run uupc with a debug level of 5, and watch
the screen as uupc parses the lines in the file and tries to make sense of
them.  You may be able to figure out where the problem lies.

Possible cause:  you have specified the HAYES dialer, and your modem is not
Hayes-compatible.  Try using the DIR "dialer", which isn't a dialer at all...
it simply opens a serial-port connection and then starts running the chat
script.  You can use the chat script to dial your modem.


Symptom:  uupc dials the phone, your neighbor's modem answers, but uupc
reports "Login failed".

Possible cause:  the send/expect strings in the chat script are not correct.
Run uupc with a debug level of 5, observe what uupc expects to receive from
your neighbor's system and what it really receives, and edit your send/expect
strings to suit.  You may need to add some delays, or change the expect
timeout, or add some try-again strings.

Possible cause:  speed-switching problems.  You have configured the serial
port to a higher speed than that of the modem-to-modem link (e.g. you specified
9600 in the Systems file, and the modem which actually answers speaks only
at 2400 bits/second).  Your modem is reporting the actual speed of the
connection in its CONNECT message (e.g. "CONNECT 2400").  Either uupc is
switching its serial-port speed to match that of the CONNECT message, and
the modem isn't (solution: specify the dialer as HAYES! or HAYES!options,
rather than as HAYES or HAYES+options)... or, the modem is switching speeds,
and uupc isn't (change your HAYES! dialer specification to HAYES or
HAYES+options, or change your HAYES!options specification to include
an option to instruct the modem not to switch speeds).


Symptom:  uupc establishes a connection, but never says "Startup"

Possible cause:  uucp misconfiguration at your neighbor's site.  Run uupc
with a debug level of 5, and make note of what your neighbor's system
says after uupc logs in.  Take this information to your neighbor's
sysadmin.

Possible cause: noisy phone lines.  The early stages of the uucp protocol
negotiation are not protected by the 'g' protocol and can be disrupted
by line noise. Try again.

Possible cause:  your connection to your neighbor's system is not to a
hardwired serial port, but to a network terminal server.  The server is
not passing data through to the system you're calling until it sees a
carriage-return.  uucp 'g' packets don't have carriage returns.  Ask your
neighbor sysadmin how to instruct the terminal-server to go into
"download" or "transparent" or "push" mode, and add the necessary
commands to your chat script.


Symptom:  uupc gets through the Startup phase, and the conversation fails
immediately thereafter:  either the phone hangs up, or uupc starts reporting
"header checksum error" and disconnects due to an excessive error count.

Possible cause: You have specified a large-packet 'g' protocol connection,
and are talking to a system which cannot construct large packets without
scrambling the packets or dumping core and aborting.  Revert to a
standard-sized-packet session (64 bytes), or try 128-byte packets.


Symptom:  uupc gets through Startup phase, starts sending or receiving
files, and the file transfer halts part way thorough one file.  The
session finally ends in an excessive-error-count disconnection.

Possible cause: extremely noisy phone line is overwhelming the 'g'
protocol's error-recovery capability.  Try a different phone line.

Possible cause: one of the modems involved in the communication is
configured for XON/XOFF flow control, an XOFF character was transmitted
as part of a 'g' protocol packet, and the modem has interpreted this as
a "stop sending data" command.  Reconfigure the modems... the 'g'
protocol is entirely incompatible with XON/XOFF flow control.

Possible cause: you have specified a larger-than-normal 'g' protocol
window (e.g. 7 packets).  Your neighbor system has agreed to a larger window,
but can't really handle it... your neighbor's serial-port buffers are
overflowing.  Switch back to a 3-packet window.


Symptom: files are transferred properly, but throughput is poor.

Possible cause: neighbor system is overloaded.  Try calling later.

Possible cause: noisy line, leading to many retransmissions.  Try calling
later.

Possible cause: you are running LocalTalk, and its interrupts and SCC
polling are causing your modem port to drop characters, leading to
excessive retransmissions.  Turn off LocalTalk while running uupc, or
switch to a lower serial-port speed.

Possible cause: you are running a standard 'g' protocol connection (3-
packet window, 64-byte packets) over an MNP or V.42/V.42bis modem
connection.  MNP or V.42 is slowing down the ACK packets enough to lead
to protocol stalling.  Turn off MNP or V.42/V.42bis, or try a larger
window or packet size.

Possible cause: you are communicating with a Mac/gnuucp system.  Mac/gnuucp
(up through version 4.6 at least) supports only a one-packet window,
and is limited to about 200 bytes/second of throughput no matter how
fast your modems may be.  Install uupc 3.0 at the affected system.

Possible cause: you are transferring files using the 'f' protocol, over
a connection which is not "almost error-free".  The entire file is being
retransmitted several times.  Switch to the 'g' protocol, or use an
error-correcting protocol such as MNP or V.42/V.42bis.


Symptom: you instruct uupc to call "Sites with jobs pending" or "Per
schedule file", and it doesn't call one or more sites which have jobs
pending or which appear to be due for a call.

Possible cause: the time-of-day restrictions in the Systems file forbid
calling the site(s) in question at this time.  Wait until later, or edit
the Systems file and remove the time restrictions.

Possible cause: the entry in the Schedule file may be in error.  Check it
and correct it if necessary.

Possible cause: one or more failed attempts to call the site(s) in question
have triggered the failed-call fallback algorithm, which forbids calling
a site for 5 minutes after the first failed call, 10 minutes after two
failed calls, 20 minutes after three, and so forth.  Force a call to the
affected system by selecting its name from the Call menu (this overrides
the fallback algorithm), or add a specific fallback time to the appropriate
line in the Systems file, or throw away the "ST.systemname" status file
in the spool folder.