[comp.sys.pyramid] Solution to Problems with UUCP/modems.

duncan@comp.vuw.ac.nz (Duncan McEwan) (08/31/88)

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

jbm@uncle.UUCP (John B. Milton) (09/01/88)

In article <14170@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
...
>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).

What is the "acucntrl" program, and where did you get it?

John
-- 
John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu
home: (614) 294-4823, work: (614) 459-7641; CP/M to MP/M, MS-DOS to OS/2

csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/03/88)

>>We use our Quattro for both incoming and outgoing calls (using a version of
>>the "acucntrl" program).

>What is the "acucntrl" program, and where did you get it?

acucntrl is a little hack that comes with 4.3BSD. It is invoked by uucico when
it wants to make an outgoing call, to scribble on the tty data structures in
the kernel and keep init(8) from waking up. In other words, it provides dialin
and dialout on the same line.

Standard OSx does not provide acucntrl. The 4.3BSD version is highly VAX de-
pendent (what do you expect for a program that opens and writes on /dev/kmem?)
and needs a fair amount of hacking to make it work on a Pyramid. Several brave
souls have done this, including Romain Kang @ pyrnj and (apparently) someone
in New Zealand. Of course, 4.3BSD Tahoe has a port to the CCI Power 6/32.

Someday (*SIGH*) someone here will implement the Sun/Mt. Xinu fix that allows
real modem devices and provides portable goof-proof in/out calling. I've been
wanting to do that for some time. Unfortunately it is the kind of thing that
makes smaller existing customers happy, but isn't real meaningful to the large
customers who are buying machines tomorrow. So it has taken a back seat to
other development. :-( If, say, Southwest Bell (Hi Bruce!) were to threaten to
dump all their machines in the Mississippi if they didn't have dialin/dialout
capability, then it would get done tomorrow afternoon. :-)

<csg>

brian@ncrcan.UUCP (09/03/88)

In article <14170@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
> [stuff deleted]
>The (old) Quattro manual I have does not document this "feature" [modem
>changing parity of the received data] , 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?

No! He is not right.  No sane modem should mess with the data stream.  It's
purpose is to get the data across a communications channel *unchanged*.  If
I am on side A and send data at even parity I expect it to be received at the
other side also with even parity, not at the last parity that was used when
sending to the (broken) modem.  This is no feature, it is a bug!

No other modems I know of due this.  There may be some that allow this to
be configured (someone may want it), but it should not be forced upon you
because some designer thought that that's the way it should be done.

Brian.
-- 
 +-------------------+--------------------------------------------------------+
 | Brian Onn         | UUCP:..!{uunet!mnetor, watmath!utai}!lsuc!ncrcan!brian |
 | NCR Canada Ltd.   | INTERNET: Brian.Onn@Toronto.NCR.COM                    |
 +-------------------+--------------------------------------------------------+

scott@questar.QUESTAR.MN.ORG (Scott Anderson) (09/03/88)

In article <37899@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
> acucntrl is a little hack that comes with 4.3BSD. It is invoked by uucico when
> it wants to make an outgoing call, to scribble on the tty data structures in
> the kernel and keep init(8) from waking up. In other words, it provides dialin
> and dialout on the same line.
> Standard OSx does not provide acucntrl. The 4.3BSD version is highly VAX de-
> pendent (what do you expect for a program that opens and writes on /dev/kmem?)

I have been fighting the dialin-out problem here for a long time.  I
have finnaly come up with a solution that will work in just about
every case (ITP) I have seen, and reliably too!  

It consists of the putty(1) program written by Gene Olsen
here in Minneapolis.  This program is the best pre-getty program that
I have ever seen.  However, it still was not enough to deal with my
brain-dead modems.  If your modems can be set to drop the carrier
line for a few seconds after the real carrier goes away, then you can
use plain putty on the pyramid and still get the modem control.
My modems cannot be set to that mode...you have to either make the
CD track the real carrier or, just set it to be on.  The second case
is horrid because the chances of hanging the modem are *high*.  (I
also got the same effect by telling the ITP that carrier is always 
high).  Anyway, I have found a solution that works reliably for
my modems and I am happy with it.

If anyone is interested in my patches to the putty program for the 
Pyramid, I would be glad to send them.

-- 
Scott Anderson			UUCP: scott@Questar.MN.ORG,
Questar Data Systems			...!amdahl!bungia!questar!scott 
Minneapolis, MN			 ATT: +1 612 688 0089

dave@onfcanim.UUCP (Dave Martindale) (09/04/88)

In article <14170@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
>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.
>
>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.
>But he also claims the Quattro is behaving perfectly reasonably.
>Is he right?  How many other modems behave like this?

I believe that a modem's job is to get bits from one place to another,
without changing them.  I have never used any modem where it was even
possible to ask it to do parity-bit stripping in data mode.  Any modem
that decides to throw away some data bits by default is, in my opinion,
a piece of junk.  Without some sort of explicit instructions to ignore
the 8th bit, the modem *must* assume that all bits are data.

Parity stripping in command mode may be quite reasonable, but not in
data mode.

	Dave Martindale

evan@telly.UUCP (Evan Leibovitch) (09/04/88)

In article <37899@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
> >What is the "acucntrl" program, and where did you get it?
> 
> acucntrl is a little hack that comes with 4.3BSD. It is invoked by uucico when
> it wants to make an outgoing call, to scribble on the tty data structures in
> the kernel and keep init(8) from waking up. In other words, it provides dialin
> and dialout on the same line.
> 
> Standard OSx does not provide acucntrl. The 4.3BSD version is highly VAX de-
> pendent (what do you expect for a program that opens and writes on /dev/kmem?)
> and needs a fair amount of hacking to make it work on a Pyramid.

There is also a System V acucntrl which does the same thing, but not as
gracefully (?) as direct kernel diddling.

The program, with setuid root, checks to see if the port is in use from
a process besides getty (also looks for uucp LCK.* files). If free, the
program edits /etc/inittab to change the entry from 'respawn' to 'off',
and then kills the getty.

A different invokation undoes this - changes inittab back to respawn, and
calls telinit.

This worked steadily for me on a Convergent Megaframe, though I'm not
using it now.
-- 
Evan Leibovitch, SA of System Telly, located in beautiful Brampton, Ontario
            evan@telly.UUCP / {uunet!attcan,utzoo}!telly!evan
The advantage of the incomprehensible is that it never loses its freshness.

duncan@comp.vuw.ac.nz (Duncan McEwan) (09/05/88)

In <37899@pyramid.pyramid.com> csg@pyramid.com (Carl S. Gutekunst) writes:
>acucntrl is a little hack that comes with 4.3BSD. It is invoked by uucico when
>it wants to make an outgoing call, to scribble on the tty data structures in

An earlier version of OSx (3.?) supported uucico automatically invoking
acucntrl to do it's stuff if the keyword "inout" appeared in L-devices.  That
capability seems to have disappeared from OSx 4.?, so I have to invoke
uucico from a script with a call to acucntrl immediately before it.  This is
a right pain, since it complicates the way I have to do polling.  Why was
it taken out?

>Standard OSx does not provide acucntrl. The 4.3BSD version is highly VAX de-
>pendent (what do you expect for a program that opens and writes on /dev/kmem?)
>and needs a fair amount of hacking to make it work on a Pyramid.  Several brave
>souls have done this, including Romain Kang @ pyrnj

In fact, I think it is rather easier to make it work on a Pyramid than on
a VAX running 4.3.  The version I run, which came indirectly from Romain, but
which I modified slightly (can't remember why now -- its been a while)
has all the /dev/kmem stuff ripped out and replaced by an ioctl to the
itp driver to set hardwired carrier on.

I don't think the result behaves exactly like the 4.3bsd version, in that
after enabling software carrier any transition of the hardware carrier will
not be noticed.

Apart from that it seems to work reasonably well most of the time.
Occasionally if fails mysteriously - the acucntrl seems to succeed (ie
it doesn't write a diagnosic indicating the ioctl failed) but the following
invokation of uucico gets a "TIMEOUT ON DEVICE OPEN" error.  Not having
access to the source to the itp driver, I don't know if there any
circumstances in which the ioctl returns with a good status but didn't,
or perhaps hasn't yet enabled the software carrier.  Since it works
most of the time, I have never gotten around to investigating the problem.

>Someday (*SIGH*) someone here will implement the Sun/Mt. Xinu fix that allows
>real modem devices and provides portable goof-proof in/out calling.

That would indeed be a nice addition.

>If, say, Southwest Bell (Hi Bruce!) were to threaten to dump all their
>machines in the Mississippi if they didn't have dialin/dialout capability,
>then it would get done tomorrow afternoon. :-)

C'mon Bruce -- how about it, huh?  What's a few wet Pyramid's between
fellow users :-)

Duncan

jbm@uncle.UUCP (John B. Milton) (09/06/88)

In article <324@telly.UUCP> evan@telly.UUCP (Evan Leibovitch) writes:
>In article <37899@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
>> >What is the "acucntrl" program, and where did you get it?
>> 
>> acucntrl is a little hack that comes with 4.3BSD. It is invoked by uucico when
...
>
>There is also a System V acucntrl which does the same thing, but not as
>gracefully (?) as direct kernel diddling.
...

Fine, where can I GET this program?

John
-- 
John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu
home: (614) 294-4823, work: (614) 459-7641; CP/M to MP/M, MS-DOS to OS/2

cdold@starfish.Convergent.COM (Clarence Dold) (09/07/88)

From article <324@telly.UUCP>, by evan@telly.UUCP (Evan Leibovitch):
> There is also a System V acucntrl which does the same thing, but not as
> gracefully (?) as direct kernel diddling.
> 
> This worked steadily for me on a Convergent Megaframe, though I'm not
> using it now.
The uucp package on Convergent SysV (CTIX 5.x) includes a 'uugetty', that I 
didn't think was Convergent exclusive.  It does everything that acucntrl
appears to do, for cu and uucico.  C-Kermit doesn't agree with it, though.
It works rather simply, by looking for lock files, the contents of which
are the owning process id.  If that process id is not active, the lock is
removed.  ct, cu, uucico, and uugetty all are suid uucp, and cooperate in 
this scheme.

-- 
Clarence A Dold - cdold@starfish.Convergent.COM		(408) 435-5274
		...pyramid!ctnews!mitisft!professo!dold
		P.O.Box 6685, San Jose, CA 95150-6685

pst@comdesign.CDI.COM (Paul Traina) (09/07/88)

From article <692@starfish.Convergent.COM>, by cdold@starfish.Convergent.COM (Clarence Dold):
| The uucp package on Convergent SysV (CTIX 5.x) includes a 'uugetty', that I 
| didn't think was Convergent exclusive.  It does everything that acucntrl
| appears to do, for cu and uucico.  C-Kermit doesn't agree with it, though.
| It works rather simply, by looking for lock files, the contents of which
| are the owning process id.  If that process id is not active, the lock is
| removed.  ct, cu, uucico, and uugetty all are suid uucp, and cooperate in 
| this scheme.

I just upgraded one of our SsyV systems to Honey-DANBER uucp, and it turns
out all you need to do to make C-Kermit work properly with uugetty/uucico/etc.
is to recompile ckutio.c with -DATT3BX.  This makes locks go in /usr/spool/locks
and inserts the pid of the kermit process into the lock file.

This switch should be renamed to something like -DHDBUUCP or somesuch.

					Happy Hacking,
						the PST
-- 
Paul Traina				To believe that what is true for
{uunet|pyramid}!comdesign!pst		you in your private heart is true
pst@condor.cdi.com			for all men, that is genius.

dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (09/08/88)

My new Prime EXL316 also came with a uugetty that is supposed to handle 
this correctly.  The technique appears to be a combination of lock
files, and serial drivers that have two entry points to each device (as
apparently exists in Sun systems: ie.  normally, you can't write to a
serial device that doesn't assert DCD.  By adding 128 to the minor 
number of the device, you can mknod a new special file that ignores 
Carrier.  Since uugetty doesn't attempt to login until it sees chars,
uucico can grab the other device and lock uugetty out.  

I'm not clear on this for one reason:  The EXL doesn't support pin 8 in 
their rs232 connection, and their official cable ties pin 8 to pin 6.  I
think this is why I haven't gotten it to work properly with my TB modem
yet.  Anybody else out there have a Prime unix box that they've gotten
bi-directional modem lines to work on?

	Thanks in advance
	--Dan

Daniel A. Graifer			Franklin Capital Investments
uunet!fciva!dag				7900 Westpark Drive, Suite A130
(703)821-3244				McLean, VA  22102
-- 
Daniel A. Graifer			Franklin Capital Investments
uunet!fciva!dag				7900 Westpark Drive, Suite A130
(703)821-3244				McLean, VA  22102

cdold@starfish.Convergent.COM (Clarence Dold) (09/09/88)

From article <520@comdesign.CDI.COM>, by pst@comdesign.CDI.COM (Paul Traina):
> From article <692@starfish.Convergent.COM>, by cdold@starfish.Convergent.COM (Clarence Dold):
> | The uucp package on Convergent SysV (CTIX 5.x) includes a 'uugetty', that I 
> | appears to do, for cu and uucico.  C-Kermit doesn't agree with it, though.
> I just upgraded one of our SsyV systems to Honey-DANBER uucp, and it turns
> out all you need to do to make C-Kermit work properly with uugetty/uucico/etc.
> is to recompile ckutio.c with -DATT3BX.  This makes locks go in /usr/spool/locks
The problem I had with this scheme if I recall correctly, is that kermit had
to be suid uucp, in order to kill uugetty, a step in the outbound dialing.
If this was true, a shell spawned from kermit carried the effective id
of uucp, endangering some security.  A shell spawned from cu gives the 
original uid, rather than uucp. I thought I could hack the code, but gave up.

C-Kermit, 4E(070) 29 Jan 88, AT&T System III/System V

I never even looked at -DATT3BX.  I read from your message that this should be
a separate compile, outside of defining ATT3BX to the full Makefile.
I'll try that, but I wanted to post back to the net first, to avoid someone
inadvertently leaving a hole in security. 
-- 
Clarence A Dold - cdold@starfish.Convergent.COM		(408) 435-5274
		...pyramid!ctnews!mitisft!professo!dold
		P.O.Box 6685, San Jose, CA 95150-6685

jbm@uncle.UUCP (John B. Milton) (09/13/88)

In article <421@fciva.FRANKLIN.COM> dag@fciva.UUCP (Daniel A. Graifer) writes:
...
>yet.  Anybody else out there have a Prime unix box that they've gotten
>bi-directional modem lines to work on?
...
I modified a program that was posted to the net a while back "modem-ctl". I am
using this program on a UNIXpc connected to a TB. I did not know about the
+128 tty device until after I finished. All the line access is done by opening
the line with O_NDELAY, doing an ioctl() with CLOCAL turned on, then a fcntl()
to turn off O_NDELAY so things work right again. Neat trick.

This program is run by init. It talks to the modem to set it up to answer a
call, right now using HAYES commands. It spends most of it's time hanging in
a read waiting for "RING". After each character it reads, it does an access()
to check for the lock file. If it sees a lock file, it immediately exits.
There are a few side effects to this. As long as this program has the line
open, any other program can come along and open the line, a uucico for
example. When the program exits, init repawns it, and it comes back and finds
a lock file. This time it just waits for the lock file to go away, opens the
line, talk to the modem and waits.

If it gets the RING, it sends ATA to answer the phone, waits a while for
CONNECT xxx, then the fun part. Based on the xxx, it fork() & exec()s an:
/etc/getty -h xxx /dev/ttyzzz
The /etc/gettydefs needs to adjusted a little. As you Bezerkers can tell this
was written for SYSV. What I have seen of BSD termio(7) would make this easier.

A while ago I promissed to post this unix-pc.sources, but what I think I want
to do now is a beta test. All volunteers e-mail me.

Describe your hardware (# of ttys,etc.)
Phone lines (direct, PBX, Datakit, etc.)
Modems (HAYES, TB, etc.)
OS (SYSV, XENIX, BSD)
Typical users (kind, load)
Current setup (weirdness you use for two-way lines)
How much time you have to goof around with it
Whether or not you have a diff that can produce -c (context) diffs
A good e-mail address

I will try to select a good test cross section (or all of you if I only get a
few :). I have a few things to clean up, so I should be ready by the time I get
replies.

If anyone out there has experience with modem-ctl, even if you're not interested
in participating, please drop me a line. BTW the name of the program will (so
far) be prtty (pre tty) I was going to call it pretty, but there is already
a program in the archives by that name.

John
-- 
John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu
home: (614) 294-4823, work: (614) 459-7641; CP/M to MP/M, MS-DOS to OS/2