Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!uw-beaver!mit-eddie!ll-xn!ames!ucbcad!ucbvax!ENGVAX.SCG.HAC.COM!KVC
From: KVC@ENGVAX.SCG.HAC.COM (Kevin Carosso)
Newsgroups: comp.os.vms
Subject: VAXstation-2000 ethernet problem...
Message-ID: <8706270754.AA00167@ucbvax.Berkeley.EDU>
Date: Fri, 26-Jun-87 21:49:00 EDT
Article-I.D.: ucbvax.8706270754.AA00167
Posted: Fri Jun 26 21:49:00 1987
Date-Received: Sun, 28-Jun-87 01:00:59 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 33

I've got a VAXstation-2000 up and running here (fun little system).

In getting the CMU/Tek TCP/IP code up on it I've run into a problem.
I've traced the problem to it's root...   Apparently the VS-2000 never receives
ARP broadcast packets.  It receives other packets with the ARP protocol
type and can send ARP broadcast packets.  It just never receives any.  In
fact, near as I can tell, the VS-2000 never receives any ethernet broadcast
packets.  It does receive multicast packets.

It makes no difference whether the VS-2000 is running as a LAVC satellite
node or completely standalone off it's own disk.  It speaks LAVC, DECnet,
and LAT with no problems.  All these use multicasts but never broadcasts,
right?  Also, if I have our Berkeley 4.3 UNIX machine act as an ARP server
for the VS-2000, the CMU TCP/IP works just fine.

The VS-2000 is our only thinwire ethernet node, so it's on the thinwire side of
a DEMPR which is plugged into a transceiver on our thick ethernet. Maybe the
DEMPR is not passing through broadcast packets?  The DEMPR is plugged into a
Cabletron ST-500 transceiver.  I think our other DEC equipment is on H4000s,
so maybe that's at fault?  If not, that would leave the DESVA controller
or the VMS device driver...

Any clues anyone?

        /Kevin Carosso                     kvc@engvax.scg.hac.com
         Hughes Aircraft Co.               kvc%engvax@oberon.usc.edu

ps.  The CMU TEK/TCP code runs without modification on the -2000.  Since
     the ethernet device name is ESA0: you need to define XEA0 as a logical
     name for it.  I modified the code to avoid such tackiness.  In my
     version you specify a driver family name (XE for all DEC ethernet)
     and a device name (ESA0:).  I will be sending this (and other mods)
     to the TEK-TCP list (if the list still works).