uucp to sun

[John C. Archambeau]

don at dksfr.UUCP (don kossman) writes:
>we've had a uucp link for a couple of years between a xenix 286 (2.1)
>machine running old-fashioned system V uucp (my side), and a Sun3
>running version 3.? of SunOS (their side).  Worked just fine.
>
>Recently, the Sun was upgraded to a more recent version of
>SunOS (? 4.0.1) which apparently replaces the uucp
>implementation with the HoneyDanBer suite.
>
>Guess what... can't connect any more.  The xenix machine can
>log in to the sun, (I get a "SUCCEEDED" msg in the log), but i
>then get a "HANDSHAKE FAILED" message and the session fails.
>
>According to the sysadmin on the other end, the account is set
>up correctly, and other machines are logging in using similar
>accounts.
>
>i haven't had a chance to sit down at the xenix machine (i'm not
>usually at the site where its at) and run a uucico session with
>debug turned up high...
>
>before i do that, can anyone tell me if i'll be wasting my time?

It does work.  I had my 386SX under SCO Xenix 386 polling the
SPARCstation 1 at work, but recently I've had a problem with UUCP.  This was
after the serial port on the SPARCstation 1 failed and I sent it back for
replacement.

What happens know is that uucico on the SPARCstation 1 catches a signal 1 and
core dumps.  I have an engineer at Sun working on this right now.  Right now,
e-mail into the SPARCstation 1 at work is like a backed up waterline.  I have
had to kill UUCP and bounce e-mail back that goes through my machine to the
SPARCstation 1 at work.

I know it's a software problem with uucico on the Sun since I can have the Sun
UUCP into a Xenix machine and it works, but a Xenix machine can't UUCP into
the Sun.  And what's weird is that it worked before the serial port failure. 
The obvious difference I've noted is that ROM revision in the new logic board
is 1.3, while the failed board was 1.0.

Since I can log in and the problem manifests itself on both ttya and ttyb, I
know it's a software problem.  The Sun engineer working on the problem logged
into the machine and checked all permissions, everything's kosher.

What Sun is doing now is sending me a non-stripped version of uucico so dbx
will work with the core dump.

I'm about ready to call the local Sun office in San Diego and demand that
SunOS 4.1 be sent to us.  Since we're a Sun VAR, I can yell at Sun and get
away with it to some degree.

Your problem is not unique, I have it to, and it manifested itself after a
logic board failure.  And what annoys me is that I've never seen this problem
happen with UUCP on a commercial implemenation of Unix.  It hurts us since
we're in the system integration business and it is very possible that we could
sell a Sun with a 386 running Xenix.  And what's to say that this won't happen
with other implementations of Unix such as SCO Unix, ESIX, 386/ix, et. al.

But I can tell you this much about the problem, it is on the SunOS end.  If it
wasn't, the core file wouldn't be there, and I'm still trying to figure out
where the hell that signal 1 is coming from.  It's like there's this gremlin
out there who's doing a kill -1 (uucico pid) everytime a Xenix machine logs in
via UUCP and what annoys me more is that it did work before perfectly.  So
that leaves the mess on Sun MicroSystems' door step.
 
     // JCA

 /*
 **--------------------------------------------------------------------------*
 ** Flames  : /dev/null                     | Small memory model only for
 ** ARPANET : crash!pnet01!jca at nosc.mil     | Unix?  Get the (*bleep*) out
 ** INTERNET: jca at pnet01.cts.com            | of here!
 ** UUCP    : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
 **--------------------------------------------------------------------------*
 */