[comp.protocols.appletalk] Anyone else seen these FastPath problems

jmg@cernvax.cern.ch (mike gerard) (02/11/91)

preamble: Shiva support seem unable or unwilling to help!

Also, as introduction, we have a site-wide Ethernet with Mac-level
bridges of various capacity and delay parameters. We also have about
150 FastPaths, mostly running KStar (7.0 or 8.0 or 8.01).
For various reasons, some FastPath nodes have managed to come up with
identical node numbers (both Phase 1 and Phase 2) on Ethernet.
Thus, I am trying to use the FastPath manager to check/change
configurations over Ethernet.

Now the problems, for which I would like to know if there is any
confirmation of them elsewhere:-

1. Using the FastPath manager for looking over Ethernet is essentially
   unworkable. The Manager never sees all of the FastPaths, and sometimes
   never finds any. When it does start finding some it quite often
   seems to want to open one immediately. Worst of all, it either bombs
   out regularly or even hangs the Mac II completely. I suspect that all
   of these problems stem from lost or delayed packets.

2. Using the FastPath Manager to download over AppleTalk has always
   been a pain when on a busy Ethernet (with lots of broadcasts), so
   that I always have a mini-Ethernet to replace the real one while
   downloading Kstar (and then have to remember to put back the real
   Ethernet before starting the FastPath.

3. If, on Phase 1, all of the (ethernet side) node numbers from 129 to 255
   and 1 to 13 are already in use then the FastPath seems to stop looking and
   just uses the number it first thought of (which is in use!): the
   result is not nice. (n.b. I know a different type of EtherTalk
   equipment which only likes the range 129-146!).

Well, that is enough to be going on with: any confirmation of problems
would be welcome, whilst any solutions would have me ecstatic.