Solution to Problems with UUCP/modems.

[Duncan McEwan]

Some months ago, I posted a description of a problem that we were having with
dialup UUCP connections between our Pyramid and various other machines
(including another Pyramid, an ICL Clan, and a VAX 750 running Ultrix).  I
received a few suggestions, but unfortunately nothing that solved the problem.

After investigating the problem intermittently since then, I think I can
explain what was happening.  My apologies for the length of this article, but I
decided to post it because a) it may help others who encounter similar
problems, and b) there are still some unanswered questions that somebody on the
net might be able to help with.

My original article was only posted to comp.sys.pyramid, but since the problems
turned out to be modem related, I am crossposting this to comp.dcom.modems.
For the benefit of readers of comp.dcom.modems who didn't see my original
posting (and for readers of comp.sys.pyramid who have forgotten it), the
following is a brief description of the problem.

Many calls (both incoming and outgoing) between our pyramid and one of our
neighbours would start up fine, get through the login and selection of the 'g'
protocol OK, then sometime later fail, always apparently in the same way.  Our
uucico would write the message "Alarm while reading SYN - RXMIT" repeatedly at
approximately 10 second intervals until either it, or the remote uucico gave up
and hung up the phone.

The modem on our side was a Quattro SB2422.  This is a "hayes compatible"
V22bis 2400 bps modem, made (I think) by a UK company called "Dowty
Electronics".  I don't know if it is sold in the U.S.  The remote site's had
various modems including Quattro's, MultiTech 224e's and SendData Quad's.  The
above symptoms would occur intermittently (though on occasions on up to 50% of
the calls) between any of the above modems and our Quattro.

It turned out that there were 3 problems, each causing calls to fail
at different stages.  The failure could occur

1) during the initialisation of the 'g' protocol (during the INITA/B/C
   exchange)

2) immediately after the 'g' initialisation, during the negotiation of the
   first file transfer or line turnaround.

3) at some random point during the transfer of a data file from our pyramid
   to the remote system.

The third case was slightly different, in that although the RXMIT error's
were repeated a number of times the uucico's sometimes managed to recover
and continue transfering data.  It was also the easiest to solve because we
could easily see what was happening on a line monitor between our pyramid and
the Quattro, so I will describe what was causing it first.

We use our Quattro for both incoming and outgoing calls (using a version of the
"acucntrl" program).  Because of the way the Quattro only autobauds on "at"
commands, we have found it easiest to have it permanently set up to talk to the
pyramid at 2400bps ("constant speed interface" turned on).

I knew that with the constant speed interface enabled the modem might have to
use flow control on the pyramid<->modem line if it connected to a modem running
at less than 2400bps.  I also knew that when uucico was running xon/xoff was
disabled, and since none of our terminals had rts/cts flow control enabled, any
flow control it tried to use would be ineffective.  But I also thought this
wouldn't matter because the 'g' protocol would provide sufficient flow control.

But from what we saw on the line monitor that appeared not to be the case.  The
result was many incomplete packets being received by the remote host which it
did not ack, and hence lots of RXMIT messages.  If the same packet had to be
retransmitted too many times our uucico would give up.  The solution was to
tell the modem to use rts/cts and to enable rts/cts on the tty line connected
to the modem.

The second problem only occurred when a call was between a Quattro and a
MultiTech 224e modem.  From tests I have run, it appears that when a sequence
of approximately 20 null's is sent from the DTE connected to the Quattro to the
one connected to the MultiTech one or two often (but not always) get dropped.
A line monitor shows them on the serial line going into the Quattro but not on
the line out from the MultiTech!

Not surprisingly this behaviour upsets UUCP!  Immediately after initialisation
of the 'g' protocol, the transmit buffer is null filled.  If the first message
after 'g' initialisation from the uucico on the Quattro side is a short one,
some of the null's in the 64 byte packet that is sent get lost.  So the remote
uucico does not see a valid packet.  One reason the first message from the
Quattro to the MultiTech may be short is if uucico on the Quattro side made the
call, but has no work for the remote.  In this case it sends a 64 byte message
containing an "H" followed by 63 nulls.

I have used two different Quattro's (one on our machine and one on a
neighbours) and two different MultiTech's (again one on our machine and one on
a (different) neighbour) and observed the same behaviour in each case.  It does
not happen between two MultiTech's, or two Quattro.

Until we figure out which modem is at fault and try to get it fixed we just
have to avoid the Quattro/MultiTech combination.  Has anyone ever experienced a
problem like this?  Can anyone offer advice on how to track down which modem is
to blame?

The last problem that we solved was made more difficult because the symptoms
seemed exactly like the second problem.  But they couldn't be caused by null
bytes being dropped because they occurred during the INITA/B/C sequence at the
start of the 'g' protocol.  Those messages are short (8 or so bytes each) and
do not contain sequences of nulls.

What we actually saw on our line monitor was an INITA message from the remote
uucico to ours, and an INITA from ours to theirs.  This was followed
immediately an INITB from the remote, but nothing from us.  After a short time
we sent another INITA, which they responded to with another INITB.  This was
repeated several times until one of the uucico's gave up and hung up the line.

The INITA messages from both ends looked identical, which led us to believe the
problem was with our pyramid (either its uucico, or less likely, faulty
hardware).  It wasn't until we looked at the parity bit that we saw the real
problem was that our Quattro modem was converting the INITA message from the
remote site to even parity.  So the packet our uucico was seeing was invalid.

We were still puzzled by the fact that the modem did not behave like this every
time.  It turns out that the Quattro determines both the terminal baud rate
*and parity* from any "at" command.  When in data mode it converts all data
from a remote modem to the parity determined this way.

Fortunately there is a workaround.  If the "at" command is sent with space
parity the Quattro allows all 8 bits through untouched.  Pyramid's uucico sends
all it's "at" commands with space parity, so every time we made an outgoing
UUCP call the modem would be set into a state that would allow the 'g' protocol
to work correctly.  "Tip" on the other hand uses even parity by default, so
whenever we used it, the modem would be put into a state where it clobbered the
8th bit.  We have now changed /etc/remote so all the entries specify space
parity, but I don't know what we will do if we encounter a host that requires
some other parity.

The (old) Quattro manual I have does not document this "feature", but I have
spoken to one of the distributors engineers who says his manual does.  As a
small consolation for all the time I spent trying to track the problem down, he
is sending me a copy of the updated manual!  But he also claims the Quattro is
behaving perfectly reasonably.  Is he right?  How many other modems behave like
this?

Duncan