jm@wlbr.UUCP (06/06/84)
[]
Evidently, this didn't make it everywhere, so here it goes again...
(Sorry to everyone who has seen it before)
Erik Fair complains about V7 uucp timing out at shutdown when
communicating with a System V uucp. The problem also occurs with
4.x systems. Having studied this problem, I offer the following
detailed (and rather long winded) explanation, with some general
suggestions (but no details) on how to fix it.
This problem occurs because of the pk user mode emulation.
cntrl() exhanges HUPY messages, then calls pkclose(), which
tries to exchange M_CLOSE messages with the remote system.
The problem is that, in the user mode pk routines, pkclose()
does not wait for the reply from the other side. It merely
tries twice (sending two control packets), then "gives up",
and proceeds with the close.
As a result, two packets are left in the input queue of the
both hosts (this is true for all uucps that I know of). Now
then, cntrl() returns to main(), which tries to exchange
OO messages using imsg() and omsg().
imsg() uses the same message sync character as the pk routines.
Soooooo.... imsg() sees the M_CLOSE message that pkclose() left
on the line, and starts looking for a terminator (a NULL or
newline, I believe), and finds it after the two M_CLOSE messages
and the desired OO message, so he returns a bunch of garbage as
data. No biggee, main() discards the rubbish, sends another
OO message, and things go on correctly. That is why two V7 sites
work OK.
Now then, System V uucp has a new, improved imsg(). If he finds
an imbedded sync character while receiving a message, he will
reset some pointers, and start over again, throwing away the
garbage. So, a System V uucp will see the FIRST OO message,
and terminate without further hassle. This is fine on dialup
lines, because the line will be hung up before long, and this
will also terminate the V7 uucp. However, if the two are
connected with a hardwire line, the V7 uucp will wait around for
another OO message that will never come (until it times out).
There are several ways to "fix" the problem:
1) Fix the user mode pkclose(), so that he WAITS for a response.
This would really be the preferred fix, but.....
2) Fix the V7 (and 4.x) imsg() to conform to System V.
(Let's see now, how many thousands of sites was that????)
3) Break the System V imsg() to conform to V7 (Yeuchhh!!!)
4) Shorten the time that main() waits for imsg() to come back
with the OO message. (Blahhhhhh!!!!!!)
Not having a whole lot of time to come up with a solution, I chose (2)
at our site, so our hardwired systems work right.
Jim Macropol
{ihnp4,trwrb,vortex,scgvaxd}!wlbr!jmpiet@mcvax.UUCP (Piet Beertema) (06/15/84)
<...>
The uucico shutdown has always presented problems. Long time ago we
already added a "resync" in imsg.c, but there are more improvements:
- (cico.c) take out the first omsg('O', "OOOOO", Ofn) statement before
the loop;
- (cntrl.c) on HUP the slave shouldn't send another HY, so prepend the
WMESG(HUP, YES) statement by: if (role == MASTER)
--
Piet Beertema, CWI, Amsterdam
...{decvax,philabs}!mcvax!piethans@log-hb.UUCP (Hans Albertsson) (06/16/84)
[]
I get the same kind of problem here; I'm using 4.2 BSD uucp, more or less
"as is". ( Very few and unimportant changes, none at all in the code
affected) My neighbouring sites, erix and enea, use a version fixed up
at mcvax in Holland, ( known as EUUGD3R3 ) and my end sends a
OO message after a HUP message, and hangs...
No such problem with the PWB down the hall, over a 9600 baud direct.
One further detail; I'm not using a special driver for my autodialler,
letting the send-expect capability handle it all.
--
{decvax,philabs}!mcvax!enea!log-hb!hans
Hans Albertsson,
TeleLOGIC AB
Box 1001,
S-14901 Nynashamn,
SWEDEN