Sams Teach Yourself Samba in 24 Hours
Hour 2: Windows Networking
Previous
Hour|
Sections in this Chapter: |
|
|
|
||
|
||
|
Previous
SectionNext
Section
|
Sams Teach Yourself Samba in 24 Hours |
|
|||||||||||||
|
Hour 2: Windows Networking |
|
|||||||||||||
|
|
Before continuing on to the details of configuring the inner workings of Samba, this hour briefs you on some of the concepts on which those details are based. The following sections explain the fundamental ideas behind the networking model that is used by Microsoft operating systems, from Windows for Workgroups to Windows NT. This hour is a view from 10,000 feet above the networking protocols which Microsoft (and other) clients use, but it provides the basis necessary to better understand and better configure your Samba servers in later hours.
If you
have worked with Intel-based machines for any length of
time, you are probably familiar with the initial BIOS screen that appears when
the machine first boots. BIOS stands for basic input/output system.
During the mid-1980s, the concepts of a computer's BIOS were extended to emerging
network concepts. The result was a programmer's application programming interface
(API) called NetBIOS standing for network
basic input/output system. The generally accepted definition of the NetBIOS
API for this timeframe was the IBM PC Network Technical Reference Manual
published by IBM in September 1994.
Shortly
thereafter, in 1985, IBM developed a network protocol to encapsulate and extend
the NetBIOS API. The resulting protocol was named NetBEUI for NetBIOS
extended user interface. NetBEUI is optimized for
small LANs but is not routable.
In addition to NetBEUI, NetBIOS can run over IPX. Presumably this would allow Novell networks and Microsoft networks to coexist.
In 1987, the Internet Engineering Task Force (IETF) standardized the interface over TCP and UDP in Request for Comments (RFC) 1001 and RFC 1002. NetBIOS over TCP/IP is commonly referred to as NBT.
RFC 1001/1002 defined three services that were to be provided by NetBIOS over TCP/IP:
A name
service helps bridge the gap between how computers see and locate other machines
and how humans see and locate them. People tend to remember names better than
numbers, but numbers are smaller to store in computer memory. What is needed
is some mechanism to match a number with a name.
That is what a name service does. If you are familiar with TCP/IP networking, you will remember that each IP host has a hostname, such as bilbo, and an associated IP address, such as 192.168.1.73. When you type telnet bilbo from another machine, the local machine you are on has to match an IP address with the hostname bilbo before it can send any packets to the remote computer. The standard means of resolving an Internet hostname to an IP address is either by a local /etc/hosts file or by querying a domain name server.
The NetBIOS name service, defined in the RFCs 1001/1002, provides the same type of service to client as DNS. You can better understand the main difference between the two when I explain what a NetBIOS name is.
NetBIOS names exist in a flat name space and consist of 16 alphanumeric characters (for example, a to z, A to Z, and 0 to 9) plus the following:
Only 15 of the characters are available for naming the client machine. The sixteenth byte is a number from 0x00 to 0xFF representing the resource type of the name. Name ownership can be exclusive for user and machine names or shared for group names. For example, the NetBIOS name MYMACHINE<00> is an unique name representing the machine MYMACHINE. The name MYDOMAIN<1e> is a group name used by browsing clients to elect a master browser. If you have some background knowledge of TCP/IP, it might help you to think of NetBIOS resource types as being equivalent to TCP and UDP port numbers. Tables 2.1 and 2.2 list all the current NetBIOS resource tags with a short explanation.
If you want to see a practical use for these resource tags, examine the output given in Listing 2.1. from the nbtstat.exe command. The output was taken from a Windows 95 OSR2 machine and the machine being examined was a Windows NT 4.0 Workstation.
C:\users\jerry>nbtstat -a picante
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
PICANTE <00> UNIQUE Registered
SALSA <00> GROUP Registered
PICANTE <03> UNIQUE Registered
JERRYC <03> UNIQUE Registered
PICANTE <20> UNIQUE Registered
SALSA <1E> GROUP Registered
SALSA <1D> UNIQUE Registered
..__MSBROWSE__.<01> GROUP Registered
MAC Address = 00-60-97-40-CD-18
The listing in the Type column combined with the resource byte help determine what the name represents. For example, you can determine that the remote machine's name is PICANTE because it is a unique name with the <00> tag. Referring back to Table 2.1, you see the justification for this conclusion. You also can determine that for browsing purposes, the machine belongs to the SALSA workgroup because of the group entries. The <1e> tag is used to elect browse masters. The browsing process is discussed more in the section on Windows networking models later in this hour and in more detail in Hours 19, "Local Subnet Browsing," and 20, "Routed Networks and Browsing."
Previously
I stated that NetBIOS names exist in a flat name space. Although this is true,
it is possible to isolate one name space from another on the same logical subnet
by using what is referred to as a NetBIOS scope. NetBIOS scope is a string
of characters whose length plus the length of the NetBIOS name cannot exceed
256 characters.
Scope does not provide any hierarchical organization to the NetBIOS name space. It simply isolates names in one scope from machines in another. Unless you have a very good reason to set a NetBIOS scope, it is generally a good idea to simply leave it blank. Figure 2.1 illustrates the use of scope to segment machines on a network. Both machines, PICANTE and QUESO, are members of the same workgroup CHIPSNDIPS but have different scope ID settings that are appended to the machine names in the diagram. PICANTE has a scope ID of "" and QUESO has a one of "dept003". Neither one can communicate with the other as long as each has a different scope.
Figure
2.1
Using the NetBIOS scope ID to segment NetBIOS clients.
In Windows 95, you can set the scope ID by starting the Network control panel and viewing the WINS Configuration tab under the TCP/IP properties for your network adapter card. Figure 2.2 shows the scope ID field set to "dept003".
Figure
2.2
Setting the Scope ID in the Windows 95 Network control panel.
The NetBIOS
name service provides a method for registering client machine names and for
resolving those names. Registering a name means
that the client machine made a successful bid and claimed
the name so that any future request to that name will go to the client. During
bootup, the client attempts to register the name by sending a request packet
to the name service that can be either collaborative or singular in nature.
Don't worry about the difference between the two types of name servers right
now.
If another client already owns the name requested, it sends a response indicating that it has the name and wishes to keep it. When client #1 responds to a request by client #2 to register client #1's machine name, the first client is said to be defending its name, meaning that it wishes to keep the name. NetBIOS clients will always want to keep their name as long as they are functioning. Having to defend registered names is an important point because it provides a means of detecting hosts who have become inactive but did not gracefully release ownership of the name.
It might also be helpful to realize that when a NetBIOS interface is run over TCP/IP, NetBIOS names are mapped to a given IP address. Imagine the case where a client using DHCP to obtain an IP address successfully claims a name, then crashes without warning, and is unable to release the name gracefully. When the machine reboots, it attempts to reclaim the name even though it can potentially have a different IP address. Although IP addresses can be dynamically allocated, NetBIOS names are hard coded. In a Windows client, if the Client for Microsoft Networks is installed, you can find these by viewing the identification tab in the Network control panel (see Figure 2.3).
Figure
2.3
The NetBIOS machine name and workgroup settings in the Network Control panel under Windows 95.
This might seem a little confusing if you are coming from a standard TCP/IP background where the host of a host is registered in DNS or a host's file and name clashes are avoided through good administration. I admit that it is a little strange to have a machine dynamically register names by requiring that they be statically recorded on the local host.
Having registered NetBIOS names, other clients must now be able to resolve the name to a network address. In this case, this is an IP address.
Two means
are available for registration and resolution: broadcast
and point-to-point. Broadcast registration or resolution means that the
request packet is sent to all hosts on the same logical subnet with the same
scope ID. Routers can be configured to forward broadcasts, but this is generally
not a good idea because of the increase in traffic that is produced.
Point-to-point
name registration and resolution is done by using a NetBIOS name server
(NBNS). The NBNS is also described in RFC 1001/1002. The NetBIOS RFCs
allow the NBNS to accept varying degrees of responsibility with regards to the
management and validation of names. Microsoft's implementation of the NBNS,
the Windows Internet Name Service (WINS), acts as an agent to allow client to
register as well as resolve names to an IP address. Samba is also able to function
as a WINS server (see Hour 18, "Resolving NetBIOS Names
Without Using Broadcasts").
The broadcast point-to-point registration and resolution creates the following taxonomy:
In practice, most NetBIOS clients are either b-nodes, meaning that they do not use a WINS server, or are h-nodes, meaning that they do use a WINS server. You can view the current node type in Windows 95 by running the Windows IP Configuration utility (winipcfg.exe) and clicking on the More Info button. Figure 2.4 shows the More Info that is displayed as a result.
Figure
2.4
Viewing the NetBIOS node type in the Windows IP Configuration utility.
The NetBIOS
session service provides a means of supporting reliable connections and exchange
of messages between two clients. For any given connection, the sender has a
calling name and the receiver has a called
name. I mention these terms here only because they sometimes appear in error
messages from Windows clients, as well as some of the utilities included with
Samba.
Perhaps it will help to think of the relationship between the name server and the session service as a telephone connection. Before you can receive a call from your friend Pete, you need a phone number assigned by the phone company (obviously you have to have the phone unit first). This is the equivalent of registering your NetBIOS name. When both you and Pete have registered phone numbers, Pete can call you up.
His side of the connection is the NetBIOS calling name, and your side of the connection is the called name. The phone lines that connect you form the session service that carries the data (your conversation). Each phone call is its own session between you and Pete only (unless your phone has been tapped). If you move but don't tell Pete and he tries to call you, he will get someone by another name who would refuse the call. Hence the NetBIOS error message "Not listening on called name." This happens when you attempt to establish a session with another host but use the wrong name.
This service provides another capability to NetBIOS applications: the detection of failed sessions with other NetBIOS clients. I mention this more for completeness than technical reference. If you would like to find out more information about the NetBIOS session service, you will want to get a copy of RFCs 1001 and 1002.
The datagram service is really the flip side of the session service. It provides a connectionless-oriented service for sending packets to a specific host or group of hosts within a workgroup (unicast/multicast) or sending to all hosts in a logical subnet or NetBIOS scope (broadcast). The datagram service allows for things such as locating the current browse master for a workgroup or domain by multicasting the request to the workgroup name.
|
Note - You might have heard the term mailslots used in place of datagrams. Mailslots are Microsoft's name for NetBIOS datagrams. |
Let's return to the example using your friend Pete. Suppose that you don't have a phone anymore. How would Pete get in touch with you, assuming you don't live close to each other? Most likely, Pete would send you a letter in the mail. Now assume that you send Pete a letter in the mail before you receive his. In this example, your mailing address is the NetBIOS name, and the letters are packets. Next, Pete sends you another letter in response to the one you sent to him, but you never receive his first letter! This type of unreliable delivery method--I'm not criticizing the post office; this is just an example--is cheaper than a long distance phone call and is less bandwidth-intensive for the phone network (none).
Continuing to use the postal service example, suppose you want to send Christmas cards to all your friends. You send 25 cards, and all arrive safely, but you have no guarantee of the order in which people receive them. Do you ever get one of those sweepstakes entries that says, "If you're the first one to call in, you will the grand prize." This is the same type of thing. When the company sends out the notices, it has no way to control who receives the notice first, even if it mails each letter at different times. Now you get the idea of a datagram service.
|
Sams Teach Yourself Samba in 24 Hours |
|
|||||||||||||
|
Hour 2: Windows Networking |
|
|||||||||||||
|
|
© Copyright Macmillan USA. All rights reserved.
){kind=link}
){kind=link}
){kind=link}
){kind=link}