Article ID: 106145
Article Last Modified on 10/23/2003
APPLIES TO
- Microsoft LAN Manager 2.0 Standard Edition, when used with:
- the operating system: UNIX
- Microsoft LAN Manager 2.1 Standard Edition, when used with:
- the operating system: UNIX
- Microsoft LAN Manager 2.1a, when used with:
- the operating system: UNIX
- Microsoft LAN Manager 2.2 Standard Edition, when used with:
- the operating system: UNIX
This article was previously published under Q106145
SYMPTOMS
When you use Microsoft LAN Manager TCP/IP on a workstation and attempt to
do a NET VIEW <computer name> or NET USE <computer name>\<share name> to a
LAN Manager for UNIX server, you may receive the following NET 53 error
message:
The network path was not found.
You would be able to successfully PING the network address of the server.
On further investigation, you might find that the LAN Manager for UNIX
server has an earlier version of BSD UNIX that uses 0.0.0.0 for a broadcast
address. Setting BCASTADDR = 0.0.0.0 on the workstation doesn't solve this
problem.
CAUSE
The broadcast address of 0.0.0.0 derives from an early release of TCP/IP
from Berkeley UNIX. This was released during a time when the TCP/IP
standards were being implemented and a industry-wide consensus hadn't been
reached concerning the IP address for a broadcast. While this has been
changed in later releases from Berkeley, this address still survives in
some commercial systems derived from their source code. This broadcast
address is not supported by the TCP/IP standards stated in RFC 917 and RFC
922 which define using 255.255.255.255 or a subnetted variation for
broadcasts. Our TCP/IP implementation is based on these internet standards.
The following are examples of three different scenarios at the workstation
when it is configured for different values of BCASTADDR and a NET USE
<computer name>\<share name> is attempted. In these examples, it is assumed
that the server NetBIOS name to IP address mapping is unknown at the
workstation and that the network is a class C with an IP address of
205.10.7.x
No Parameter
The Station sends a NetBIOS Name-Query ("server") Command with the
following IP Address: 205.10.7.255:
The Server doesn't answer.
This is expected because the server waits for 205.10.7.0
BCASTADDR = 0.0.0.0
The Station sends a NetBIOS Name-Query ("server") Command with the
following IP Address : 0.0.0.0. Even when you change the subnet mask, the
"broadcast IP address" is always 0.0.0.0.
The Server doesn't answer.
This is expected because the server waits for 205.10.7.0
BCASTADDR = 205.10.7.0
The Station doesn't send any NetBIOS Name-Query Command. The Station sends
an ARP to the 205.10.7.0 Destination IP Address. The Server doesn't answer.
When explicitly using the BCASTADDR parameter, the BCASTADDR specified is
not masked with the subnet mask at any time. If an address 0.0.0.0 or
255.255.255.255 is specified, then the TCP/IP stack will consider these
standard broadcasts and use them with a Name-Query to resolve the NetBIOS
name. If any other valid IP address is used then the TCP/IP stack will
treat that IP address as unique and will attempt to resolve the address to
a physical address before doing anything else. This is why an ARP request
is generated for the IP address listed in bcastaddr in example 3.
This is documented on page 196 of the "LAN Manager 2.2 Installation and
Configuration Guide."
RESOLUTION
The best way is to explicitly set the NetBIOS name to IP address mapping in
the LMHOSTS file. This will resolve the NetBIOS name to an IP address
without resorting to an ARP request and would solve the problem of finding
the server from the workstation. The LMHOSTS file is in the LANMAN.DOS\ETC
directory and is commented with instructions on how to configure it.
Unfortunately, since the BSD UNIX system uses 0.0.0.0 for a broadcast
address, all the LAN Manager clients won't see any server broadcasts since
they would be listening for broadcasts on 205.10.7.255.
Setting BCASTADDR = 0.0.0.0 on the client wouldn't solve this problem since
the bcastaddr is used for generated broadcasts only and has no impact on
how the TCP/IP stack receives broadcasts.
This means that clients won't see the server listed in the server list when
a NET VIEW is done but would see the server's resources when the server
name is referenced. A NET VIEW \\<server name> would work since the IP
address has already been resolved by the local LMHOSTS file on the
workstation.
Additional query words: 2.0 2.1 2.1a LMX LMU DOS TINYRFC LANMAN
Keywords: KB106145