Chapter 13 - Using NetBEUI with Windows NT

The NetBEUI protocol was one of the earliest protocols available for use on networks composed of personal computers. In 1985, IBM introduced NetBEUI to provide a protocol that could be used with software programs designed around the Network Basic Input/Output System (NetBIOS) interface.

NetBEUI was designed as a small, efficient protocol for use in department-sized local area networks (LANs) of 20 to 200 computers that do not need to be routed to other subnets. Today, NetBEUI is used almost exclusively on small, non-routed networks composed of computers running under a variety of operating systems that can include Microsoft Windows NT Server 3.5 and later, Windows NT Workstation version 3.5 and later, Microsoft LAN Manager, Windows for Workgroups, Windows 3.1, Windows NT version 3.1, and LAN Manager for UNIX as well as IBM PCLAN and LAN Server.

Windows NT-based NetBEUI, also referred to as NBF because it uses NetBEUI Frame (NBF), implements the IBM NetBIOS Extended User Interface (NetBEUI) 3.0 specification. This protocol provides compatibility with existing LANs that use the NetBEUI protocol and is compatible with the NetBEUI protocol driver shipped with past Microsoft networking products.

This chapter describes Windows NT-based NetBEUI and how it interfaces with the architecture of Windows NT Server and Windows NT Workstation to support connection-oriented and connectionless data transfer and to support a virtually infinite number of network sessions (logical connections between networked computers).

The information presented in this chapter is intended for the network administrator and support personnel who need to understand NetBEUI and to manage computers that connect to the network by using the NetBEUI protocol. You should be familiar with the architecture of Windows NT Server and Windows NT Workstation to understand the information discussed in this chapter. For information about the architecture of Windows NT Server, refer to Chapter 1,"Windows NT Networking Architecture" in this book. For information about the architecture of Windows NT Workstation, refer to the Windows NT Workstation Resource Guide.

Overview of Windows NT NetBEUI

The Windows NT-based implementation of NetBEUI, referred to as NBF throughout the remainder of this chapter, does the following:

Uses the Windows NT-based Transport Driver Interface (TDI) which provides an emulator for interpretation of NetBIOS network commands. 

Uses the Windows NT-based Network Device Interface Specification (NDIS) version 3.0 with improved transport support and a full 32-bit asynchronous interface.

Note Developers who require detailed information about the NDIS 4.0 specification should see the Windows NT Device Driver Kit (DDK).

Removes the NetBIOS session number limit. 

Uses memory dynamically to provide automatic memory tuning. 

Supports dial-up client communications with Remote Access Service (RAS) services. 

Provides connection-oriented and connectionless data transfer services. 

Interoperability Using NBF

NBF provides compatibility with computers running under the earlier operating systems of Microsoft LAN Manager and MS-Net, and IBM LAN Server. NBF can be used to connect LAN workstation and server computers, and to connect remote and dial-up clients, including laptop computers, to computers running the Windows NT-based RAS.

NBF can be used with programs that implement a variety of services based on the following application programming interfaces (APIs):

NetBIOS 

Named Pipes 

Mailslot 

Network DDE (dynamic data exchange) 

Remote Procedure Call (RPC) over NetBIOS 

RPC over Named Pipes 

NBF is most efficient when used for computers connecting to small to medium-sized, single-location networks. NBF is not a routable protocol like TCP/IP or IPX, although NBF does support a form of routing known as Token Ring routing, available only on IBM Token Ring networks. Additionally, NBF uses a single part naming scheme that does not support network segmentation used in most large networks.

Architecture of NBF

NBF is a transport driver that is composed of the following layers:

LLC802.2 Protocol Corresponds to the Open Systems Interconnect (OSI) Logical Link Control (LLC) layer. It performs code, address, and control frame flow, and provides connectionless data transfer. NetBIOS Frame Protocol (NBFP) Corresponds to the OSI Transport and Session layers. It performs session establishment, multiplexing, and termination. It also performs message segmentation, delimiting, assembly, and acknowledgment.

Figure 13.1 shows the components of NBF and their relation to the OSI model.

 

Figure 13.1 The OSI Model and the Architecture of NBF 

Notice that the upper edge of NBF, the NBFP component, connects to the bottom edge of the Windows NT-based Transport Driver interface (TDI). The lower edge of NBF, the LLC component, connects to the Network Driver Interface (NDIS).

Note In the preceding illustration, the Network layer between NBFP and LLC is intentionally empty. In the OSI model, the Network layer lies between the Transport and LLC layers. However, NetBEUI uses IBM Token Ring source routing to perform network layer functions. Token Ring source routing conforms to a different standard, the IEEE 802.5 standard, and logically corresponds to the OSI Physical layer, not the OSI Network layer.

The following sections describe the NBF functions at its upper and lower edges:

"NBF's Interface to the Upper OSI Layers—The TDI Interface" 

"NBF's Interface to the Lower OSI Layers—The NDIS Interface"

NBF's Interface to the Upper OSI Layers—The TDI Interface

Software programs that rely on NBFP for network communication require a transport driver that exposes the NetBIOS interface. However, the Windows NT-based transport drivers for NBF, IPX, and TCP/IP do not expose a NetBIOS interface; instead they expose the more flexible Windows NT TDI, as illustrated in both Figure 13.1 and Figure 13.2.

The Windows NT TDI provides a NetBIOS emulator that maps NetBIOS commands to TDI commands to support applications designed for use with NBFP. Note that Figure 13.2 illustrates how both NetBIOS-based and Windows Sockets-based applications use the TDI.

 

Figure 13.2 The Transport Driver Interface (TDI) and NBF 

Note In the preceding figure, the term "transport providers" refers to the binding of a specific transport driver, such as NBF, to a specific underlying NIC driver. Computers in which multiple NIC cards are installed will have multiple bindings.

This is how the TDI supports NetBIOS-based applications: NetBIOS commands are formatted as network control blocks (NCBs). When a program running on a Windows NT-based computer creates an NCB, the NetBIOS command is first processed by the Windows NT-based NetBIOS driver (Netbios.sys). Netbios.sys processes the NCB by mapping it to the corresponding TDI command or commands, and sends the TDI command to the Windows NT-based NetBEUI driver (Nbf.sys). (TDI calls implement the same general semantics as NetBIOS NCBs, but are optimized for a 32-bit kernel interface.)

In other words, unlike 16-bit Windows and MS-DOS transport clients which send NCBs directly to a NetBEUI driver, the NetBIOS network applications running on a Windows NT-based computer must direct the NCBs to a NetBIOS emulator. The NetBIOS emulator creates TDI requests and sends the TDI requests to the NBF transport driver.

NBF's Interface to the Lower OSI Layers — The NDIS Interface

The NBF transport driver processes the TDI requests as frames that are to be sent out on the network in the Logical Link Control (LLC) layer. This lower edge, the LLC layer, is the NBF layer that receives frames sent from a remote computer on the network.

NBF conforms to the IEEE 802.2 LLC protocol standard and performs the following functions:

Link establishment (connection-oriented data transfer) 

Maintenance and termination 

Frame sequencing and acknowledgment 

Frame flow control 

Connectionless data transfer 

At the LLC layer, NBF binds, receives, and sends packets to the underlying NIC drivers by using the NDIS 4.0 interface. (See the earlier note about the term "transport providers.")

Communication within the LLC layer is based on service access points, links, and link stations. Each LLC client program identifies itself by registering a unique service access point (SAP). A SAP is actually a mechanism by which the layer above can programmatically access a particular service implemented by the layer below. A SAP can also be thought of as the address of a software port as defined by the OSI model. There are well-known SAPs, similar to the well-known ports of TCP/IP. Because NBF is a NetBIOS implementation, it uses the well-known NetBIOS SAP (0xF0). This is illustrated in Figure 13.3, which shows the relationship of the SAP to the LLC Layer.

 

Figure 13.3 The NBF LLC Layer and NDIS Interface to the Physical Layers 

When a network client program uses LLC to send a frame on to the network, LLC specifies the client SAP as well as the destination SAP in the header of the LLC frame. The header of an LLC frame thus identifies the:

Source service access point (SSAP)—the LLC client on the sending computer that created the frame. 

Destination service access point (DSAP)—the LLC client on the receiving computer that should receive the frame. 

The SSAP, DSAP, and NIC address of the destination client are all that is needed for unreliable connectionless data transfer, in which NBF transmits the message once or a specified number of times and is responsible only for ensuring that the frame is properly transmitted on the network medium. No acknowledgment from the destination client is required.

Reliable connection-oriented data transfer service requires establishment of a link between the sending and receiving LLC clients in which NBF is responsible for transferring the frame from the source client to the destination client and which requires an acknowledgment from the destination client that the frame is received. The link is established by using the sending client SAP, the destination client SAP, and the NIC address of the remote computer. Note that the NIC address of the receiving client can be specified as:

An individual computer's NIC address where the LLC frame is received by a single LLC client that registered the destination SAP. 

A NetBIOS multicast address where the LLC frame is received by all LLC clients that have registered the multicast destination SAP. 

NBF Removes the NetBIOS Session Limit

Early versions of NetBEUI used a 1- byte (8-character binary) number with a maximum decimal value of 254 to identify NetBIOS sessions. Session numbers were assigned per computer. That is, a computer using NetBEUI could support a maximum of 254 network connections.

NBF is not constrained by the session limitation of earlier versions of NetBEUI. NBF uses the TDI and a TDI 32-bit handle composed of the session number and the network address of the remote computer. This allows a virtually limitless range of unique numbers that can be used to uniquely identify sessions.

Using NBF, it is possible for a Windows NT Server with a single network adapter card to support simultaneous sessions that exceed the previous NetBEUI session limit of 256. For example, a Windows NT Server running NBF with a single network adapter card is able to support sessions with more than 1,000 clients.

The following figure illustrates the differences between NBF and other non-Windows implementations of NetBEUI.

 

Figure 13.4 Comparison between NetBEUI and Windows NT NBF Session Limits 

NBF Dynamically Allocates Memory

A Windows NT-based computer running NBF automatically allocates the memory necessary to process the requests made by session clients. This means that NBF uses memory only when needed. For example, on a Windows NT-based computer that does not have an active network connection, very little memory will be used by the NBF protocol stack.

Because of this dynamic memory management, installing NBF on a Windows NT-based computer is easily done. It does not require additional configuration for number of sessions, packets, or buffers.

NBF Supports RAS Clients

NBF is used by remote computers that need to connect to a computer running Windows NT Server with RAS server. Because NBF dynamically allocates memory and is self-tuning, no configuration is required on the computer running the RAS client service. However, the WanNameQueryRetries parameter in the Registry can be changed to fine-tune RAS name query performance by using the Registry Editor. (This parameter is the WAN equivalent of the NameQueryRetries parameter.)

Connection-oriented and Connectionless Data Transfer

NBF supports both unreliable connectionless and reliable connection-oriented data transfer. Unreliable connectionless data transfer is also called datagram, or Type 1, operation.

Unreliable connectionless communication is similar to sending a letter in the mail. No response is generated by the receiver of the letter to tell the sender that the letter made it to its destination.

Note Connectionless communications can be either unreliable or reliable. NBF provides only unreliable connectionless communications. Reliable connectionless communications is like a registered letter whose sender is notified that the letter arrived.

In unreliable connectionless communicaton, the transport protocol driver transmits the message once or a specified number of times, ensuring only that the message was properly transmitted to the network medium. The message can only be a single frame. Acknowledgment from the destination computer is not required.

Note If reliable connectionless communication is required, NBF can be configured for certain communication commands to send a number of frames that will allow time for the destination computer to respond to the message. The number is based on retry Registry value entries, such as NameQueryRetries. The time between sending each frame is determined by timeout Registry entries, such as NameQueryTimeout.

Reliable connection-oriented communication is also called session, or Type 2, operation. Reliable connection-oriented communication provides reliable communications between two computers in a way that is analogous to a phone call where two callers connect, a conversation occurs, and then the connection is dropped when the conversation ends. A reliable connection requires more overhead than connectionless communications do.

In reliable connection – oriented communications, the transport protocol driver assumes responsibility for transferring the entire message from source to destination, and within an acceptable time period. Sequencing is provided; a message that is larger than the maximum transmit frame size can be broken down into multiple frames, sent across the network, and properly reassembled at the receiving computer.

Connectionless Traffic

Three types of NetBIOS commands generate connectionless traffic:

Name claim and resolution

Datagrams

Miscellaneous commands 

These commands are sent as Unnumbered Information (UI) frames at the LLC sublayer.

To understand how Windows NT Server and Windows NT Workstation use retry and timeout values, consider what happens when the Windows NT-based computer running NBF registers its NetBIOS computer name. The Windows NT-based computer sends a multicast message containing an ADD_NAME_QUERY frame on to the network. Other computers on the network running NBF can retrieve and process the ADD_NAME_QUERY message. The multicast frames are sent a total of AddNameQueryRetries times at time intervals of AddNameQueryTimeout. This allows computers on the network enough time to inform the sending computer whether the name is already registered as a unique computer name or as a group name on the network.

Note All Registry values discussed in this chapter are found under the following Registry path:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Nbf 

Connection-oriented Traffic

The net use command is an example of a connection-oriented communication, as illustrated in Figure 13.5.

 

Figure 13.5 Connection-oriented Network Traffic 

When a user types net use at the command line to connect to a shared resource, NBF must first locate the server by sending UI-frames, and then initialize the link. This is handled by the redirector when it makes a connection to the NBF drivers by using the TDI interface. NBF begins the sequence by generating a NetBIOS Find Name frame. Once the server is found, a session is set up with Class-II frames which contain timing parameters following the 802.2 protocol standard (802.2 governs the overall flow of data).

The client computer sends a Set Asynchronous Balance Mode Extended (SABME) frame, and the server returns an Unnumbered Acknowledgment (UA) frame. Then the client sends a Receive Ready (RR) frame, notifying the server that it is ready to receive Informational (I) frames whose sequence number is currently 0. The server acknowledges this frame.

Once the LLC-level session is established, additional NetBEUI-level information is exchanged. The client sends a Session Initialize frame, and then the server responds with a Session Confirm frame. At this point, the NetBEUI-level session is ready to handle application-level frames (Server Message Blocks, or SMBs).

Reliable transfer is achieved with link-oriented frames by numbering the I-frames. This allows the receiving computer to determine whether the frames were lost and in what order they were received.

NBF improves performance for connection-oriented traffic through two techniques: use of adaptive sliding windows and use of link timers. The next two sections describe these techniques.

Adaptive Sliding Window Protocol

NBF uses an adaptive sliding window algorithm to improve performance while reducing network congestion and providing flow control. A sliding window algorithm allows the Windows NT-based computer using NBF to dynamically tune the number of LLC frames sent before an acknowledgment is requested. Figure 13.6 shows frames traveling through a two-way pipe.

 

Figure 13.6 Adaptive Sliding Window 

If the sending computer could send only one frame on to the network and then had to wait for an acknowledgment (ACK), the sending computer would be underused. The frames would travel forward, and then ACKs for the received frames would have to travel back to the sending computer before it could send another frame. The number of frames that the sender is allowed to send before it must wait for an ACK is referred to as the send window.

The number of frames that a receiving computer is allowed to receive before sending an ACK to the sending computer is referred to as a receive window. In general, NBF has no receive window, unless it detects that the remote sending computer is running a version of IBM NetBEUI which does not support polling; in this case, NBF uses a receive window based on the value of MaximumIncomingFrames in the Registry.

The default value for MaximumIncomingFrames is 2 and this value does not dynamically change. It must be manually changed by using the Registry Editor. For additional information about the receive window, refer to "Using Windows NT NetBEUI in IBM LAN Server Networks" in the section "Troubleshooting NetBEUI" later in this chapter.

The adaptive sliding window protocol tries to determine the best sizes for the send window based on current network conditions. Ideally, the windows should be big enough so that maximum throughput can be realized. However, if the window gets too big, the receiving computer could get overloaded and drop frames.

Dropped frames cause significant network traffic because more frames have to be retransmitted. Dropped frames might be a problem on slow links or when frames have to pass over multiple hops to find the destination computer. Dropped frames coupled with large send windows generate multiple retransmissions. This traffic overhead might make an already congested network worse. Limiting the send window size can improve performance by reducing network traffic.

Link Timers

NBF uses three timers to help regulate network traffic: the response timer (T1), the acknowledgment timer (T2), and the inactivity timer (Ti). These timers are controlled by the values of the Registry parameters DefaultT1Timeout, DefaultT2Timeout, and DefaultTiTimeout, respectively.

The response timer is used to determine how long the sender should wait before it assumes that the I-frame is lost. After T1 milliseconds, NBF sends an RR frame and doubles the value for T1. If the RR frame is not acknowledged after the number of retries defined by the value of LLCRetries, the link is dropped.

Where the return traffic does not allow the receiver to send an I-frame within a legitimate time period, the acknowledgment timer begins, and then the ACK is sent. The value for this timer is set by the T2 variable, with a default value of 150 milliseconds. If the sender has to wait until the T2 timer starts in order to receive
a response, the link might be underused while the sender waits for the ACK. This rare situation can occur over slow links. On the other hand, if the timer value is too low, the timer starts and sends unnecessary ACKs, generating excess traffic. NBF is optimized so that the last frame that the sender wants to send is sent with the POLL bit turned on. This forces the receiver to send an ACK immediately.

The inactivity timer, Ti, is used to detect whether the link has gone down. The default value for Ti is 30 seconds. If Ti milliseconds pass without activity on the link, NBF sends an I-frame for polling. This is then ACKed, and the link is maintained.

Note Remember that T2 is less than or equal to T1, which is less than or equal to Ti.

The T1 parameter is tuned dynamically on a per-link basis, based on link conditions and throughput. The value of the T1 parameter as specified in the Registry is used as the starting value for how long the process should wait for a response. This registry parameter can be changed. For example, if you know that the computer connects to the network on a slow link, the T1 registry parameter value can be increased. However, even if this parameter is not changed, NBF can detect the slow link quickly and automatically tune the T1 registry parameter value.

T2 and Ti are not adapted dynamically.

NBF Sessions

Each process that uses Windows NT-based NetBIOS can communicate with up to 254 different computers. Earlier implementations of NetBIOS supported only 254 sessions for the entire computer, including the workstation and server components.

The implementation of NetBIOS under Windows NT requires that an application do a few more things than have traditionally been required in other NetBIOS implementations, but the capacity for maintaining up to 254 sessions from within each process by using Windows NT-based NetBIOS is well worth the price.

Note that the 254-session limit does not apply to the default workstation or server components of Windows NT. The workstation and server services avoid the session limit problem completely by writing directly to the TDI, which is a 32-bit handle-based interface, instead of writing directly to the NetBIOS interface.

NBF also has a unique method of handling resources to create a virtually infinite (local computer memory permitting) number of connections, as described in the next section.

Session Limits

The 254-session limit is based on a key variable in the NetBIOS architecture called the Local Session Number (LSN). This is a 1-byte number (0 to 255) with several numbers reserved for system use. When two computers establish a session via NBF, there is an exchange of LSNs.

The LSNs on the two computers might be different. They do not have to match, but a computer always uses the same LSN for a given session. This number is assigned when a program issues a call for a Network Control Block (CALL NCB). The number is actually shared between the two computers in the initial frame sent from the calling computer to the listening computer. Figure 13.7 shows this session-creation frame exchange.

 

Figure 13.7 Multicast of NameQuery 

The initial frame is a NameQuery frame. In earlier implementations of NBF, this frame was broadcast onto the network. All computers read the frame and check to see if they have the name in their name space and if there is a LISTEN NCB pending on the name. If there is a LISTEN NCB pending, the computer assigns a new LSN for itself. It adds the LSN to the response frame, satisfying the LISTEN NCB which now contains just the LSN used on that computer. Even though each computer knows the LSN of the other, the information is not used. The more important information for the two communicating partners is the network addresses that are part of the frames. As the frames are exchanged, each partner picks up the address of the other in the source address component of the frame received. The NBF protocol keeps the network address of the remote partner so that subsequent frames can be addressed directly.

Note This process applies only to NBF connections. NetBIOS connections established by using NetBIOS over TCP/IP (NetBT) are handled differently.

Windows NT has to use the same NameQuery frame to establish connections with remote computers via NBF; otherwise, it would not be able to talk to existing workstations and servers. The NameQuery frame transmitted must contain the 1-byte-wide LSN to be used.

For example, suppose a computer running Windows NT Server and NBF assigns a session number of 1 to identify the session between itself and Computer A and also assigns the number 1 for the simultaneous session with Computer B. The computer running Windows NT Server can identify the different sessions because it uses the computer network address as part of the TDI handle to further identify each session. When the computer running Windows NT Server sends a session frame to either Computer A or Computer B, it uses the network address to direct the frame across the network. Therefore, Computer A does not receive the frames addressed to Computer B, and vice versa. However, if the computer running Windows NT Server and NBF establishes another session with Computer A, it must use a session number other than 1 to uniquely identify the second session.

A Windows NT Server computer running NBF can do this only when it is able to determine beforehand which adapter the session connection is going to be made to. Consider the following three scenarios:

1.

A client connecting to a Windows NT computer running NBF. 

When a client connects to a computer running NBF, NBF can inspect the incoming frame to determine the remote adapter's address and assign a session number for that adapter. 

2.

NBF connecting to a remote client with a unique NetBIOS name. 

When NBF is connecting to a remote client, it first sends a FINDNAME frame. A response from the remote client means that the name is a unique name. NBF can then look at the remote adapter address in the response and assign a session number for that adapter because it knows that only that remote client owns this name. 

3.

NBF connecting to a remote client with a group NetBIOS name. 

If the FINDNAME response indicates that the connection is being made to a group name, NBF has no way of knowing which adapter belonging to the group will respond when it tries to connect, and so it has to assign a session number on a global basis, just as NetBEUI did for all connections. 

These scenarios show that NBF has no limit on sessions, unless it is establishing connections to group names, in which case the old NetBEUI limit still applies. To be accurate, if you have n group name connections, then you can have 254-n connections to any given remote client. If n is 0, then you can have a full 254 connections to a remote. If n is 253, you can still have 1 connection to each remote, but if n is 254, then no connections can be made until one of the existing ones is disconnected.

Breaking the 254-session Limit

NBF breaks the 254-session barrier by using a combination of two matrices, one maintained by NBF and one maintained by NetBIOS.

The matrix maintained by NBF is two-dimensional, as shown in Figure 13.8.

 

Figure 13.8 NBF and Its LSN Matrix 

Along the side of this matrix are the LSN numbers 1 to 254. Across the top are the network addresses for the different computers that it has sessions with. In the cell defined by the intersection of the LSN and network address is the TDI handle, which relates back to the process that established the connection (either the CALL or LISTEN).

Note The matrix concept and its contents are for illustration purposes only. The physical storage algorithm and exact contents are beyond the scope of this chapter.

The NameQuery frame from Windows NT contains the LSN number associated with the TDI handle that satisfies either the NCB CALL or the LISTEN. In the case of a CALL, it is not broadcast but is addressed directly to the remote computer.

The remaining question is how NBF gets the network address of the remote computer to add to its matrix to be used when doing the CALL. (It's easy on the LISTEN side because the address is in the NameQuery frame received.)

Figure 13.9 illustrates the NCB CALL and NCB LISTEN frames.

 

Figure 13.9 NameQuery Frames in NBF

The numbered items in Figure 13.9 represent the following:

1.

The first frame (1) is the FindName frame of the NameQuery. However, an LSN of 0 is special; it indicates that it is a FindName frame. The FindName frame is broadcast on the network; when a remote computer responds to the frame, NBF on the local computer receives the network address of the remote computer.

2.

The second frame (2) of the NameQuery is then sent directly to the remote computer by using the network address and a LSN value that indicates it is a CALL command. The remote client returns a successful FindName frame, even if no LISTEN NCB is posted against the name.

3.

If no LISTEN NCB is posted against the name, frame (3) is sent. 

4.

The same frame is responded to by frame (4). 

NBF must also address another problem—the LSN from the NBF matrix cannot be the one returned to the process issuing the CALL or LISTEN commands. NBF may have established connections with multiple remote computers with LSN=5, for example. Windows NT must return to each process an LSN number that uniquely defines its session.

As stated earlier, NBF uses the TDI handle to know which LSN and network address to send frames to, and each process has its own set of LSNs available to it. Therefore, there must be a component between the originating process and the TDI interface of NBF that translates a process ID and an LSN into a TDI handle. The component in the middle is Netbios.sys.

Figure 13.10 illustrates the Netbios.sys matrix, which is 254 LSNs per LAN adapter number per process. (In Windows NT, the LANA number identifies a unique binding of a protocol driver and one network adapter (NIC) driver.) In reality, each process can have up to 254 sessions per LANA number, not just a total of 254 sessions.

 

Figure 13.10 Netbios.sys Matrix 

Netbios.sys builds a second matrix that has LSNs down the side, process IDs along the top, and TDI handles in the cells. It is the LSN from this table that is passed back to the originating process.

To further understand how Netbios.sys uses this matrix, suppose a process needs to establish a session with a remote computer. Before the process can issue the CALL NCB, it must issue a RESET NCB. This command signals Netbios.sys to allocate space in its TDI handle table, among other things. Once the RESET is satisfied, the process issues a CALL NCB to make a connection with a specific remote computer. This NCB is directed down to the Netbios.sys device driver. The driver opens a new TDI handle to NBF and sends the command to NBF.

NBF issues the first NAME_QUERY with LSN=0 to find the remote computer. When the remote computer responds, the network address is extracted from the frame, and a column in the NBF table is created. The second NAME_QUERY with an LSN is sent directly to the remote computer. When that frame is returned successfully, NBF returns from the TDI call to the Netbios.sys driver with a successful status code.

Netbios.sys then fills in the LSN from its table into the NCB and sends it back to the calling process.

Limited Network Routing Using NBF

Multi-location networks, such as a wide area network (WAN), require routing capabilities, while single-location, small- to medium-sized local area networks (LANs) generally do not require the overhead of a routing protocol.

NBF is not a routable protocol. It uses a single-part naming scheme which cannot be used to differentiate between computers belonging to multiple interconnected networks. NBF can provide a simple form of routing known as Token Ring source routing, and it can only be implemented on Token Ring networks.

Token Ring source routing occurs when NBF broadcasts a name query frame on a local token ring; if it doesn't receive a response in a set period of time, it enables source routing fields in the name query ring frame that force source routing bridges to receive and process the frame. The source routing bridges add additional routing information to the frame and send it to all other rings to which the bridge is connected. When the name query frame reaches the desired computer, that computer sends its computer name in the return message frame, using the routing information from the query to send the message directly to the originating computer. The originating computer caches the routing information and uses the cache to address subsequent frames.

Troubleshooting NetBEUI

This section discusses problems that you might encounter on a Windows NT-based computer on which the NetBEUI protocol is installed and running.

Note NBF is the underlying implementation of the NetBEUI protocol installed on a computer running Windows NT Server or Windows NT Workstation. Most users are more familiar with the term NetBEUI. When troubleshooting, it is more common to use the term NetBEUI, rather than NBF.

Tuning NetBEUI Using Registry Parameters

When NetBEUI is installed on a Windows NT-based computer, it is installed with default configurations. Because NBF is largely self-tuning, no configuration is required when installing NetBEUI on a Windows NT–based computer.

If desired, however, you can change the default values for NetBEUI registry parameters. The NetBEUI startup parameters are found under the following subkey:

HKEY_LOCAL_MACHINE \SYSTEM \Services \NBF \Parameters 

Warning Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the incorrect use of Registry Editor can be solved. Use this tool at your own risk.

Changing a NetBEUI Binding

You can manually change the NetBEUI bindings. The changes you can make are:

Enable a binding 

Disable a binding 

Move the order (priority) of the bindings up or down 

To change a NetBEUI binding 

1.

Click Start, point to Settings, and click Control Panel

2.

Double-click Network

3.

Click the Bindings tab.

4.

In Show Bindings for, click all protocols

5.

Double-click NetBEUI Protocol to display a list of bindings. 

6.

Select the binding you want to change and then click the appropriate action button. 

7.

Click OK

Source Routing Not Supported in FDDI Network

Source routing is only supported for Token Ring networks. A network using a fiber data distributed interface (FDDI) for network communications cannot use NBF for source routing. To correct this problem, use transparent source routing or transparent bridging.

No Session Alive Frames

NBF does not use NetBIOS session alive frames to determine if the remote client is up. Instead, it sends LLC poll frames, which serve the same purpose. NBF will respond correctly to session alive frames, so this should cause no interoperability problems with other implementations of NetBEUI.

Using Windows NT NetBEUI in IBM LAN Server Networks

In general, NBF has no receive window, unless it detects that the remote sending computer is running a version of IBM NetBEUI which does not use network polling—for example, IBM LAN Server. NBF initiates a link with a remote computer in the same manner as IBM NetBEUI; however, NBF looks for a poll bit in received frames. If a frame is received that does not have the poll bit set, the Windows NT-based computer will wait until T2 expires before sending a frame ACK.

Note When the poll bit is set in a received frame, NBF ignores the receive window and immediately sends an ACK.

For example, an IBM LAN Server computer is a non-polling system that may have a send window set to 1. If this the case, the registry parameter MaxIncomingFrames should be decreased from its default of 2 to 1. If not, the non-Windows NT-based computer will wait for an ACK from the Windows NT-based computer, which in this case will be sent only when the T2 time limit expires.

NBF uses a receive window based on the value of MaximumIncomingFrames in the Registry. The default value for MaximumIncomingFrames is 2, and this value does not dynamically change. It must be manually changed by changing the parameter default value in the Registry.

Note When a Windows NT-based computer is using the MaxIncomingFrames receive window, it may not always send an acknowledgment frame after receiving exactly MaxIncomingFrames packets. This is because NBF will also wait until it receives an NDIS ProtocolReceiveComplete before sending the ACK. However, when the Windows NT-based computer receives POLL frames, it will ACK immediately (typically on return from NdisTransferData (synchronous communications) or within ProtocolTransferDataComplete (asynchronous communications).

NetBEUI Browser Does Not See TCP/IP Clients

Browsing on a computer running under Windows NT is based on a per protocol basis. In other words, there is a master browser for each protocol. Computers running only the NetBEUI protocol register with the master browser computer running the NetBEUI protocol. Computers running only NetBEUI get the master browser list from the master browser running NetBEUI. Because computers running only the TCP/IP protocol register with a master browser running TCP/IP, these computers will not be on the master browser list from a computer running only NetBEUI.



© 2016 Microsoft Corporation. All rights reserved. Contact Us |Terms of Use |Trademarks |Privacy & Cookies