Conference noted::pwv50ift

    My understanding (and testing) shows that use of a direct datagram is
    ignored by the LAN Manager 2.2 server; it only "listens" for
    broadcasts.  This should (hopefully) change with the v6 server, to be
    more like NT.
    

Thanks, Steve.  There were already notes in the UCX conference that
indicated that PW would only broadcast itself on the first interface.
What wasn't clear is whether or not UCX would make an incoming
broadcast interface-transparent.  That is, the request is made under
a configuration that would be normal if the 198.110.162.x subnet
were the first interface.  The results here indicate that PW will
only listen on the first interface.

>    My understanding (and testing) shows that use of a direct datagram is
>    ignored by the LAN Manager 2.2 server; it only "listens" for
>    broadcasts.  This should (hopefully) change with the v6 server, to be
>    more like NT.

Also it sounds like you are saying that the WAN domains won't work.
Doesn't that operation depend on using a direct datagram?

Lew

    Lew,
    
    What error is the client getting?  And what specifically did you enter
    in LMHOSTS?  Does Win95 even use LMHOSTS during domain logon?  If so,
    you may need more than just the name of the server with #PRE and #DOM
    (maybe a special 16th byte?).
    
    And I believe we _listen_ for broadcasts over one interface only. 
    However, a client should be able to directly use any IP address "owned"
    by the server to communicate with it as long as the NETBIOS name in the
    request is also one for which the server "owns".
    
    My understanding is the client would send the request directly to the
    198... address of the server - if it IP stack on the server accepts the
    request, it should hand it off to lmmcp who should check that the
    request is one this pw server should respond to.  I think this check is
    based on a NETBIOS name (in a net logon request, I believe that name is
    the domain name with a special 16th byte?).  
    
    Though it's not quite the same, I know if you have a UCX cluster
    impersonator (aka, alias) address defined, you can use that address 
    in the LMHOSTS file on a remote PW server to facilitate the WAN domain
    uas replication stuff.  I'd think a pseudo interface address would be
    just as legit.
    
    You could do $ TCPIPTRACE /PACKETS=n <IP-address-of-client> and see
    what comes in thru UCX.  If it all looks normal, I guess putting the
    server in debug mode might show where the breakdown is...
    
    HTH,
    
    Paul

    What I was trying to say in .1 is that, if I remember correctly, the
    use of WINS or LMHOSTS does not work to a v5 server's NETLOGON service
    even with a single (non-cluster) node -- that the NETLOGON service only
    "hears" broadcasts, not directed datagrams.  If someone in engineering
    has a different understanding, please let us know.
    

    
>    What error is the client getting?  And what specifically did you enter
>    in LMHOSTS?  Does Win95 even use LMHOSTS during domain logon?  If so,
>    you may need more than just the name of the server with #PRE and #DOM
>    (maybe a special 16th byte?).

He only put 

address   server_name   #PRE #DOM:domain name

Do we have to put anything else for the WAN domains?  I have also been 
following 4203 with interest, but this should be more direct.
    
>    And I believe we _listen_ for broadcasts over one interface only. 
>    However, a client should be able to directly use any IP address "owned"
>    by the server to communicate with it as long as the NETBIOS name in the
>    request is also one for which the server "owns".

Well, that's what one would guess.
    
>    My understanding is the client would send the request directly to the
>    198... address of the server - if it IP stack on the server accepts the
>    request, it should hand it off to lmmcp who should check that the
>    request is one this pw server should respond to.  I think this check is
>    based on a NETBIOS name (in a net logon request, I believe that name is
>    the domain name with a special 16th byte?).  

Shouldn't the netlogon request (domain logon in win95) handle any name
modification?
    
>    Though it's not quite the same, I know if you have a UCX cluster
>    impersonator (aka, alias) address defined, you can use that address 
>    in the LMHOSTS file on a remote PW server to facilitate the WAN domain
>    uas replication stuff.  I'd think a pseudo interface address would be
>    just as legit.

That's what I thought also.
    
>    You could do $ TCPIPTRACE /PACKETS=n <IP-address-of-client> and see
>    what comes in thru UCX.  If it all looks normal, I guess putting the
>    server in debug mode might show where the breakdown is...
    
The tcp trace will be the next step.

>    HTH

Yes.  If nothing other than keeping sanity in a world where Murphy's Law
has the corollary:

If it can be tried, sooner or later a customer will try it.

Lew

>    What I was trying to say in .1 is that, if I remember correctly, the
>    use of WINS or LMHOSTS does not work to a v5 server's NETLOGON service
>    even with a single (non-cluster) node -- that the NETLOGON service only
>    "hears" broadcasts, not directed datagrams.  If someone in engineering
>    has a different understanding, please let us know.
    
I certainly hope they do respond.  This is a valuable piece of info and was
something I did not realize.  I will check the release notes also.

Lew

I see that this is my fault in that the lack of support for netlogon
is very clear in the article:

[PW-VMS]V5 Implementing WAN Domain Using TCP/IP LMHOSTS                       

That clears up the operation as far as the direct datagram is concerned.
Now to try and understand all the implications of being in the same
subnet as the pseudo address...

Lew

    Lew,
    
    I read the stars article and _think_ I see what you're referring to:
    
    NOTE: Dynamic Host Configuration Protocol (DHCP), Windows Internet
          Name Service (WINS), and support for wide area NET LOGON
          Validation has not been included in this release.
    
    What your customer is trying to do is, in essence, a "wide area NET
    LOGON Validation" because it's sending a directed datagram.  Is this
    how you see it?  I mean, the difference between a LAN NET LOGON and WAN
    NET LOGON is one you do a broadcast and the other requires directed
    datagram, eh?  
    
    FWIW, I know a customer who setup a WAN domain with just PATHWORKS
    servers (PDC was a cluster and bdc a single vax).  With the pdc defined
    in lmhosts (#pre #dom:domainname) on bdc (and vice versa), they could
    do $ NET LOGON from the BDC and get validated by the PDC.  This has to
    be via a directed datagram.  And if it responds to that directed
    datagram, why wouldn't it respond to a Win95 clients?  Guess an
    engineer would have to answer.  Wonder what would happen if you put
    the Win95 client in the server's LMHOSTS file????  
    
    Does the tcpiptrace show anything getting into the server?  I suspect
    it will, but the server isn't responding.  This is assuming Win95 has
    the same WAN domain logon validation capabilities as WNT. 
    
    Paul

Paul,
    
Haven't been able to contact the customer yet to get the trace.

>    I read the stars article and _think_ I see what you're referring to:
    
Yes, that note was the one referred to.  Pretty obvious to miss, but I did
in the long run anyway.
    
>    What your customer is trying to do is, in essence, a "wide area NET
>    LOGON Validation" because it's sending a directed datagram.  Is this
>    how you see it?  I mean, the difference between a LAN NET LOGON and WAN
>    NET LOGON is one you do a broadcast and the other requires directed
>    datagram, eh?  

Well, the datagram sending was the second pass at it.  The article answers
this case.  But the first try was as a standard logon.  It is not obvious
that UCX will not pass on broadcasts it receives on the second interface.
I have been browsing in UCX notes, and I see the following:

The broadcast mask will be the one defined for the first interface, regardless
of what one specifies in later interfaces.  That is no problem here.

A note (1359.*) from 7-dec-94 discussed this problem with the server version
of that time.  It is highly interesting in that it suggests that the server
_does_ receive broadcasts on both interfaces, but that netlogon requires
that the server also _send_ broadcasts on both interfaces!  The only way that
would seem reasonable would be if the client first listened for the server.
I would certainly like to know whether or not this is accurate.
    
>    FWIW, I know a customer who setup a WAN domain with just PATHWORKS
>    servers (PDC was a cluster and bdc a single vax).  With the pdc defined
>    in lmhosts (#pre #dom:domainname) on bdc (and vice versa), they could
>    do $ NET LOGON from the BDC and get validated by the PDC.  This has to
>    be via a directed datagram.  And if it responds to that directed
>    datagram, why wouldn't it respond to a Win95 clients?  Guess an
>    engineer would have to answer.  Wonder what would happen if you put
>    the Win95 client in the server's LMHOSTS file????  

Are you sure the PDC is doing the validation?  That is interesting.  I will
have him define the client in lmhosts on the server, and we will see.
    
Thanks for the help.

Lew

    
    No, I didn't see the PDC validate the BDC NET LOGON; a customer I trust
    indicated it worked (and that with it defined incorrectly in lmhosts,
    NET LOGON from the BDC didn't work).  He was the guy trying to setup
    the WAN domain with a PATHWORKS cluster (that was discussed in another
    note in this conf).
    
    Paul

    
>    No, I didn't see the PDC validate the BDC NET LOGON; a customer I trust
>    indicated it worked (and that with it defined incorrectly in lmhosts,
>    NET LOGON from the BDC didn't work).  He was the guy trying to setup
>    the WAN domain with a PATHWORKS cluster (that was discussed in another
>    note in this conf).
    
Well, this certainly makes it interesting.  I will report back when the customer
is available to try things.

Lew

    What Paul is saying works. As far as the 95 and WAN logon Phil
    indicated sometime back to me that it might work but they never looked
    at the WAN/LMHOSTS stuff they put in "D" as being done for that purpose
    so they didn't test/analize that theory (Phil - you listening?)
    
    Mike

>                          -< BDC-PDC/LMHOSTS OK >-
>
>    What Paul is saying works. As far as the 95 and WAN logon Phil
>    indicated sometime back to me that it might work but they never looked
>    at the WAN/LMHOSTS stuff they put in "D" as being done for that purpose
>    so they didn't test/analize that theory (Phil - you listening?)
    
Well, if BDC in a separate subnet works, then it is sending a routed message
for its logon.  It is not at all clear how that would be different than a
routed message from any other source.  UCX sure as heck doesn't care.  At
this point, it begins to appear that the PDC -> client communication may
indeed be the source of differences.  I hope to get a test today.

Lew

This whole note quite confused me yesterday until I got some time to 
think about it.

This thing about broadcast vs. directed datagram I believe is a red 
herring.  One should be able to put a domain name in a LMHOST file 
and target broadcast to that name to a specific internet address (ie.
"direct" the datagram").  This is the basic reason for doing lmhost 
support in the first place.

When PW binds to UCX, it binds to IF_INET which somehow gloms all 
types of messages (directed and broadcast) from all interfaces (eg. 
multiple lan controllers) through one fd (channel,socket,etc.). 

In fact this can also be a problem because some "smart" clients see 
two responses to a name query, send out a name conflict to one and 
connect to the other.  When the name happens to be the same name seen 
via two controllers, problems occur.

> Client is set as 198.110.162.z.  Client has lmhosts file with 
server defined 
> by 198.. address.  Netlogon doesn't get there.  If client is set 
for subnet 
> 128.1.18.x it works fine.  Operations other than netlogon work 
fine.

You say the server is defined by 198... but netlogon doesn't send 
datagrams to servers, it sends them to the domain, so you need to 
have an lmhost entry for the domain name.  Is that what you have?

Phil,

Thanks for getting in here.

>When PW binds to UCX, it binds to IF_INET which somehow gloms all
>types of messages (directed and broadcast) from all interfaces (eg.
>multiple lan controllers) through one fd (channel,socket,etc.).

Then the server should be hearing the requests from clients in the
second interface, even without an lmhosts file?  It also sounds like
netlogon should work for WAN clients contrary to our current set of
STARS articles.

>You say the server is defined by 198... but netlogon doesn't send 
>datagrams to servers, it sends them to the domain, so you need to 
>have an lmhost entry for the domain name.  Is that what you have?

The server definition has the "#DOM:domain_name" item in the entry
for the server.  Are you saying there needs to be an entry such as

address   domain_name   #PRE

as well?

Lew

No, I wrote without looking.  

a.d.d.r server-name #dom:domain-name #pre 

is right

How is the the pseudo address set up?  We are going to look at it 
here to see what is happening.  I have never heard of a pseudo 
address and if it requires specific application support, it probably
won't work.

Phil

>How is the the pseudo address set up?  We are going to look at it 
>here to see what is happening.  I have never heard of a pseudo 
>address and if it requires specific application support, it probably
>won't work.

The term "pseudo address" was used because that's the way the customer
called it in, and I hadn't heard of it either at the time.  He actually
has multiple interfaces.  UCX allows this and it is discussed for
various problems in the UCX notes file (LASSIE::UCX), although I
hadn't heard of that either.  The server is a node in both subnets, and
apparently may or may not be a router.

Ideally, both subnets would function the same way one does.

Lew

Minor clarification from the previous reply.  I had heard of the
UCX notes long ago.  What I meant was that I hadn't known about
the use of multiple interfaces before taking this call.  Just
couldn't leave it the way it was.

Lew

The customer called back in.  He reports that they knew already that the
server is sending a broadcast response to netlogon requests.  This came
about in earlier attempts to accomplish netlogon through a router.  They
had Cisco monitor the netlogon request traffic, and discovered that the
server response was a broadcast rather than a directed datagram.  

This was in fact the reason for setting up the second subnet.  After
doing that, they found out that the broadcasts only go out on the first
interface.

This is all second-hand for me, and I can't test it.  However, confirming
the operation should be uncomplicated with the right equipment.  The
obvious question now is whether or not this is the way it is intended to
work.  If not, I will put in an IPMT.  If so, it will be an SPR.

Lew

For whatever it's worth, I now have a second customer with exactly the
same complaint.  He has also done a network trace and confirmed that
the following takes place:

   Client on subnet defined by interface 2 issues netlogon request

   Server sees request and verifies the user and password

   Server issues a verification by broadcast over subnet defined by
   interface 1.

   Client thinks server is out to lunch

Lew

If the server sees the netlogon request and wishes to reply it will attempt to 
resolve the destination (in this case the client's) netbios name to find the IP
addr. Normally it should find this in the cache, since we just received a
NETLOGON request (directed or broadcast) datagram from the client and these
learned name-IP address mappings are cached temporarily. This is how the server
responds to directed datagrams from clients who are not on the same subnet and
who use the LMHOSTS file to send a NETLOGON directed datagram to the server. 
If however the server is unable to correctly resolve the IP addr of the client,
it broadcasts the reply.

Now, if the server is only broadcasting on the first interface as you mentioned,
then it would appear that the server for some strange reason doesn't find the
client's name in its cache and so tries to resolve the client name by doing
B-node name query ONLY on the first interface/sub-net. When this fails to
resolve the client name (since client is on the other sub-net) the server then 
broadcasts the NETLOGON reply on the first interface/sub-net. This is what I 
think is happening atleast from what I've read in this note...maybe I'm wrong. 

I dont know enough about how the UCX Pseudo interface is setup or exactly how it
is supposed to work. All I know at this point is that you dont need more than
one controller to set these up and you can use these Pseudo interfaces to set up
the OpenVMS host to be part of multiple subnets on the same physical network. I
Will try to set it up here and test to see what I can find. Can you give me more
info about the customer's set up particularly the output from '$UCX SHOW ROUTE'.
You mention that one of the customers has a network trace of this problem...any 
chance you can get us this trace?



-Raj

Raj,

Thanks for the input.  Yes, it is quite possible for me to get the trace,
and I will try tomorrow.

However, your reply is interesting.  In investigating this, I found:

1 - The release notes only promise that the server will participate in
an NT WAN domain.  They do not say that the server can be a PDC.

2 - The following is in our primary article on the WAN domain topic:

NOTE: Dynamic Host Configuration Protocol (DHCP), Windows Internet            
      Name Service (WINS), and support for wide area NET LOGON                
      Validation has not been included in this release.                       

You either said, or strongly implied, that a client can do a netlogon
using a directed datagram over a wide-area connection.  Everything I
can see indicates that is not the case.  That was the reason the customers
defined the second interface to begin with, attempting to put the server
in the same subnet as the clients.

Lew

I did some testing on PW5 and PW6 for Unix for WAN logging in some time 
ago.

It appears that on a PW5 system, even if the server receives a netlogon 
request (via a WINS gateway for address resolution) it is only listening 
for multicasts (or broadcasts) and ignores the directed netlogon request.

The server never responds at all (as seen from Iris).

In PWv6, it all works fine.

Alan