safe message problem: HP to 486

safe message problem: HP to 486

Post by mit-eddie!harvard!scubed!flamingo.SanDiego.NCR.COM!donn » Fri, 06 Nov 1992 09:07:44



This is probably old news but here goes ...

We're trying to inteoperate between our i486 machine running a port of
Kerberos 4.9 and an HP-9000 system running version 4.? (don't know the
exact version). When receiving "safe" messages sent by the HP
system, we fail comparing the checksums and reject the message.

The 4.9 source tries to account for the different machine
architectures by invoking swap_u_16() on one of the checksums before
comparing the received checksum with that generated by des_quad_cksum
on our side.  However, swap_u_16() swaps the ENTIRE 16 bytes as
follows:
   original bytes: 000102030405060708090a0b0c0d0e0f
   after swap:     0f0e0d0c0b0a09080706050403020100

Unfortunately des_quad checksum() on the 486 returns:
                                   03020100070605040b0a09080f0d0e0c
If one swaps the bytes in EACH long independently you get:
                                   000102030405060708090a0b0c0d0e0f
Which is the same value as the checksum sent in the message!

It looks like the call to swap_u_16() should be changed to 4 calls to
swap_u_long(), or swap_u_16() be changed to handle swapping within the
long integers that make up the checksum. Alternatively swapping could
be removed from rd_safe and des_quad_checksum changed to create a
machine independent 16 or 32 byte value.

If this is a known bug is there a standard fix? I also assume that
private message handling is impacted, but I haven't looked into it
yet.

By the way the machine definitions for the 486 are:

#define BITS32
#define BIG
#define LSBFIRST

Any help would be appreciated.

Thanks in advance.

--

NCR LCPD-San Diego, MS 1240
16550 W. Bernardo Drive
San Diego, CA 92127

Telephone: (619)485-3396                FAX: (619)485-2598
VoicePlus: 440-3396

 
 
 

safe message problem: HP to 486

Post by Shawn Mamr » Wed, 11 Nov 1992 00:38:39


I noticed the same problem with safe messages between machines with different
byte-ordering a couple months ago (in my case, between a DECstation (little-
endian) and a Sun SPARCstation (big-endian).  I changed the checksum
byte-swapping code in src/lib/krb/rd_safe.c to swap one longword (four bytes)
at a time, and that seemed to fix it.


any acknowledgement one way or another.  I have no doubt that this has already
been noticed long before I did, and odds are good there was probably even
a patch posted to this mailing list a long time ago, but I've never seen
any place where "official" fixes to patchlevel 9 have been kept...  For
what it's worth, here's my patchlevel 9-based fix:

*** rd_safe.c   Mon Sep 14 10:25:32 1992
--- rd_safe.c.orig      Mon Jan 23 15:16:38 1989
***************
*** 165,179 ****
       */

      bcopy((char *)p,(char *)big_cksum,sizeof(big_cksum));
!     if (swap_bytes) {
!       u_long *swapptr;
!       int i;
!
!       for (i = 0; i < 4; i++) {
!           swapptr = (u_long *)(big_cksum) + i;
!           swap_u_long(*swapptr);
!       }
!     }

  #ifdef NOENCRYPTION
      bzero(calc_cksum, sizeof(calc_cksum));
--- 165,171 ----
       */

      bcopy((char *)p,(char *)big_cksum,sizeof(big_cksum));
!     if (swap_bytes) swap_u_16(big_cksum);

  #ifdef NOENCRYPTION
      bzero(calc_cksum, sizeof(calc_cksum));

Private messages don't seem to suffer from the same problem... actually, if
you look at rd_priv.c from patchlevel 9, you'll see that the checksum-checking
clause has been #ifdef'd out... sigh.

-Shawn Mamros


 
 
 

1. HP Vectra 486/66XM Video Problem

Hi,

I recently upgraded my HP Vectra 486/66XM to 64MB.  I am running NS 3.3
(3.3.3.8) with the S3 (v3.30) video driver.  After some struggle, I am
able to boot in VGA mode.  I tried to reset the mapped memory in the
generic S3 driver to a new value above 64MB.  I have used 0xA000000,
0x10000000, etc. but still can't get the thing running.  I turned off
boot up graphics, the system is fine until I get the "boot complete"
message.  It then turns on the graphics and the system hangs.  I'd
really like to keep NS on my system, but unless I can get this driver
problem licked, it looks like NT :-(

Is there a more recent version of the driver.  There are some other
minor video problems that it would be nice to fix up.

Thanks

Mark Jackson

2. Capisce? :-)

3. Wanted: 10 x 486 PCI Motherboards - PCI 486 ALI2

4. Checking TTFs

5. 486 > Sparc (Was:Re: Minix for 486 PCs)

6. Parallel Line IP anyone?

7. Is Intel's 486 Rapid Card a 486?

8. Diff b/w Win98 and Win NT

9. Getting Hi-Res Graphics on HP Vectra 486/66N

10. Original HP LaserJet & 486 ???

11. HP Laserjet 4L and 286/486

12. PRIMAX Colorado D600 / COM3 problem on 486 PC with WIN-95

13. 486 and ecp port problem