Accessing LMX Systems that Broadcast on 0.0.0.0
ID: Q108783
|
The information in this article applies to:
-
Microsoft LAN Manager, versions 2.0, 2.0a, 2.1, 2.1a, 2.2, 2.2b
on the following platforms: UNIX
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:
The network path was not found
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 :
Version : :2.0,2.0a,2.1,2.1a,2.2,2.2b
Platform :
Issue type :