ben@catnip.UUCP (Bennett Broder) (04/26/86)
I recent obtained a copy of C-kermit 4.2(030) PRERELEASE #2, 5 March 85.
We have been using this version at work on a Perkin Elmer 3250XP and an
AT&T 3B5, and so I wasn't expecting any problem bringing it up on Xenix.
Well the package compiles without error, and appears to work okay, until
you attempt to do a transfer. Then it can't even seem to get past the
header packet, and keeps printing SS%S%S%S%S% and the like on the screen.
Looking at the debugging output from both ends show that the Xenix machine
is computing the checksum incorrectly. Please, can anyone help???
--
Ben Broder
{ihnp4,decvax} !hjuxa!catnip!ben
{houxm,topaz}/caf@omen.UUCP (Chuck Forsberg WA7KGX) (04/30/86)
In article <294@catnip.UUCP> ben@catnip.UUCP (Bennett Broder) writes: >I recent obtained a copy of C-kermit 4.2(030) PRERELEASE #2, 5 March 85. >We have been using this version at work on a Perkin Elmer 3250XP and an >AT&T 3B5, and so I wasn't expecting any problem bringing it up on Xenix. >Well the package compiles without error, and appears to work okay, until >you attempt to do a transfer. Then it can't even seem to get past the >header packet, and keeps printing SS%S%S%S%S% and the like on the screen. >Looking at the debugging output from both ends show that the Xenix machine >is computing the checksum incorrectly. Please, can anyone help??? > The Microsoft C compiler has a few problems with right shifts such as used in the Kermit CRC calculations. Here is something that should work better. (From Professional-YAM, the most powerful COMM program for the PC) /* C H K 1 -- Compute a type-1 Kermit 6-bit checksum. */ chk1(pkt) char *pkt; { register chk; chk = chk2(pkt); return((((chk & 0300) >> 6) + chk) & 077); } /* C H K 2 -- Compute the numeric sum of all the bytes in the packet. */ chk2(pkt) register char *pkt; { register chk; for (chk = 0; *pkt; ++pkt) chk += (kparity ? (*pkt & 0177) : (*pkt & 0377)); return chk; } /* C H K 3 -- Compute a type-3 Kermit block check. * * Calculate the 16-bit CRC of a null-terminated string using a byte-oriented * tableless algorithm invented by Andy Lowry (Columbia University). The * magic number 010201 is derived from the CRC-CCITT polynomial x^16+x^12+x^5+1. * Note - this function could be adapted for strings containing imbedded 0's * by including a length argument. */ chk3(s) char *s; { register unsigned int c, q; LONG crc = 0; while ((c = *s++) != '\0') { if (kparity) c &= 0177; else c &= 0377; q = (crc ^ c) & 017; /* Low-order nibble */ crc = (crc >> 4) ^ (q * 010201); q = (crc ^ (c >> 4)) & 017; /* High order nibble */ crc = (crc >> 4) ^ (q * 010201); } return(crc); } Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131 Author of Professional-YAM communications Tools for PCDOS and Unix Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231 Voice: 503-621-3406 TeleGodzilla: 621-3746 300/1200 L.sys entry for omen: omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly
brad@looking.UUCP (Brad Templeton) (05/03/86)
In article <329@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: >In article <294@catnip.UUCP> ben@catnip.UUCP (Bennett Broder) writes: >>I recent obtained a copy of C-kermit 4.2(030) PRERELEASE #2, 5 March 85. >>We have been using this version at work on a Perkin Elmer 3250XP and an >>AT&T 3B5, and so I wasn't expecting any problem bringing it up on Xenix. >>Well the package compiles without error, and appears to work okay, until >>you attempt to do a transfer. Then it can't even seem to get past the >>header packet, and keeps printing SS%S%S%S%S% and the like on the screen. >>Looking at the debugging output from both ends show that the Xenix machine >>is computing the checksum incorrectly. Please, can anyone help??? >> The problem is indeed a bug in the MSC compiler involving shifts of signed integers combined with ands. The fix for kermit is simple enough, make the int in CHK1 into an "unsigned int" We're lucky on this one. It turns out that the Kermit start packet just happens to have a checksum that triggers this bug. Even so it took me several hours to track it down. I'm going to report it to Microsoft as soon as I see it's not in the new Beta release I just got. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473