From uucp Mon Jun 24 06:17:44 1985 Relay-Version: version B 2.10.2 9/18/84; site gwsd.UUCP Posting-Version: version B 2.10.2 9/18/84; site olympus.UUCP Path: gwsd!sdcsvax!dcdwest!ittvax!decvax!genrad!panda!talcott!harvard!seismo!umcp-cs!gymble!lll-crg!dual!olympus!bob From: bob@olympus.UUCP (Bob Toxen) Newsgroups: net.bugs.uucp Subject: Re: uucico bug: if remote hostname is null watch out! Message-ID: <155@olympus.UUCP> Date: 22 Jun 85 07:42:27 GMT References: <239@kovacs.UUCP> Organization: Silicon Graphics, Mountain View, CA Lines: 153 > A Silicon Graphics workstation called up our > 4.2 vax and started up a uucico. > Funny thing was that the hostname on the SGI machine > was null (""). The vax then proceeded to give it > mail messages destined for at least 2 machines other > than the one that was dialing in with the null hostname. > It probably would have given away the whole store if > the transmission hadn't gone bad for line noise reasons. > > --dave yost You do Silicon Graphics a disservice by implying that the bug was introduced by Silicon Graphics. THE BUG IS IN THE *VAX 4.2* UUCICO. I haven't spent the time to find the bug but it is prob- ably matching the first N characters where N is the length of the remote node name, in this case zero. Silicon Graphics uses a basically System V uucp with some bug fixes and enhancements such as ethernet support. The bug will probably show itself for any System V uucico calling 4.2bsd (it doesn't seem to occur if one 4.2 system calls another one). This bug was discovered and our uucico enhanced to abort if the node name is null a few weeks ago. You can wait for the July release or contact SGI for a special tape. I am supplying the fix as well as a fix for the 4.2 end for those with source. System V: *** /tmp/,RCSt1a28763 Fri Jun 21 23:02:48 1985 --- uucpname.c Mon Jun 17 11:40:02 1985 *************** *** 1,4 /* @(#)uucpname.c 1.5 */ #include "uucp.h" #ifdef UNAME --- 1,12 ----- /* @(#)uucpname.c 1.5 */ + static char *Sccsid = "@(#)$Header: /ws/rel/src/usr.bin/uucp/RCS/uucpname.c,v 1.2 85/06/17 11:39:09 bob Exp $"; + /* + * $Log: uucpname.c,v $ + * Revision 1.2 85/06/17 11:39:09 bob + * Fixed to abort if node name is null since otherwise 4.2bsd uucp will + * send every node's mail to the node! + * + */ #include "uucp.h" #ifdef UNAME *************** *** 34,39 while ((*d = *s++) && d < name + SYSNSIZE) d++; *(name + SYSNSIZE) = '\0'; /* the following statements are for debugging */ #ifdef TESTB ret = guinfo(getuid(), loginusr, msg); --- 42,53 ----- while ((*d = *s++) && d < name + SYSNSIZE) d++; *(name + SYSNSIZE) = '\0'; + if (!*name) { + fprintf(stderr, "Node name is empty\n"); + DEBUG(1, "Node name is empty\n", 0); + logent("Node name is empty","uucico aborted"); + exit(3); + } /* the following statements are for debugging */ #ifdef TESTB ret = guinfo(getuid(), loginusr, msg); *************** *** 49,53 break; } #endif - return; } --- 63,66 ----- break; } #endif } 4.2bsd: *** /tmp/,RCSt1023671 Fri Jun 21 23:53:56 1985 --- cico.c Fri Jun 21 23:53:35 1985 *************** *** 1,6 #ifndef lint static char sccsid[] = "@(#)cico.c 5.3 (Berkeley) 10/3/83"; ! static char *Sccsid = "@(#)$Header: cico.c,v 1.3 85/01/07 12:18:03 bob Exp $"; /* # $Log: cico.c,v $ * Revision 1.3 85/01/07 12:18:03 bob --- 1,6 ----- #ifndef lint static char sccsid[] = "@(#)cico.c 5.3 (Berkeley) 10/3/83"; ! static char *Sccsid = "@(#)$Header: cico.c,v 1.4 85/06/21 23:52:34 bob Exp $"; /* # $Log: cico.c,v $ * Revision 1.4 85/06/21 23:52:34 bob *************** *** 3,8 static char *Sccsid = "@(#)$Header: cico.c,v 1.3 85/01/07 12:18:03 bob Exp $"; /* # $Log: cico.c,v $ * Revision 1.3 85/01/07 12:18:03 bob * Installed seismo!rick's lost line fix posted on Usenet. * --- 3,13 ----- static char *Sccsid = "@(#)$Header: cico.c,v 1.4 85/06/21 23:52:34 bob Exp $"; /* # $Log: cico.c,v $ + * Revision 1.4 85/06/21 23:52:34 bob + * Fixed to abort connection if remote node name is empty (so that we won't + * send it all jobs waiting for all systems due to a bug in pattern + * matching deeply buried). + * * Revision 1.3 85/01/07 12:18:03 bob * Installed seismo!rick's lost line fix posted on Usenet. * *************** *** 228,233 p = pskip(q); sprintf(Rmtname, "%.7s", q); DEBUG(4, "sys-%s\n", Rmtname); if (mlock(Rmtname)) { omsg('R', "LCK", Ofn); cleanup(0); --- 233,243 ----- p = pskip(q); sprintf(Rmtname, "%.7s", q); DEBUG(4, "sys-%s\n", Rmtname); + if (!*Rmtname) { + DEBUG(1, "Remote node name is empty\n", 0); + logent("Remote node name is empty","uucico aborted"); + cleanup(0); + } if (mlock(Rmtname)) { omsg('R', "LCK", Ofn); cleanup(0); -- Bob Toxen "Beam us up, Scotty! We found the only intelligent OS." Silicon Graphics {ucbvax,decwrl,ames!vienna,dual,its}!olympus!bob From root Wed Mar 26 02:24:29 1986 Relay-Version: version B 2.10.2 9/18/84; site ncr-sd.UUCP Posting-Version: version B 2.10.2 9/18/84; site watmath.UUCP Path: ncr-sd!sdcsvax!dcdwest!ittatc!decvax!bellcore!ulysses!burl!clyde!watmath!rjwhite From: rjwhite@watmath.UUCP (RJ White) Newsgroups: net.bugs.uucp Subject: bug in uucico causes spooled files to get removed Message-ID: <1804@watmath.UUCP> Date: 24 Mar 86 23:21:23 GMT Date-Received: 26 Mar 86 08:20:32 GMT Distribution: net Organization: University of Waterloo [MFCF] Lines: 54 Last night we lost alot of stuff queued for ihnp4 because it looks like their filesystem was full and couldn't create any temporary files. The code checks for this and if sending the file bombs because of this, then it isn't supposed to remove the file that it couldn't send. The problem is, the wrong byte is checked in the status message sent back. The following is a diff so that it will now FAIL instead of trying to continue since there is no point in continuing if the disk is full. The file is cntrl.c *** cntrl.c Mon Mar 24 17:55:04 1986 --- new_cntrl.c Mon Mar 24 17:57:54 1986 *************** *** 318,325 ASSERT(role == MASTER, "WRONG ROLE", "", role); fclose(fp); fp = NULL; ! if (msg[1] != '4') ! unlinkdf(W_DFILE); goto top; } --- 318,328 ----- ASSERT(role == MASTER, "WRONG ROLE", "", role); fclose(fp); fp = NULL; ! if (msg[2] == '4') { /* from EM_NOTMP , msg="SN4" */ ! (*Turnoff)(); ! return( FAIL ); ! } ! unlinkdf(W_DFILE); goto top; } *************** *** 390,396 WMESG(SNDFILE, EM_NOTMP); logent("CAN'T OPEN", "DENIED"); unlinkdf(Dfile); ! goto top; } WMESG(SNDFILE, YES); --- 393,400 ----- WMESG(SNDFILE, EM_NOTMP); logent("CAN'T OPEN", "DENIED"); unlinkdf(Dfile); ! (*Turnoff)(); ! return( FAIL ); } WMESG(SNDFILE, YES); >From bblue Fri Jul 12 14:21:36 1985 >From uucp Thu Jul 11 06:50:48 1985 remote from crash Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site gwsd.UUCP Posting-Version: version B 2.10.2 9/5/84; site nsc-pdc.UUCP Path: gwsd!sdcsvax!dcdwest!ittvax!decvax!tektronix!reed!nsc-pdc!joemu From: joemu@nsc-pdc.UUCP (Joe Mueller) Newsgroups: net.bugs.uucp Subject: More System V.2 uucp bugs, maybe in others as well Message-ID: <227@nsc-pdc.UUCP> Date: 10 Jul 85 03:10:59 GMT Distribution: net Organization: NSC Portland Development Center, Portland Oregon Lines: 98 [eat me] I found a couple of other bugs in uucp while I was hacking away I thought I'd share the fixes. 1. If you look at your LOGFILE and notice that you have the sequence: OK (conversation complete) TIMEOUT (machine-name) The your system is missing the over and out message at the end of the transmission. The way I found some versions of uucp doing it was to modify cico.c in the following way: *** /tmp/,RCSt1010067 Tue Jul 9 19:41:56 1985 --- /tmp/,RCSt2010067 Tue Jul 9 19:41:58 1985 *************** *** 488,494 DEBUG(4, "send OO %d,", ret); if (!setjmp(Sjbuf)) { for (;;) { - omsg('O', "OOOOO", Ofn); ret = imsg(msg, Ifn); if (ret != 0) break; --- 488,493 ----- DEBUG(4, "send OO %d,", ret); if (!setjmp(Sjbuf)) { for (;;) { ret = imsg(msg, Ifn); if (ret != 0) break; Basically I added a second omsg call within the loop. There is another omsg call directly above the DEBUG statement. Some versions of cico.c that I looked at had the omsg call within the loop but was missing it above the DEBUG statement. Actually, the right way to fix it would to extend the protocall so that you would syncronously look for the over and out message rather than to have both side blurt it out and hope the other guy sees it but it would mean that you'ld have to change all the uucp's around. 2. The second and third bugs are that the routine us_sst does not open the correct lock file and once you fix that you can't open it because you don't have the correct permissions on the file. You can see the problem if you call your machine from another while in debug mode over the value of 9. i.e. on another machine issue the following command as root: /usr/lib/uucp/uucico -r1 -x9 -syour_machine_name It will call your machine and spit out a lot of junk to your screen. You then go back to your machine and check /usr/spool/uucp/AUDIT to see if you have any messages that look something like: "fopen of /usr/spool/uucp/LCK.LSTAT failed" If you do, you have the bugs. To fix the first one you need to change us_sst.c as follows: *** /tmp/,RCSt1010154 Tue Jul 9 19:48:34 1985 --- us_sst.c Tue Jul 9 19:48:07 1985 *************** *** 48,54 umask(mask); return(FAIL); } ! if ((fp = fopen(L_stat, "r+")) == NULL) { DEBUG(3, "fopen of %s failed\n", LCKLSTAT); rmlock(LCKLSTAT); umask(mask); --- 48,54 ----- umask(mask); return(FAIL); } ! if ((fp = fopen(LCKLSTAT, "r+")) == NULL) { DEBUG(3, "fopen of %s failed\n", LCKLSTAT); rmlock(LCKLSTAT); umask(mask); The second bug you need to modify the file ulockf.c in the following way: *** /tmp/,RCSt1010117 Tue Jul 9 19:45:20 1985 --- ulockf.c Tue Jul 9 19:44:43 1985 *************** *** 146,152 char cb[100]; extern errno; ! fd=creat(tempfile,0444); if(fd < 0){ sprintf(cb, "%s %s %d",tempfile,name,errno); logent("ULOCKC", cb); --- 146,152 ----- char cb[100]; extern errno; ! fd=creat(tempfile,0664); if(fd < 0){ sprintf(cb, "%s %s %d",tempfile,name,errno); logent("ULOCKC", cb); That should do it. >From bblue Fri Jul 12 14:22:12 1985 >From uucp Thu Jul 11 06:54:26 1985 remote from crash Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site gwsd.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: gwsd!sdcsvax!dcdwest!ittvax!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.bugs.uucp Subject: Re: 4.2 uucp bug? Message-ID: <2403@sun.uucp> Date: 10 Jul 85 01:38:04 GMT References: <226@nsc-pdc.UUCP> Distribution: net Organization: Sun Microsystems, Inc. Lines: 40 > When I look in LOGFILE I see the "OK (conversation complete)" message > followed by a "TIMEOUT (machine-name)" message. It looks like our 4.2 BSD > machine is missing the "OOOOO" message from the other machine. Actually, this bug's existed in most versions of UUCP since the beginning of time; the 4.2BSD one is the only one (with the possible exception of honey danber) which actually bothered to report the timeout, so I guess nobody knew about it until then. The hangup sequence for UUCP is supposed to be: Master - sends H, indicating it has no more work and is ready to switch roles (if the slave has work) or hang up (if the slave has no more work either), and waits for an HY or HN from the slave Slave - if it has no work, it responds with HY and waits for an HY or HN from the master Master - reads the HY from the slave, sends an HY, turns off the protocol on its end (reverting to the initial "imsg"/"omsg" protocol), sends an OOOOO, sends another OOOOO, and waits for the slave to reply with OOOOO Slave - reads the HY from the master and shuts down the same way the master did However, when the slave reads the HY from the master, instead of shutting down immediately, it sends back *another* HY. If the "g" protocol is being used, this means that there is unacknowledged output; the slave waits for an acknowledgment which never comes. Eventually, it times out, but in the interim the master hasn't seen its OOOOO and times out also. This is somewhat timing dependent, so you may not get this sequence every time - however, the bug in the protocol is obvious. Either the slave should not send an HY when it receives the HY, or the master should expect an additional HY in response to the HY it sent. I originally implemented the second solution - it's not the "correct" solution, but it does match what most systems do. Rick Adams later implemented the first solution, and I believe 4.3BSD will have his UUCP. That is the right solution; furthermore, it made some timeouts that the second solution caused to occur (it seemed to happen either when talking to System V UUCP or honey danber UUCP, I'm not sure which) go away. Since I don't care whether the other guy gets spurious timeouts (they don't clutter my "uustat" output), I prefer that solution. Guy Harris From ncr-sd!hp-sdd!ucsdhub!ucsd!ames!mailrus!umix!honey Mon Oct 10 14:46:09 PDT 1988 David MacKenzie writes: >While we're at it, every so often between two uucp v2 SVR1 systems >people get messages from uucp that contain the message, "remote access >to path/file denied." I've never been able figure out what that means, >and our uucp documentation doesn't give a clue. Does this mean the >message wasn't delivered on the remote end, wasn't spooled locally, or >what? here's the scenario. host1 has a uux request spooled for host2. host1 sends the first file. host2 receives the file, and commits it to the host1 subdirectory. the connection fails before host1 receives notification of successful receipt (CY message). now host2 has the file in its subdirectory for host1, but host1 thinks it has yet to successfully transfer the file. when host1 re-establishes a connection to host2, host1 tries to resend the file. because the file already exists, host2 rejects the request. host1 then sends the second file and everything works as intended. in summary, it's benign. peter