Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!vms.CIS.PITTSBURGH.EDU!Postmaster From: Postmaster@vms.CIS.PITTSBURGH.EDU (PMDF Mail Server) Newsgroups: comp.os.vms Subject: Undeliverable mail Message-ID: <8710290541.AA18597@ucbvax.Berkeley.EDU> Date: Mon, 26-Oct-87 10:42:00 EST Article-I.D.: ucbvax.8710290541.AA18597 Posted: Mon Oct 26 10:42:00 1987 Date-Received: Tue, 3-Nov-87 04:50:10 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 70 The message could not be delivered to: Addressee: 000426 Reason: %MAIL-E-NOSUCHUSR, no such user 10217_000426 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Mon, 26 Oct 87 00:53 EDT Received: From CMUCCVMA(MAILER) by PITTVMS with RSCS id 3794 for 000426@PITTVMS; Mon, 26-OCT-1987 00:33 EDT Received: by CMUCCVMA (Mailer X1.25) id 3793; Mon, 26 Oct 87 00:34:59 EST Date: 22 Oct 87 20:20:24 GMT From: Kevin Carosso Subject: Re: TCP/IP Driver for a VAX 8530 Sender: INFO-VAX Discussion To: BETH DOE <000426@vms.cis.pittsburgh.edu> Reply-to: INFO-VAX@KL.SRI.COM Comments: Warning -- original Sender: tag was info-vax-request@kl.sri.com Comments: To: info-vax@kl.sri.com 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