don@dksfr.UUCP (don kossman) (06/07/90)
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? the usual drooling thanks in advance... -- Don Kossman, SEI Information Technology, Los Angeles ...mahendo.jpl.nasa.gov!seila!don -- Don Kossman, SEI Information Technology, Los Angeles ...mahendo.jpl.nasa.gov!seila!don
jca@pnet01.cts.com (John C. Archambeau) (06/08/90)
don@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@nosc.mil | Unix? Get the (*bleep*) out ** INTERNET: jca@pnet01.cts.com | of here! ** UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */