jeh@dcs.simpact.com (05/26/90)
In article <27@thehulk.dmc.com>, munroe@thehulk.dmc.com (Dick Munroe, Doyle Munroe Consultants, Inc.) writes: > All implementations of UUPC send [an extra null byte preceding each > DLE] during the initial g protocol handshake. ... > I plan to fix the uucico in DECUS UUCP but it was easier to fix > the UUPC implementation ... Your fix to UUPC will of course solve the problem. In V1.2 of DECUS uucp, we solve the problem on "our side" -- uucico ignores extra null bytes that occur between elements of the initial handshake. V1.2 will be on the Spring 90 SIG tape, will be available as a separately orderably item in the DECUS Library, and will no doubt be available via anon. ftp just as V1.1 is now, all within a few weeks... we hope! --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@dcs.simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh
help@kendra.kew.com (Drew Derbyshire) (05/29/90)
From article <27@thehulk.dmc.com>, by munroe@thehulk.dmc.com (Dick Munroe, Doyle Munroe Consultants, Inc.): > My thanks to Andre Wood (andre@hern.mv.com) who, in passing, > mentioned seeing this problem before and saved me a lot of time > hunting for it. > > All implementations of UUPC send the following during the initial > g protocol handshake: > > \000\020 handshake message \000 > > For those of you who want the fix, in dcpsys.c in function wmsg, > change: > > swrite("\0\020",2) ; > > to > > swrite("\020",1) ; > > and the problem will go away. This is a bad idea. The reason is that wmsg is the driver for most messages through UUPC, and will cause sync'ed messages to include the extra \000 character, which may impact your performance. The fix should go in startup(), I think (I don't read news on kendra, which is where my UUPC source is). I'll fix the distribution copy of UUPC when someone gives me the fix for startup() and tested it. Later ... Looking at the UUPC/extended 1.07j source, changes need to made around lines 433 and 466 of dcpsys.c to add a direct call to swrite to terminate the message with a \000. I'd personally fix DECUS UUCP. However, I'll add the fix to UUPC/extended 1.07k if some writes it up and tests it. Drew Derbyshire UUPC/extended maintainer Internet: help@kendra.kew.com
munroe@thehulk.dmc.com (Dick Munroe, Doyle Munroe Consultants, Inc.) (05/29/90)
In article <27@thehulk.dmc.com>, munroe@thehulk.dmc.com (Dick Munroe, Doyle Munroe Consultants, Inc.) writes: > All implementations of UUPC send the following during the initial > g protocol handshake: > > \000\020 handshake message \000 > > While not, strictly speaking, a violation of g protocol (as I > understand it) it does give some uucico implementations a > problem, notably DECUS UUCP, which is where I ran into it. > > I plan to fix the uucico in DECUS UUCP but it was easier to fix > the UUPC implementation (because I understand it better, not due > to any flaw in DECUS UUCP). > > ... Several lines deleted ... And here, as promised, is the fix for DECUS UUCP V1.1. The attached file is used as input to the SLP editor and applied against the version of CALL.C that ships with V1.1 of DECUS UUCP. It has been tested against UUPC and the UUCP running on uunet. Use it in good health. -- Dick Munroe Internet: munroe@thehulk.dmc.com Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe 267 Cox St. Office: (508) 568-1618 Hudson, Ma. FAX: (508) 562-1133 -------------------- cut here for SLP file -------------------- - 2 * * 0.000 Dick Munroe 28-May-90 * Fix getstring to operate properly on g protocol framed strings. - 774, 776 * Read a framed, null-terminated string for the protocol initialization * sequence. String starts with character following the first DLE (0x10) * character and goes until the next null character. - 787 while ( ((data = xgetc(10)) != EOF)) { data &= 0x7f ; /* Trim to 7 bits */ if (data == 0x10) { goto DLE_seen ; } ; /* End if */ } ; /* End while */ /* ** There was no DLE character in the data stream within the ** timeout period. This means there was no frame and, by implication, ** no string. */ DEBUG(DB_LGI, "\nTimeout in Getstring while scanning for DLE\n", 0); return FAIL; DLE_seen : - 805, 808 } DEBUG(DB_LGI, "\nTimeout in Getstring while collecting string\n", 0); /
munroe@thehulk.dmc.com (Dick Munroe, Doyle Munroe Consultants, Inc.) (05/29/90)
In article <27@thehulk.dmc.com>, munroe@thehulk.dmc.com (Dick Munroe, Doyle Munroe Consultants, Inc.) writes: > My thanks to Andre Wood (andre@hern.mv.com) who, in passing, > mentioned seeing this problem before and saved me a lot of time > hunting for it. > > All implementations of UUPC send the following during the initial > g protocol handshake: > > \000\020 handshake message \000 > > While not, strictly speaking, a violation of g protocol (as I > understand it) it does give some uucico implementations a > problem, notably DECUS UUCP, which is where I ran into it. > > I plan to fix the uucico in DECUS UUCP but it was easier to fix > the UUPC implementation (because I understand it better, not due > to any flaw in DECUS UUCP). > > For those of you who want the fix, in dcpsys.c in function wmsg, > change: > > swrite("\0\020",2) ; > > to > > swrite("\020",1) ; > > and the problem will go away. > -- > Dick Munroe Internet: munroe@thehulk.dmc.com > Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe > 267 Cox St. Office: (508) 568-1618 > Hudson, Ma. FAX: (508) 562-1133 -- Dick Munroe Internet: munroe@thehulk.dmc.com Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe 267 Cox St. Office: (508) 568-1618 Hudson, Ma. FAX: (508) 562-1133
munroe@thehulk.dmc.com (Dick Munroe, Doyle Munroe Consultants, Inc.) (05/29/90)
As promised, here is a patch for DECUS UUCP that fixes the
spurious termination of the protocol handshake.
Attached is a SLP file for the version of CALL.C that shipped
with DECUS UUCP V1.1 that implements this fix. It has been tested
against UUPC and the UUCP running on uunet.
Use it in good health.
--
Dick Munroe Internet: munroe@thehulk.dmc.com
Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe
267 Cox St. Office: (508) 568-1618
Hudson, Ma. FAX: (508) 562-1133
------------------ Cut here for SLP file --------------------------
- 2
*
* 0.000 Dick Munroe 28-May-90
* Fix getstring to operate properly on g protocol framed strings.
- 774, 776
* Read a framed, null-terminated string for the protocol initialization
* sequence. String starts with character following the first DLE (0x10)
* character and goes until the next null character.
- 787
while ( ((data = xgetc(10)) != EOF))
{
data &= 0x7f ; /* Trim to 7 bits */
if (data == 0x10)
{
goto DLE_seen ;
} ; /* End if */
} ; /* End while */
/*
** There was no DLE character in the data stream within the
** timeout period. This means there was no frame and, by implication,
** no string.
*/
DEBUG(DB_LGI, "\nTimeout in Getstring while scanning for DLE\n", 0);
return FAIL;
DLE_seen :
- 805, 808
}
DEBUG(DB_LGI, "\nTimeout in Getstring while collecting string\n", 0);
/munroe@thehulk.dmc.com (Dick Munroe, Doyle Munroe Consultants, Inc.) (05/30/90)
In article <27@thehulk.dmc.com>, munroe@thehulk.dmc.com (Dick Munroe, Doyle Munroe Consultants, Inc.) writes: > All implementations of UUPC send the following during the initial > g protocol handshake: > > \000\020 handshake message \000 > > While not, strictly speaking, a violation of g protocol (as I > understand it) it does give some uucico implementations a > problem, notably DECUS UUCP, which is where I ran into it. > > I plan to fix the uucico in DECUS UUCP but it was easier to fix > the UUPC implementation (because I understand it better, not due > to any flaw in DECUS UUCP). > As promised, here is the fix for DECUS UUCP. Attached are the SLP files for the version of CALLS.C and UUCICO.C that shipped with DECUS UUCP V1.1 that implements this fix. It has been tested against UUPC and the UUCP running on uunet. --------------- cut here for call.slp ----------------------------- - 2 * * 0.000 Dick Munroe 28-May-90 * Fix getstring to operate properly on g protocol framed strings. - 774, 776 * Read a framed, null-terminated string for the protocol initialization * sequence. String starts with character following the first DLE (0x10) * character and goes until the next null character. - 785 "Scanning for DLE (getstring), rcvd"); while ( ((data = xgetc(10)) != EOF)) { data &= 0x7f ; /* Trim to 7 bits */ charlog (&data, 1, DB_LGI, (char *)NULL); if (data == 0x10) { goto DLE_seen ; } ; /* End if */ } ; /* End while */ /* ** There was no DLE character in the data stream within the ** timeout period. This means there was no frame and, by implication, ** no string. */ DEBUG(DB_LGI, "\nTimeout in Getstring while scanning for DLE\n", 0); return FAIL; DLE_seen : charlog((char *)NULL, 0, DB_LGI, - 805, 808 } DEBUG(DB_LGI, "\nTimeout in Getstring while collecting string\n", 0); / --------------- cut here for uucico.slp --------------------------- - 33 * * 0.000 Dick Munroe 29-May-90 * A minor reorganization of the protocol handshake to get the DLE * scan working in getstring. - 643, 645 if (getstring(msgbuf, MAX_STRING) != SUCCESS) { - 649, 653 } ; if (strncmp( msgbuf, "Shere", 5 ) != SAME) { - 657, 657 } ; /* End if */ - 661, 662 if (msgbuf[5] == '=') { if (strcmp(Hostname, &msgbuf[6]) != SAME) { - 667, 667 } else if (msgbuf[5] != '\0') { - 671, 671 } ; /* End if */ / -- Dick Munroe Internet: munroe@thehulk.dmc.com Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe 267 Cox St. Office: (508) 568-1618 Hudson, Ma. FAX: (508) 562-1133