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