Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ncar!gatech!mcnc!borg!hatteras!kuzminsk
From: kuzminsk@hatteras.cs.unc.edu (David Kuzminski)
Newsgroups: comp.sys.mac.comm
Subject: Re: EtherTalk problems
Message-ID: <2960@borg.cs.unc.edu>
Date: 5 Apr 91 22:40:43 GMT
References: <2908@borg.cs.unc.edu>
Sender: news@cs.unc.edu
Organization: University of North Carolina, Chapel Hill
Lines: 51

In article <2908@borg.cs.unc.edu> kuzminsk@hatteras.cs.unc.edu (David Kuzminski) writes:
>
>
>I have a Mac IIci with an Apple EtherTalk NB board, running system
>6.0.5 and EtherTalk 1.1.  We have several Macs attached directly to 
>the Ethernet, as well as three LaserWriters via EtherPrint boxes.  
>These are all on a zone named "CS EtherTalk".  We also have three
>other zones (MacLAN 1, 2 and 3) that are defined by three Kinetics
>FastPaths running K-STAR version 8.0.  The EtherTalk Mac was as happy
>as it could be accessing devices on all the zones until this morning
>when I temporarily removed the battery from the CPU card.  Once I 
>put the system back together, I lost the ability to access devices
>on the other side of the Kinetics boxes.  I can still see the zones  
>in the chooser, but none of the devices on them show up.  Everything
>attached diretly to the EtherTalk is still accessible.
>
>Does anyone have any idea where to look for solutions to this problem?
>I feel it must be related to some settings in the Parameter Ram as it
>started immediately after removing the battery backup to it.
>

Gee, it's pretty bad when a guy has to follow up on his own problem
report!  :^).

Seriously, though, I determined what I thought *MIGHT* be causing the
problem, made what I *THOUGHT* was the necessary change, and, voila, no
more problem.  The tough part now is understanding why the problem existed
in the first place and why it's gone now.

Through various Sherlock Holmes type steps, I came to the conclusion that
the problem had something to do with the AppleTalk node address of the
machine being set to 1.  How I reached this conclusion is long and
complicated, and I don't particularly want to embarrass myself by going
through it publically.  Nevertheless, when I changed the node number from
1 to 2, everything went back to working just fine!

Does anyone have a clue as to what might be causing this problem?  I am
not looking forward to going through this everytime someone resets their
PRAM.

aTdHvAaNnKcSe.


=======================================
David Kuzminski
Computer Science Department
University of North Carolina
131 Sitterson Hall, Campus Box 3175
Chapel Hill, NC  27599-3175
Office: 919-962-1767 Fax:  919-962-1799
Email: kuzminsk@cs.unc.edu