bin@primate.wisc.edu (Brain in Neutral) (10/14/89)
VAX 8200, Ultrix 1.2 VAXstation 2000, Ultrix 3.1 (but comments apply to 3.0 and 2.2 as well) Whenever the VAXstation kernel is compiled with DECnet in it, it won't speak TCP/IP to the 8200. (Actually, the silence is only partial; rwho traffic gets through from one to the other, but ping, rlogin, rsh, etc., don't work.) When the VS kernel is compiled w/o DECnet, the machines talk TCP/IP to each other with no problems. Anyone know why this is? Perhaps due to differences in 4.2/4.3BSD networking code? The VAXstation talks to my MIPS box (4.3BSD based in the networking) fine whichever way the kernel is compiled. Paul DuBois stewed-monkey-heads@primate.wisc.edu
avolio@decuac.DEC.COM (Frederick M. Avolio) (10/14/89)
Did you follow proper/normal procedures in starting things up after installing DECnet? You might want to post/mail things like how things are started up in your rc.local, etc. We have tons of machines who do both tcp/ip and decnet and have no problems. Course, you're 8200's code is a bit out of date... Make sure that decnet is started before tcp/ip in your rc.local. Does telnet, rcp, tlogin, et al. work in either direction? How about removing the arp info from both sides on each other and trying. How about explicitly turning headers off of both. Fred
grr@cbmvax.UUCP (George Robbins) (10/14/89)
In article <880@uakari.primate.wisc.edu> bin@primate.wisc.edu (Brain in Neutral) writes: > VAX 8200, Ultrix 1.2 > VAXstation 2000, Ultrix 3.1 (but comments apply to 3.0 and 2.2 as well) > > Whenever the VAXstation kernel is compiled with DECnet in it, it won't > speak TCP/IP to the 8200. (Actually, the silence is only partial; rwho > traffic gets through from one to the other, but ping, rlogin, rsh, etc., > don't work.) When the VS kernel is compiled w/o DECnet, the machines > talk TCP/IP to each other with no problems. Are you following the instructions as far as firing up DECnet in the /etc/rc file before you start the TCP stuff? If not, when DECnet changes the ethernet "address" your system drops out of sight of any TCP systems which think they already know who it is... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
hurf@batcomputer.tn.cornell.edu (Hurf Sheldon) (10/19/89)
In article <2774@decuac.DEC.COM> avolio@decuac.DEC.COM (Frederick M. Avolio) writes: > >Did you follow proper/normal procedures in starting things up after >installing DECnet? You might want to post/mail things like >how things are started up in your rc.local, etc. We have tons of >machines who do both tcp/ip and decnet and have no problems. Course, >you're 8200's code is a bit out of date... > >Make sure that decnet is started before tcp/ip in your rc.local. Does >telnet, rcp, tlogin, et al. work in either direction? How about >removing the arp info from both sides on each other and trying. How >about explicitly turning headers off of both. What isn't made clear here is that Decnet aliases the hardware ethernet address of your interface so if you 'arp -a' from your tcpip system you should see what looks like a bogus hardware address for the system running Ultrix-Decnet. -more like 'aa:0:4:0:4:dc' instead of '8:0:2b:7:64:de'. The 'aa' is a tipoff as all DEC systems start with 8:0:2b - if you see the real hardware address do an 'arp -d targetname' to get the decnet aliased address in the arp table. (by deleting the earlier one) In your /etc/rc.local start up decnet and sleep or do something else for a few seconds before starting 'ifconfig' so ifconfig picks up the aliased address. (Why is this, Fred? - not complaining a bit - just curious - the Ultrix Decnet is so nice to have) hurf -- Hurf Sheldon Network: hurf@ionvax.tn.cornell.edu Lab of Plasma Studies Bitnet: hurf@CRNLION 369 Upson Hall, Cornell University, Ithaca, N.Y. 14853 ph:607 255 7267 I got a job in science; I bought a Porsche; Now, everyone takes me seriously.
michaud@decvax.dec.com (Jeff Michaud) (10/19/89)
> In your /etc/rc.local start up decnet and sleep or do something else > for a few seconds before starting 'ifconfig' so ifconfig picks up the > aliased address. (Why is this, Fred? - not complaining a bit - just > curious - the Ultrix Decnet is so nice to have) # %DECnetSTART% if [ -f /usr/bin/ncp ]; then echo 'Starting DECnet ' >/dev/console /usr/bin/ncp set executor state on fi If you have an '&' after the ncp command, simply remove it. rc.local will wait for ncp to exit, which means that when it returns it will of already changed the hardware address. With the '&' (ie. background) rc.local keeps executing and you have yourself a race condition between ncp (actually nml) changing the hardware address and ifconfig being executed farther down in rc.local. Hope that helps! /--------------------------------------------------------------\ |Jeff Michaud michaud@decwrl.dec.com michaud@decvax.dec.com| |DECnet-ULTRIX #include <standard/disclaimer.h> | \--------------------------------------------------------------/
bin@primate.wisc.edu (Brain in Neutral) (10/20/89)
In article <880@uakari.primate.wisc.edu>, bin@primate.wisc.edu (Brain in Neutral) writes: > VAX 8200, Ultrix 1.2 > VAXstation 2000, Ultrix 3.1 (but comments apply to 3.0 and 2.2 as well) > > Whenever the VAXstation kernel is compiled with DECnet in it, it won't > speak TCP/IP to the 8200. (Actually, the silence is only partial; rwho > traffic gets through from one to the other, but ping, rlogin, rsh, etc., > don't work.) When the VS kernel is compiled w/o DECnet, the machines > talk TCP/IP to each other with no problems. > > Anyone know why this is? Thanks to those who responded. The problem now appears to be fixed. I'll describe the solution below in case it might help someone else. DEC uses 16-bit addresses for DECnet addressing. Ethernet addresses are 48 bits. DEC allocated a range of ethernet addresses from Xerox (the address "custodian" for ethernet) that all begin with the 32-bit constant aa:00:04:00, and then puts the DECnet address in the last two bytes to form a 48-bit ethernet address. (I discovered this this very morning while reading "Designing and Implementing Ethernet Networks, Bill Hancock, on the bus coming to work. Funny how these things happen.) Of course, that synthetic address may not correspond to the physical ethernet address of the interface, so when Ultrix boots, the DECnet initialization (presumably /usr/bin/ncp in /etc/rc.local) changes the address to one of those aa:00:04:00 things. Unfortunately the 8200 still had the old (unaltered) ethernet address in its arp cache and the two machines would not talk to each other. This was fixed by deleting the arp entry for the VAXstation on the 8200 with arp -d. Interestingly, our MIPS M/120 figured out the new ethernet address right away and had no problems. Paul DuBois dubois@primate.wisc.edu
maj@cl.cam.ac.uk (Martyn Johnson) (10/20/89)
In article <9085@batcomputer.tn.cornell.edu> hurf@tcgould.tn.cornell.edu (Hurf Sheldon) writes: > -more like 'aa:0:4:0:4:dc' instead of '8:0:2b:7:64:de'. The 'aa' is a > tipoff as all DEC systems start with 8:0:2b Not absolutely true. I have a batch of early DEQNAs with hardware addresses beginning aa:0:03. This is easily confused with the DECnet prefix of aa:0:04. It means that you have to look at all three bytes to be sure. Martyn Johnson University of Cambridge Computer Lab Cambridge UK.