Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!ucbvax!ORVILLE.NAS.NASA.GOV!lekash
From: lekash@ORVILLE.NAS.NASA.GOV (John Lekashman)
Newsgroups: comp.protocols.tcp-ip
Subject: HYROUTE(TCP/IP gateway between HYPERchannel and ethernet)
Message-ID: <8806140116.AA01014@orville.nas.nasa.gov>
Date: 14 Jun 88 01:16:34 GMT
References: <8805231553.AA21150@oliver.cray.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 30


     The bottom line is that any implementation of HYROUTE that limits
     you to a subset of the IP addresses that the vendor supports is
     broken.  (That is, if the vendor doesn't support subnets, then
     his HYROUTE program isn't broken because it doesn't work with
     subnets.  But if the vendor does support subnets, as the vendor
     should, and HYROUTE does not work with subnets, then the vendor's
     implementation is broken)

I bet this problem stems from the fact that the BSD distributed
in_lnaof() in the C-library does not return the subnetted net, only
the main network number.  (At least the version we have.  I think
I've gotten all bug fixes.)

So, the typical clever programmer just calls in_lnaof(addr) in
both the hyroute and the kernel, and loses cause they return
different things for user and kernel space.

I fixed this here some time ago by sticking in a in_mainlnaof()
in the hy driver, and calling that.  It returns only the class A,B,C
network.  It would be better to repair the c-library, but
it does not seem to be a trivial fix, and I didn't want to 
worry about breaking other things at this time.

I like the idea of hashing on the whole IP address better, but it
does mean a more difficult hashing algorithm, or else a really
big table.  I know those few rotates and adds don't much matter,
but they have to happen on every packet.

						john