mirror of
https://github.com/samba-team/samba.git
synced 2024-12-25 23:21:54 +03:00
83a17815a7
- Same name for a doc everywhere (howto -> Samba-HOWTO-Collection, etc)
- Shorter and more clearly structured Makefile
- Make it possible to change the paths for the images
(This used to be commit 96f6c05f25
)
161 lines
6.0 KiB
XML
161 lines
6.0 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
|
|
<!ENTITY % global_entities SYSTEM '../entities/global.entities'>
|
|
%global_entities;
|
|
]>
|
|
<chapter id="netbios">
|
|
<chapterinfo>
|
|
<author>
|
|
<firstname>Luke</firstname><surname>Leighton</surname>
|
|
</author>
|
|
<pubdate>12 June 1997</pubdate>
|
|
</chapterinfo>
|
|
|
|
<title>Definition of NetBIOS Protocol and Name Resolution Modes</title>
|
|
|
|
<sect1>
|
|
<title>NETBIOS</title>
|
|
|
|
<para>
|
|
NetBIOS runs over the following tranports: TCP/IP; NetBEUI and IPX/SPX.
|
|
Samba only uses NetBIOS over TCP/IP. For details on the TCP/IP NetBIOS
|
|
Session Service NetBIOS Datagram Service, and NetBIOS Names, see
|
|
rfc1001.txt and rfc1002.txt.
|
|
</para>
|
|
|
|
<para>
|
|
NetBEUI is a raw NetBIOS frame protocol implementation that allows NetBIOS
|
|
datagrams to be sent out over the 'wire' embedded within LLC frames.
|
|
NetBEUI is not required when using NetBIOS over TCP/IP protocols and it
|
|
is preferable NOT to install NetBEUI if it can be avoided.
|
|
</para>
|
|
|
|
<para>
|
|
IPX/SPX is also not required when using NetBIOS over TCP/IP, and it is
|
|
preferable NOT to install the IPX/SPX transport unless you are using Novell
|
|
servers. At the very least, it is recommended that you do not install
|
|
'NetBIOS over IPX/SPX'.
|
|
</para>
|
|
|
|
<para>
|
|
[When installing Windows 95, you will find that NetBEUI and IPX/SPX are
|
|
installed as the default protocols. This is because they are the simplest
|
|
to manage: no Windows 95 user-configuration is required].
|
|
</para>
|
|
|
|
<para>
|
|
NetBIOS applications (such as samba) offer their services (for example,
|
|
SMB file and print sharing) on a NetBIOS name. They must claim this name
|
|
on the network before doing so. The NetBIOS session service will then
|
|
accept connections on the application's behalf (on the NetBIOS name
|
|
claimed by the application). A NetBIOS session between the application
|
|
and the client can then commence.
|
|
</para>
|
|
|
|
<para>
|
|
NetBIOS names consist of 15 characters plus a 'type' character. This is
|
|
similar, in concept, to an IP address and a TCP port number, respectively.
|
|
A NetBIOS-aware application on a host will offer different services under
|
|
different NetBIOS name types, just as a host will offer different TCP/IP
|
|
services on different port numbers.
|
|
</para>
|
|
|
|
<para>
|
|
NetBIOS names must be claimed on a network, and must be defended. The use
|
|
of NetBIOS names is most suitable on a single subnet; a Local Area Network
|
|
or a Wide Area Network.
|
|
</para>
|
|
|
|
<para>
|
|
NetBIOS names are either UNIQUE or GROUP. Only one application can claim a
|
|
UNIQUE NetBIOS name on a network.
|
|
</para>
|
|
|
|
<para>
|
|
There are two kinds of NetBIOS Name resolution: Broadcast and Point-to-Point.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>BROADCAST NetBIOS</title>
|
|
|
|
<para>
|
|
Clients can claim names, and therefore offer services on successfully claimed
|
|
names, on their broadcast-isolated subnet. One way to get NetBIOS services
|
|
(such as browsing: see ftp.microsoft.com/drg/developr/CIFS/browdiff.txt; and
|
|
SMB file/print sharing: see cifs4.txt) working on a LAN or WAN is to make
|
|
your routers forward all broadcast packets from TCP/IP ports 137, 138 and 139.
|
|
</para>
|
|
|
|
<para>
|
|
This, however, is not recommended. If you have a large LAN or WAN, you will
|
|
find that some of your hosts spend 95 percent of their time dealing with
|
|
broadcast traffic. [If you have IPX/SPX on your LAN or WAN, you will find
|
|
that this is already happening: a packet analyzer will show, roughly
|
|
every twelve minutes, great swathes of broadcast traffic!].
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>NBNS NetBIOS</title>
|
|
|
|
<para>
|
|
rfc1001.txt describes, amongst other things, the implementation and use
|
|
of, a 'NetBIOS Name Service'. NT/AS offers 'Windows Internet Name Service'
|
|
which is fully rfc1001/2 compliant, but has had to take specific action
|
|
with certain NetBIOS names in order to make it useful. (for example, it
|
|
deals with the registration of <1c> <1d> <1e> names all in different ways.
|
|
I recommend the reading of the Microsoft WINS Server Help files for full
|
|
details).
|
|
</para>
|
|
|
|
<para>
|
|
The use of a WINS server cuts down on broadcast network traffic for
|
|
NetBIOS name resolution. It has the effect of pulling all the broadcast
|
|
isolated subnets together into a single NetBIOS scope, across your LAN
|
|
or WAN, while avoiding the use of TCP/IP broadcast packets.
|
|
</para>
|
|
|
|
<para>
|
|
When you have a WINS server on your LAN, WINS clients will be able to
|
|
contact the WINS server to resolve NetBIOS names. Note that only those
|
|
WINS clients that have registered with the same WINS server will be
|
|
visible. The WINS server _can_ have static NetBIOS entries added to its
|
|
database (usually for security reasons you might want to consider putting
|
|
your domain controllers or other important servers as static entries,
|
|
but you should not rely on this as your sole means of security), but for
|
|
the most part, NetBIOS names are registered dynamically.
|
|
</para>
|
|
|
|
<para>
|
|
This provides some confusion for lots of people, and is worth mentioning
|
|
here: a Browse Server is NOT a WINS Server, even if these services are
|
|
implemented in the same application. A Browse Server _needs_ a WINS server
|
|
because a Browse Server is a WINS client, which is _not_ the same thing].
|
|
</para>
|
|
|
|
<para>
|
|
Clients can claim names, and therefore offer services on successfully claimed
|
|
names, on their broadcast-isolated subnet. One way to get NetBIOS services
|
|
(such as browsing: see ftp.microsoft.com/drg/developr/CIFS/browdiff.txt; and
|
|
SMB file/print sharing: see cifs6.txt) working on a LAN or WAN is to make
|
|
your routers forward all broadcast packets from TCP/IP ports 137, 138 and 139.
|
|
You will find, however, if you do this on a large LAN or a WAN, that your
|
|
network is completely swamped by NetBIOS and browsing packets, which is why
|
|
WINS was developed to minimise the necessity of broadcast traffic.
|
|
</para>
|
|
|
|
<para>
|
|
WINS Clients therefore claim names from the WINS server. If the WINS
|
|
server allows them to register a name, the client's NetBIOS session service
|
|
can then offer services on this name. Other WINS clients will then
|
|
contact the WINS server to resolve a NetBIOS name.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
</chapter>
|