[comp.sys.apollo] weird problems with Domain internetworking

ianh@merlin.bhpmrl.oz (Ian Hoyle) (05/02/89)

I have been having some REALLY wierd problems using Domain services in
an internet.

The problem (a rather simplified diagram) :


                     merlin (3500)
                    /     \
              RING  \     /
                     \   /
                     zaphod (10000 running rtsvc)
                       |
     ------------------------------------------------------------
      ETHERNET                              |
                                          lindon (4500)

1) rtsvc is running on the 10000.

2) when I log onto lindon and lcnode I can see both lindon and zaphod.

3) I can cd to //merlin ok, so I guess rtsvc is ok on zaphod.

4) when I cd to etc on merlin and do an 'ls' I get a full directory
   listing ok.

5) BUT, when I do an 'ls p*' to list all files beginning with p, the whole
   thing locks up on me.

   if I have another pad open at the same time continually pinging merlin
   using TCP/IP packets, the instant I type in the 'ls p*' the pinging
   halts.

   also, more often than not, when I regain control again, 'lcnode' will
   only see lindon and will not find zaphod.

what on earth is different between doing an 'ls' and an 'ls p*' ????? Are
different packet sizes used for any obscure reason ??? (lindon is connected
to the ethernet using thinwire via a 3Com multiport repeater)

could it be the VME ethernet card in the 10000 ????

I'm obviously at a loss to explain this behaviour so I'd luv whatever clues
I can get :-)

						ian

wescott@LNIC2.HPRC.UH.EDU (Andrew M. Wescott) (05/04/89)

With (3) DN3500s running SR 10.1, I have seen this problem
several times when doing an "ls" with options from one 3500
to another or from a 3500 to our DN10000.  The problem only
occurs in directories that do not contain user accounts (i.e.
it does not occurr in /u1 on our machines, but everywhere
else like /etc and /usr).  

The bottom line is that there is a bug in the file /sys/ethernet8_microcode.
The solution is to rename the file to /sys/ethernet8_microcode.old and
let the communication services use what is in the ROM on the ethernet
controller.  There is also a patch version of ethernet8_microcode
available which I have, but I have not bothered to install it as the
performance difference is negligible and I don't want to push my
luck.  This is a well-known bug within Chelmsford, and I think it
has made it to "technical bulletin" status.

As a secondary curiousity, I would also check to see if Unix
restrictions are enforced in your registry, but I'm sure what
I suggested above will do the trick.


Andrew M. Wescott
University of Houston
Department of Chemical Engineering

P.S.  I am referring to /sys/ethernet8_microcode on your DN3500's and
DN4500s, you won't find this file on the DN10000.