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."