Article ID: 108783
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.0a, 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
- Microsoft LAN Manager 2.2b, when used with:
- the operating system: UNIX
This article was previously published under Q108783
SYMPTOMS
When you try a NET USE \\computername\sharename or NET VIEW \\computername from a Microsoft LAN Manager TCP/IP workstation to a server using LAN Manager for Unix, you get the NET 53 error message:
even when you can successfully PING the server's network address.
Further investigation might show that the LAN Manager for Unix server has an older version of BSD Unix that uses 0.0.0.0 for a broadcast address, but setting bcastaddr = 0.0.0.0 on the workstation doesn't solve the problem.
CAUSE
The 0.0.0.0 broadcast address still shows up in some commercial systems derived from BSD Unix TCP/IP releases that predate TCP/IP standards RFC 917 and RFC 922--which require broadcast addresses of 255.255.255.255 or a subnetted variation. Microsoft bases its TCP/IP implementation on these standards.
EXAMPLES
These scenarios show what can happen when you attempt a NET USE \\computername\sharename on three workstations that:
- are configured with different bcastaddr values
- do not know the server-NetBIOS-name-to-IP-address mapping
- belong to a Class C network with an IP address of 205.10.7.x
Case 1: No Parameter
- the workstation sends a NetBIOS name-query ("server") command with an IP address of 205.10.7.255
- the server doesn't answer because it is waiting for 205.10.7.0
Case 2: bcastaddr = 0.0.0.0
- the workstation station sends a NetBIOS name-query ("server") command with an IP Address of 0.0.0.0
- even when you change the subnet mask, "broadcast IP address" is always 0.0.0.0
- the server doesn't answer because it is waiting for 205.10.7.0
Case 3: bcastaddr = bcastaddr = 205.10.7.0
- instead of sending a NetBIOS name-query command, the workstation sends an ARP to the 205.10.7.0 destination IP address
- the server doesn't answer
Any broadcast address you specify with the bcastaddr parameter is never masked with the subnet mask. If you specify an address of 0.0.0.0 or 255.255.255.255, then the TCP/IP stack treats them as standard broadcasts and uses them with a name-query to resolve the NetBIOS name. If you use any other valid IP address, the TCP/IP stack treats it as unique and attempts to resolve it to a physical address before doing anything else. This is why the workstation in Case 3 generates an ARP request for the IP address listed in bcastaddr.
WORKAROUND
Setting the NetBIOS-name-to-IP-address mapping in the local LMHOSTS file lets the workstation resolve the NetBIOS name to an IP address without resorting to an ARP request and solves the problem of finding the server. LMHOSTS is in \LANMAN.DOS\ETC and is commented with configuration instructions.
Still, LAN Manager clients listen for broadcasts on 205.10.7.255, so they cannot see server broadcasts from systems that use 0.0.0.0 for a broadcast address because they are based on early BSD Unix source code. Setting the client's bcastaddr to 0.0.0.0 doesn't solve this problem because the bcastaddr is used for generated broadcasts only and has no impact on how the TCP/IP stack receives broadcasts.
This means that clients doing a NET VIEW don't see the server listed in the server list but do see the server's resources when the server name is referenced. A NET VIEW \\<server name> works because the LMHOSTS file on the workstation resolves the IP address.
REFERENCES
Microsoft LAN Manager "Installation and Configuration Guide," version 2.2, p. 196.
Additional query words: 2.0 2.1 2.1a LMX LMU DOS TINYRFC LANMAN
Keywords: KB108783
