HOWTO: Use LANA Numbers in a 32-bit Environment

ID: Q138037

The information in this article applies to:

Microsoft Win32 Software Development Kit (SDK), versions 3.1, 3.5, 3.51, 4.0

SUMMARY

NetBIOS uses the concept of a LANA (LAN adapter number) that allows you to write transport-independent NetBIOS applications. This article describes what a LANA is and recommends an approach to writing NetBIOS applications.

MORE INFORMATION

A LANA is a field of the NetBIOS NCB structure. In IBM's NetBIOS 3.0 specification, a LANA was used to specify a particular network adapter, as NetBIOS then supported up to two network adapters in one PC computer. Specifying a LANA of zero directed a request to the first adapter, and specifying a LANA of one directed a request to the second adapter.

Originally, IBM sent NetBIOS packets over the NETBEUI protocol, also known as the NetBIOS Frames protocol. This was the only transport NetBIOS could use to send data across the network. In other words, each network adapter had only one protocol to send and receive NetBIOS packets.

Because most computers have only one network adapter, many MS-DOS-based applications send all their requests to a LANA value of zero (also called simply 'LANA zero'). If a second network adapter is installed, some programs allow the user to configure the application to use LANA one instead. As a result, LANA zero became a default setting, though it was never intended to be a default.

Today's network technology allows NetBIOS to use transports other than NETBEUI. Microsoft has extended the meaning of LANA to indicate a specific transport on a specific adapter. For example, if you have two network adapters, and have IPX/SPX and NETBEUI transports installed, you have four LANAs. The LANAs may or may not be sequential, and there is no systematic way to identify which transport maps to which LANA.

In addition to extending the meaning of a LANA, Microsoft also added an NCB command (NCBENUM) that returns an array of available LANA numbers. As an example, the LANA_ENUM structure filled by NCBENUM might hold an array with values 0, 3, 5, and 6. Zero might map to IPX/SPX on the first adapter, three might map to NETBEUI on a second adapter, and so on.

In Windows NT and Windows 95, network adapters consist of physical adapters (like a 3Com Etherlink II) and software adapters (like the Dial Up Adapter). In addition, a user may have TCP/IP, NETBEUI, IPX/SPX, and other transports installed, all of which have NetBIOS support.

For Windows NT, LANAs are configurable through the control panel. Choose the Network applet, choose the NetBIOS Interface component, then choose Configure. A dialog appears that allows you to edit the LANAs.

For Windows 95, you may only set LANA zero, the default protocol, and if no protocol is set as default, there won't be a LANA zero. You can set the default protocol in the control panel. Choose the Network applet, choose the protocol you want as default, choose Properties, the Advanced tab, and finally check 'Set this protocol to be the default protocol'.

LANAs may seem like a constraint that your application must work around. However, making your application ignorant of how users want to configure their machines is a powerful idea, and one that makes life easier for your customers.

The best way to write a NetBIOS application is to support all LANAs, and establish connections over any LANA. A good approach is outlined in the following steps:

Enumerate the LANAs by submitting NCBENUM.

Reset each LANA by submitting one NCBRESET per LANA.

Add your local NetBIOS name to each LANA. The name may be the same on each LANA.

Connect using any LANA:

For servers, submit an NCBLISTEN on each LANA. If necessary, cancel any outstanding listen after the first listen is satisfied.

For clients, submit an NCBFINDNAME (Windows NT only) or an NCBCALL (either Windows NT or Windows 95) on each LANA. The first successful find name or call will indicate which LANA to use. When using NCBCALL instead of NCBFINDNAME, you must cancel any pending NCBCALLs and hang up the extra completed calls (when two or more calls are successful.)

It is a good idea to submit NCBADDNAME, NCBLISTEN, NCBFINDNAME, and NCBCALL asynchronously. Asynchronous requests will be processed almost in parallel on each transport.

This architecture is quite beneficial. Once your application is written to establish connections in this manner, it will support any transport that NetBIOS can use. As a result, your customers will not have to configure anything within your application, and your application will not be affected by dynamic LANAs such as dial-up adapters or plug-and-play hardware.

REFERENCES

IBM NetBIOS specification version 3.0 and Win32 SDK Documentation.


Keywords          : kbnetwork kbNetBIOS kbNTOS310 kbNTOS350 kbNTOS351 kbSDKPlatform kbWinOS95 kbGrpNet 
Version           : 
Platform          : 
Issue type        : kbhowto

Last Reviewed: March 5, 1999