jorgnsn@qucis.queensu.CA (John Jorgensen) (05/24/91)
Yesterday, I asked for help getting HoneyDanBer UUCP to work with a
Gandalf V.32 modem on a Sun IPC. Incoming calls were working fine,
but when I tried to originate a call, uucico complained about:
Alarm while looking for SYN -- request RXMIT
unless I disabled the modem's MNP error checking.
Well, I've solved the problem with your help, though I still don't
understand precisely what was happening. The short answer is, put
"" P_ZERO
into the /usr/etc/Dialers file before _any_ characters are sent to the
modem. My Devices entry now reads:
gandalf =,-, "" P_ZERO "" \dA\pTE1V1XQ0S2=255S12=255\r\c OK\r \EATDT\T\r\c CONNECT
Now the long story, for those who are interested.
Shortly after I posted my question, I found out that the problem was
not with flow control, as I had originally guessed, but with parity.
We have source for an old implementation of UUCP, and it revealed that
the SYN character uucico was looking for has the value \020 (even
though "man 7 ascii" says SYN is octal \026). So I compared trace(1)
output from uucico with MNP enabled and disabled, and discovered that
while the MNP-disabled trace did show reads of \020, the MNP-enabled
trace showed reads of \220 at the same points--\020 with its high bit
set. "stty everything > /dev/cua0" showed that uucico had set the
line for 8 bits, no parity, and the modem setting was set for 8 bits,
no parity; yet the modem insisted on outputting 7 bits even parity
when MNP was enabled.
So I tried putting various combinations of "P_ZERO", "P_EVEN", and
"STTY=this,that,theother" commands into my Systems chat script, with
no effect. I finally took a closer look at the uucico traces,
thinking uucico must be sneaking some extra commands to the modem. I
noticed that even though uucico opened the modem line without parity,
it was simulating even parity in software during the dialing and login
sequences (i.e. instead of writing "ATDT", it wrote "A\324D\324").
Presumably, uucico handles parity itself until the login sequence is
over so that it can open up an 8 bit line, but get past any getty and
login processes that insist parity be set. The P_ZERO, P_EVEN, and
P_ODD tokens in chat scripts seem to affect uucico's software parity
handling, while STTY=parenb actually produces the ioctls to change the
line characteristics.
When I moved the P_ZERO to the very beginning of the Dialers entry, so
that uucico sent no characters with parity set in the modem commands,
the modem stopped sending its output with even parity. Presumably if
MNP is enabled and this modem sees characters with their high bits set
while it's in command mode, it decides that the DTE is running 7 bits
even parity, and resets itself accordingly, regardless of how you set
its switches. That explanation is just a hypothesis, though, and I'm
still not certain why we didn't have similar problems on the 3/50
running SunOS 3.5.
Many thanks to the people who replied.
Jim Knutson <knutson%sw.mcc.com@mcc.com> replied within an hour with
the suggestion to add P_ZERO to the expect/send scripts.
Unfortunatley it took me a while to find the right place to put it.
Mark McDonald <apex!markm@uunet.UU.NET> had the answer in the example
he sent of a working Dialers file.
John Palkovic <palkovic@linac.fnal.gov> gave me tips on how to set up
RTS/CTS flow control on the remote end as well as the sending side (I
hadn't realized you could put arbitrary stty commands in
/etc/gettytab).
Jonathon Clark <jhc@ulysses.att.com> suggested I should turn flow
control off completely, to avoid any problems with XON/XOFF.
<jan@eik.ii.uib.no> and G. Roderick Singleton <gerry@jtsv16.jts.com>
both suggested I just leave MNP off, since UUCP does its own error
control, flow control, and buffering. Actually, our first response
here was to leave MNP off on on both the professor's home modem and
our machine room modem. The problem was that a third site started
having frequent failures when they called our machine room. So we
reenabled MNP on the machine room modem, and then the home machine
started failing fairly often (possibly because it couldn't always
negotiate a protocol with the machine room modem?). John Palkovic
had another suggestion to avoid overlaying two error-protection
protocols: use MNP and UUCP's e protocol. Because I don't understand
MNP well enough to know if it is absolutely reliable, I'm sticking to
UUCP's g protocol for now.
--
John Jorgensen jorgnsn@qucis.queensu.ca (613) 545 6784
Systems Programmer, Dept. of Computing Science, Queen's University