Accessing LMX Systems that Broadcast on 0.0.0.0

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

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:

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.

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

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.