[comp.os.vms] TCP/IP Driver for a VAX 8530

padwa%harvsc3@HARVARD.HARVARD.EDU (Danny Padwa) (10/19/87)

HI!!!
        Does anybody out there in network land know of a package that
allows TCP/IP access on a VAX 8530? We are running the Carnegie-Mellon
package on our MicroVaxen and 750, but it won't run on the 8530.
	Apparently it our TCP/IP software can't handle the new DEC bus.
Does anyone have any ideas? All information would be appreciated.
                                Daniel Padwa
                                User Services Department
                                Harvard University
     
                                PADWA@HARVSC3.BITNET
                                PADWA@HARVSC3.HARVARD.EDU

DSTEVENS@VAXC.STEVENS-TECH.EDU (David L. Stevens) (10/20/87)

 Could you please explain more about what you mean by new DEC bus.  Because we
 have CMU TCP/IP up and running on a VAX 8700 which also uses the BI bus.

 - thanx
  Dave Stevens
  Stevens Tech
  Computer Center

  BITNET:	DSTEVENS@SITVXA
  INTERnet:	DSTEVENS@VAXC.STEVENS-TECH.EDU

 [ No I'm not related to the founders of the college ... I just work here ]
------------

kvc@nrcvax.UUCP (Kevin Carosso) (10/22/87)

In article <8710200125.AA25209@ucbvax.Berkeley.EDU> padwa%harvsc3@HARVARD.HARVARD.EDU (Danny Padwa) writes:
>HI!!!
>        Does anybody out there in network land know of a package that
>allows TCP/IP access on a VAX 8530? We are running the Carnegie-Mellon
>package on our MicroVaxen and 750, but it won't run on the 8530.
>	Apparently it our TCP/IP software can't handle the new DEC bus.
>Does anyone have any ideas? All information would be appreciated.
>                                Daniel Padwa

All of DEC's ethernet devices have the same (or nearly the same)
driver interface.  This means the CMU stuff should not have any
dependencies which prevent it from running on the 8530.
Unfortunately, the version of CMU TCP/IP I am familiar with (6.0)
has two possible gotchas.  One easy to get around, one not...

First of all, version 6.0 (I haven't seen 6.2 yet) only knows about
the device names XEA0 and XQA0.  You could define a system (or at
least group) -wide logical name for XEA0 and equate it to ETA0, the
device name on a BI machine, causing the ACP process to get the proper
device when it does its $ASSIGN.  I fixed this by modifying the code
NOT to figure out the device family (DEC vs. Interlan vs. DMR) from
the device name (which is dumb) but from a separate field in the
config.  I do not know if CMU incorporated this idea, but one can
hope...

The second problem is less likely, but more serious.  The ethernet
device on the -2000 series machines (ESA0) poses a problem in that the
device driver ignores incoming broadcast packets by default.  This
means you have to enable reception of broadcasts because TCP/IP
(actually ARP) require them.  I DO NOT KNOW IF THE DRIVER FOR THE
DEBNT OR DEBNA ON BI MACHINES REQUIRE THIS.  If so, then you need a
fix to the code which initializes the device.  DEC has indicated that
they intend all future ethernet drivers to behave this way, so the fix
had best be in any newer version of CMU TCP/IP.  It does not adversely
affect usage of older (DEUNA, DEQNA, DELUA) drivers.  I can send this
fix, but it won't do you any good unless you have a BLISS compiler.

If this is the problem, the symptoms are obvious.  The machine behaves
like it never sees ARP requests.  You can make connections from the
machine to a Berkeley 4.2 or 4.3 machine, but not to another CMU
TCP/IP (because Berkeley doesn't need to ARP back) and you can make
connections from Berkeley 4.2 or 4.3 machines back to the VMS machine
for as long as the address stays in the ARP cache.  You could get around
the problem by having a 4.3 machine "publish" ARP requests on behalf 
of the sick machine, so everyone can find out its address...

	/Kevin Carosso                     kvc@nrcvax.uucp
	 Network Research Co.            nrcvax!kvc@TRWIND.TRW.COM