Conference noted::pwv50ift

    more info from the customer:
    
      All 3 systems in the cluster are FDDI connected to a DEChub 900 MX
      controller.  The controller in the Alpha system is a DEC "tulip"
      adapter.
    
    
    I've heard that there's a DECnet probelm with FDDI in 5.0E being fixed
    in eco1 -- any issues seen with IP and/or NETLOGON?
    
    

    DECnet netbios problem is indeed fixed.
    
    No problems with netlogon/ip
    
    Adrie

>>    I've heard that there's a DECnet probelm with FDDI in 5.0E being fixed
>>    in eco1 -- any issues seen with IP and/or NETLOGON?
  
    Its fixed, only DECnet and FDDI. See another note from me in this
    conference explaining the problem.
    However this fix will be not in 5.0E-ECO1. When you use decnet and 
    and FDDI is the controller then I suggest to raise an IPMT to get a 
    new NETBIOS image. This NETBIOS will run an all V50E versions.
    
    If only IP or NETbeui or 'normal' etherboards then do not bother.  
    
    
    However this is not the problem you're hunting.
    
    	Rob.

    .3 Sorry I looked for the note and wanted to stick the keyword FDDI
    on it but noticed that I did not put it in here at all :-)
    
    So this is the sequence when you issue a $ net logon username password
    on a standalone machine to logon on the domain.
    
    	1) The net command will set up a session with the _local_ server
    	   (pwrk$lmsrv).
    	   This will happen via the remote api's and you are not able to
    	   trace this on the network with IRIS because we'll see
    	   that its on the same node and will use PCOMS for interprocess
    	   communication.
    
    	2) When the session setup is ok then the UXREDIR will send out a
    	   netlogon multicast.
    	   This is traceble with IRIS, capture all NETBIOS datagrams
    	   by filtering on:
    
    		 09-00-2b-00-00-07 DECnet netbios
    		 03-00-00-00-00-01 Netbeui
    		 ff-ff-ff-ff-ff-ff TCP/IP
    
    	  3) In the name response from the logon server (PDC or BDC)
    	  the server name which served the netlogon request is specified
    	  together with the type of the name (unique or group when its a 
    	  PATHWORKS cluster ) and the object number (which is object 64 which 
    	  is created by the pwrk$lmmmcp prccess which handles all incomming 
    	  connections.)
      
    	  4) Before the negotiate protocol is sent out a NETBIOS findname 
             request is sent out to resolve the netbios name of the 
    	     PATHWORKS cluster alias.
    
    	  5) The name response is sent back by the NETBIOS process containing
    	
    	         - the object number (64)
    		 - The physical decnet address prefixed with the fixed 
    		   part of 000400aa.
    
    	  6) A connection is made to the DECnet address (1024*area +
            nodenumber) object 64.
    
    	However on ethernet controllers DECnet overwrites the physical
        address with it DECnet physical address (SCSSYSTEMID is part of it).
    	Other applications can not overwrite it with another address.
    
    	For FDDI this is per channel, so the data link header should
    	contain the DECnet physical address rather then the physical
    	hardaware address. The application (NETBIOS) should overwrite it 
    	during initialization.
    
    	For FDDI controllers we did not do that thus the datalink source
    	address contained the physical address rather then the DECnet physical
    	address.
    
    	Why does it (mostly) work ?
    
    	Normaly the LANmanager machine name (NETBIOS name) is  the same as the
    	DECnet node name, when we do not see the DECnet physical address
    	prefix we connect to the nodename which mostly succeeds.
    
    	For cluster however it can happen that the connection is made to
    	wrong DECnet node which is _not_ running PATHWORKS because DECnet
    	will do the loadbalacing and not PATHWORKS.
    
    	The above problem is fixed as indicated in .3.
    
    	Also make sure that the PATHWORKS cluster alias in NOT the same as
    	the DECnet/Transport cluster alias!
    
    
    
    			Rob.
    
    
    		Rob.
    

We have a customer with the same problem except DECnet may
not be related and they don't have an FDDI adapter on their
Alpha.

I had them remove DEcnet from a W95 client and the problem
persisted.

Problem has been occurring almost everyday since they upgraded to
V5.0E

Any ideas?

/Mario

    just to clarify: my customer (.0) isn't using DECnet either 

    From my (.0) customer... and no, I don't know any more details than
    what he provided here, sorry
    
     Regards the call I initially opened, I have resolved it here at my site
     by changing the stack on my client PC's.  After much testing and
     numerous TCP tracedumps, I discovered that the client stack that I was
     using was not polling correctly for the NBT packets.  More
     specifically, it was not doing ARP requests to capture the packets and
     discover the broadcasts on either our local net or on the remote nets.
     
     I switched the stack over to the MicroSoft TCP stack (which I dislike
     due to it's lack of RFC compliance) and things started working
     magically.  I suppose that in spite of the stack not being 100%
     compliant in the manner in which some things are done, at least it does
     discover the NBT packets correctly (even across the routers - according
     to our preliminary tests) and lets us work on.
    
     Thanks for your attention, time and help.  You may close this call now.
    
     

    
    re. .7 - Steven,
    
    What client IP stack was he using?  
    
    Paul

    unfortionately, I have no idea.

    disable the alerter service whenever you have DMN problems
    and NETLOGON problems.
    
    Adrie