diff options
Diffstat (limited to 'docs-xml/Samba3-HOWTO/TOSHARG-Integrating-with-Windows.xml')
| -rw-r--r-- | docs-xml/Samba3-HOWTO/TOSHARG-Integrating-with-Windows.xml | 745 |
1 files changed, 745 insertions, 0 deletions
diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-Integrating-with-Windows.xml b/docs-xml/Samba3-HOWTO/TOSHARG-Integrating-with-Windows.xml new file mode 100644 index 0000000000..68b9d49b69 --- /dev/null +++ b/docs-xml/Samba3-HOWTO/TOSHARG-Integrating-with-Windows.xml @@ -0,0 +1,745 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<chapter id="integrate-ms-networks"> + +<chapterinfo> + &author.jht; + <pubdate> (Jan 01 2001) </pubdate> +</chapterinfo> + +<title>Integrating MS Windows Networks with Samba</title> + +<para> +<indexterm><primary>NetBIOS</primary></indexterm> +This chapter deals with NetBIOS over TCP/IP name to IP address resolution. If +your MS Windows clients are not configured to use NetBIOS over TCP/IP, then this +section does not apply to your installation. If your installation involves the use of +NetBIOS over TCP/IP, then this chapter may help you to resolve networking problems. +</para> + +<note> +<para> +<indexterm><primary>NetBEUI</primary></indexterm> +<indexterm><primary>LLC</primary></indexterm> +NetBIOS over TCP/IP has nothing to do with NetBEUI. NetBEUI is NetBIOS +over Logical Link Control (LLC). On modern networks it is highly advised +to not run NetBEUI at all. Note also that there is no such thing as +NetBEUI over TCP/IP &smbmdash; the existence of such a protocol is a complete +and utter misapprehension. +</para> +</note> + +<sect1> +<title>Features and Benefits</title> + +<para> +Many MS Windows network administrators have never been exposed to basic TCP/IP +networking as it is implemented in a UNIX/Linux operating system. Likewise, many UNIX and +Linux administrators have not been exposed to the intricacies of MS Windows TCP/IP-based +networking (and may have no desire to be, either). +</para> + +<para> +This chapter gives a short introduction to the basics of how a name can be resolved to +its IP address for each operating system environment. +</para> + +</sect1> + +<sect1> +<title>Background Information</title> + +<para> +<indexterm><primary>NetBIOS over TCP/IP</primary></indexterm> +<indexterm><primary>UDP port 137</primary></indexterm> +<indexterm><primary>TCP port 139</primary></indexterm> +<indexterm><primary>TCP port 445</primary></indexterm> +<indexterm><primary>UDP port 137</primary></indexterm> +Since the introduction of MS Windows 2000, it is possible to run MS Windows networking +without the use of NetBIOS over TCP/IP. NetBIOS over TCP/IP uses UDP port 137 for NetBIOS +name resolution and uses TCP port 139 for NetBIOS session services. When NetBIOS over +TCP/IP is disabled on MS Windows 2000 and later clients, then only the TCP port 445 is +used, and the UDP port 137 and TCP port 139 are not. +</para> + +<note> +<para> +When using Windows 2000 or later clients, if NetBIOS over TCP/IP is not disabled, then +the client will use UDP port 137 (NetBIOS Name Service, also known as the Windows Internet +Name Service, or WINS), TCP port 139, and TCP port 445 (for actual file and print traffic). +</para> +</note> + +<para> +<indexterm><primary>DNS</primary></indexterm> +<indexterm><primary>ADS</primary></indexterm> +<indexterm><primary>DDNS</primary></indexterm> +<indexterm><primary>SRV RR</primary></indexterm> +<indexterm><primary>IXFR</primary></indexterm> +<indexterm><primary>DHCP</primary></indexterm> +When NetBIOS over TCP/IP is disabled, the use of DNS is essential. Most installations that disable NetBIOS +over TCP/IP today use MS Active Directory Service (ADS). ADS requires +<indexterm><primary>DNS</primary><secondary>Dynamic</secondary></indexterm> dynamic DNS with Service Resource +Records (SRV RR) and with Incremental Zone Transfers (IXFR). <indexterm><primary>DHCP</primary></indexterm> +Use of DHCP with ADS is recommended as a further means of maintaining central control over the client +workstation network configuration. +</para> + +</sect1> + +<sect1> +<title>Name Resolution in a Pure UNIX/Linux World</title> + +<para> +The key configuration files covered in this section are: +</para> + +<indexterm><primary>/etc/hosts</primary></indexterm> +<indexterm><primary>/etc/resolv.conf</primary></indexterm> +<indexterm><primary>/etc/host.conf</primary></indexterm> +<indexterm><primary>/etc/nsswitch.conf</primary></indexterm> + +<itemizedlist> + <listitem><para><filename>/etc/hosts</filename></para></listitem> + <listitem><para><filename>/etc/resolv.conf</filename></para></listitem> + <listitem><para><filename>/etc/host.conf</filename></para></listitem> + <listitem><para><filename>/etc/nsswitch.conf</filename></para></listitem> +</itemizedlist> + +<sect2> +<title><filename>/etc/hosts</filename></title> + +<para> +This file contains a static list of IP addresses and names. +<programlisting> +127.0.0.1 localhost localhost.localdomain +192.168.1.1 bigbox.quenya.org bigbox alias4box +</programlisting> +</para> + +<para> +<indexterm><primary>/etc/hosts></primary></indexterm> +<indexterm><primary>name resolution</primary></indexterm> +The purpose of <filename>/etc/hosts</filename> is to provide a +name resolution mechanism so users do not need to remember +IP addresses. +</para> + +<para> +<indexterm><primary>IP addresses</primary></indexterm> +<indexterm><primary>MAC address</primary></indexterm> +<indexterm><primary>physical network transport layer</primary></indexterm> +Network packets that are sent over the physical network transport +layer communicate not via IP addresses but rather using the Media +Access Control address, or MAC address. IP addresses are currently +32 bits in length and are typically presented as four decimal +numbers that are separated by a dot (or period) &smbmdash; for example, 168.192.1.1. +</para> + +<para> +<indexterm><primary>MAC Addresses</primary></indexterm> +MAC addresses use 48 bits (or 6 bytes) and are typically represented +as two-digit hexadecimal numbers separated by colons: 40:8e:0a:12:34:56. +</para> + +<para> +Every network interface must have a MAC address. Associated with a MAC address may be one or more IP +addresses. There is no relationship between an IP address and a MAC address; all such assignments are +arbitrary or discretionary in nature. At the most basic level, all network communications take place using MAC +addressing. Since MAC addresses must be globally unique and generally remain fixed for any particular +interface, the assignment of an IP address makes sense from a network management perspective. More than one IP +address can be assigned per MAC address. One address must be the primary IP address &smbmdash; this is the +address that will be returned in the Address Resolution Protocol (ARP) reply. +</para> + +<para> +<indexterm><primary>machine name</primary></indexterm> +When a user or a process wants to communicate with another machine, +the protocol implementation ensures that the <quote>machine name</quote> or <quote>host +name</quote> is resolved to an IP address in a manner that is controlled +by the TCP/IP configuration control files. The file +<filename>/etc/hosts</filename> is one such file. +</para> + +<para> +<indexterm><primary>ARP/RARP</primary></indexterm> +When the IP address of the destination interface has been determined, a protocol called ARP/RARP is used to +identify the MAC address of the target interface. ARP is a broadcast-oriented method that uses User Datagram +Protocol (UDP) to send a request to all interfaces on the local network segment using the all 1s MAC address. +Network interfaces are programmed to respond to two MAC addresses only; their own unique address and the +address ff:ff:ff:ff:ff:ff. The reply packet from an ARP request will contain the MAC address and the primary +IP address for each interface. +</para> + +<para> +<indexterm><primary>/etc/hosts</primary></indexterm> +The <filename>/etc/hosts</filename> file is foundational to all +UNIX/Linux TCP/IP installations and as a minimum will contain +the localhost and local network interface IP addresses and the +primary names by which they are known within the local machine. +This file helps to prime the pump so a basic level of name +resolution can exist before any other method of name resolution +becomes available. +</para> + +</sect2> + + +<sect2> +<title><filename>/etc/resolv.conf</filename></title> + +<para> +This file tells the name resolution libraries: +</para> + +<itemizedlist> + <listitem><para>The name of the domain to which the machine + belongs. + </para></listitem> + + <listitem><para>The name(s) of any domains that should be + automatically searched when trying to resolve unqualified + host names to their IP address. + </para></listitem> + + <listitem><para>The name or IP address of available domain + name servers that may be asked to perform name-to-address + translation lookups. + </para></listitem> +</itemizedlist> + +</sect2> + + +<sect2> +<title><filename>/etc/host.conf</filename></title> + + +<para> +<indexterm><primary>/etc/host.conf</primary></indexterm> +<filename>/etc/host.conf</filename> is the primary means by which the setting in +<filename>/etc/resolv.conf</filename> may be effected. It is a critical configuration file. This file controls +the order by which name resolution may proceed. The typical structure is: +<programlisting> +order hosts,bind +multi on +</programlisting></para> + +<para>Both addresses should be returned. Please refer to the +man page for <filename>host.conf</filename> for further details. +</para> + +</sect2> + + +<sect2> +<title><filename>/etc/nsswitch.conf</filename></title> + +<para> +<indexterm><primary>/etc/nsswitch.conf</primary></indexterm> +This file controls the actual name resolution targets. The +file typically has resolver object specifications as follows: +<programlisting> +# /etc/nsswitch.conf +# +# Name Service Switch configuration file. +# + +passwd: compat +# Alternative entries for password authentication are: +# passwd: compat files nis ldap winbind +shadow: compat +group: compat + +hosts: files nis dns +# Alternative entries for host name resolution are: +# hosts: files dns nis nis+ hesiod db compat ldap wins +networks: nis files dns + +ethers: nis files +protocols: nis files +rpc: nis files +services: nis files +</programlisting></para> + +<para> +Of course, each of these mechanisms requires that the appropriate +facilities and/or services are correctly configured. +</para> + +<para> +It should be noted that unless a network request/message must be +sent, TCP/IP networks are silent. All TCP/IP communications assume a +principal of speaking only when necessary. +</para> + + +<para> +<indexterm><primary>libnss_wins.so</primary></indexterm> +<indexterm><primary>NetBIOS names</primary></indexterm> +<indexterm><primary>make</primary></indexterm> +<indexterm><primary>/etc/nsswitch.conf</primary></indexterm> +<indexterm><primary>wins</primary></indexterm> +Starting with version 2.2.0, Samba has Linux support for extensions to +the name service switch infrastructure so Linux clients will +be able to obtain resolution of MS Windows NetBIOS names to IP +addresses. To gain this functionality, Samba needs to be compiled +with appropriate arguments to the make command (i.e., <userinput>make +nsswitch/libnss_wins.so</userinput>). The resulting library should +then be installed in the <filename>/lib</filename> directory, and +the <parameter>wins</parameter> parameter needs to be added to the <quote>hosts:</quote> line in +the <filename>/etc/nsswitch.conf</filename> file. At this point, it +will be possible to ping any MS Windows machine by its NetBIOS +machine name, as long as that machine is within the workgroup to +which both the Samba machine and the MS Windows machine belong. +</para> + +</sect2> +</sect1> + + +<sect1> +<title>Name Resolution as Used within MS Windows Networking</title> + +<para> +<indexterm><primary>computer name</primary></indexterm> +<indexterm><primary>machine name</primary></indexterm> +<indexterm><primary>NetBIOS name</primary></indexterm> +<indexterm><primary>SMB name</primary></indexterm> +MS Windows networking is predicated on the name each machine is given. This name is known variously (and +inconsistently) as the <quote>computer name,</quote> <quote>machine name,</quote> <quote>networking +name,</quote> <quote>NetBIOS name,</quote> or <quote>SMB name.</quote> All terms mean the same thing with the +exception of <quote>NetBIOS name,</quote> which can also apply to the name of the workgroup or the domain +name. The terms <quote>workgroup</quote> and <quote>domain</quote> are really just a simple name with which +the machine is associated. All NetBIOS names are exactly 16 characters in length. The +16<superscript>th</superscript> character is reserved. It is used to store a 1-byte value that indicates +service level information for the NetBIOS name that is registered. A NetBIOS machine name is therefore +registered for each service type that is provided by the client/server. +</para> + +<para> +<link linkend="uniqnetbiosnames">Unique NetBIOS names</link> and <link linkend="netbiosnamesgrp">group names</link> tables +list typical NetBIOS name/service type registrations. +</para> + +<table frame="all" id="uniqnetbiosnames"> +<title>Unique NetBIOS Names</title> +<tgroup cols="2"> +<colspec align="left"/> +<colspec align="justify"/> +<tbody> +<row><entry>MACHINENAME<00></entry><entry>Server Service is running on MACHINENAME</entry></row> +<row><entry>MACHINENAME<03></entry><entry>Generic machine name (NetBIOS name)</entry></row> +<row><entry>MACHINENAME<20></entry><entry>LanMan server service is running on MACHINENAME</entry></row> +<row><entry>WORKGROUP<1b></entry><entry>Domain master browser</entry></row> +</tbody> +</tgroup> +</table> + +<table frame="all" id="netbiosnamesgrp"> +<title>Group Names</title> +<tgroup cols="2"> +<colspec align="left"/> +<colspec align="justify"/> +<tbody> +<row><entry>WORKGROUP<03></entry><entry>Generic name registered by all members of WORKGROUP</entry></row> +<row><entry>WORKGROUP<1c></entry><entry>Domain cntrollers/netlogon servers</entry></row> +<row><entry>WORKGROUP<1d></entry><entry>Local master browsers</entry></row> +<row><entry>WORKGROUP<1e></entry><entry>Browser election service</entry></row> +</tbody> +</tgroup> +</table> + +<para> +<indexterm><primary>NetBIOS</primary></indexterm> +It should be noted that all NetBIOS machines register their own +names as per <link linkend="uniqnetbiosnames">Unique NetBIOS names</link> and <link +linkend="netbiosnamesgrp">group names</link>. This is in vast contrast to TCP/IP +installations where the system administrator traditionally +determines in the <filename>/etc/hosts</filename> or in the DNS database what names +are associated with each IP address. +</para> + +<para> +<indexterm><primary>NetBIOS</primary></indexterm> +<indexterm><primary>/etc/hosts</primary></indexterm> +<indexterm><primary>NetBIOS name</primary></indexterm> +One further point of clarification should be noted. The <filename>/etc/hosts</filename> +file and the DNS records do not provide the NetBIOS name information +that MS Windows clients depend on to locate the type of service that may +be needed. An example of this is what happens when an MS Windows client +wants to locate a domain logon server. It finds this service and the IP +address of a server that provides it by performing a lookup (via a +NetBIOS broadcast) for enumeration of all machines that have +registered the name type *<1C>. A logon request is then sent to each +IP address that is returned in the enumerated list of IP addresses. +Whichever machine first replies, it then ends up providing the logon services. +</para> + +<para> +<indexterm><primary>domain</primary></indexterm> +<indexterm><primary>workgroup</primary></indexterm> +The name <quote>workgroup</quote> or <quote>domain</quote> really can be confusing, since these +have the added significance of indicating what is the security +architecture of the MS Windows network. The term <quote>workgroup</quote> indicates +that the primary nature of the network environment is that of a +peer-to-peer design. In a workgroup, all machines are responsible for +their own security, and generally such security is limited to the use of +just a password (known as share-level security). In most situations +with peer-to-peer networking, the users who control their own machines +will simply opt to have no security at all. It is possible to have +user-level security in a workgroup environment, thus requiring the use +of a username and a matching password. +</para> + +<para> +<indexterm><primary>SMB</primary></indexterm> +<indexterm><primary>Network Basic Input/Output System</primary><see>NetBIOS</see></indexterm> +<indexterm><primary>Logical Link Control</primary><see>LLC</see></indexterm> +<indexterm><primary>Network Basic Extended User Interface</primary><see>NetBEUI</see></indexterm> +<indexterm><primary>Internetworking Packet Exchange</primary><see>IPX</see></indexterm> +<indexterm><primary>NetWare</primary></indexterm> +<indexterm><primary>NetBT</primary></indexterm> +<indexterm><primary>NBT</primary></indexterm> +MS Windows networking is thus predetermined to use machine names +for all local and remote machine message passing. The protocol used is +called Server Message Block (SMB), and this is implemented using +the NetBIOS protocol (Network Basic Input/Output System). NetBIOS can +be encapsulated using LLC (Logical Link Control) protocol &smbmdash; in which case +the resulting protocol is called NetBEUI (Network Basic Extended User +Interface). NetBIOS can also be run over IPX (Internetworking Packet +Exchange) protocol as used by Novell NetWare, and it can be run +over TCP/IP protocols &smbmdash; in which case the resulting protocol is called +NBT or NetBT, the NetBIOS over TCP/IP. +</para> + +<para> +MS Windows machines use a complex array of name resolution mechanisms. +Since we are primarily concerned with TCP/IP, this demonstration is +limited to this area. +</para> + +<sect2> +<title>The NetBIOS Name Cache</title> + +<para> +<indexterm><primary>n-memory buffer</primary></indexterm> +<indexterm><primary>local cache</primary></indexterm> +<indexterm><primary></primary></indexterm> +All MS Windows machines employ an in-memory buffer in which is +stored the NetBIOS names and IP addresses for all external +machines that machine has communicated with over the +past 10 to 15 minutes. It is more efficient to obtain an IP address +for a machine from the local cache than it is to go through all the +configured name resolution mechanisms. +</para> + +<para> +<indexterm><primary>name lookup</primary></indexterm> +If a machine whose name is in the local name cache is shut +down before the name is expired and flushed from the cache, then +an attempt to exchange a message with that machine will be subject +to timeout delays. Its name is in the cache, so a name resolution +lookup will succeed, but the machine cannot respond. This can be +frustrating for users but is a characteristic of the protocol. +</para> + +<para> +<indexterm><primary>nbtstat</primary></indexterm> +<indexterm><primary>nmblookup</primary></indexterm> +<indexterm><primary>NetBIOS</primary></indexterm> +The MS Windows utility that allows examination of the NetBIOS +name cache is called <quote>nbtstat.</quote> The Samba equivalent +is called <command>nmblookup</command>. +</para> + +</sect2> + +<sect2> +<title>The LMHOSTS File</title> + +<para> +<indexterm><primary>LMHOSTS</primary></indexterm> +This file is usually located in MS Windows NT 4.0 or Windows 200x/XP in the directory +<filename>%SystemRoot%\SYSTEM32\DRIVERS\ETC</filename> and contains the IP address +and the machine name in matched pairs. The <filename>LMHOSTS</filename> file +performs NetBIOS name to IP address mapping. +</para> + +<para> +It typically looks like this: +</para> + +<para><programlisting> +# Copyright (c) 1998 Microsoft Corp. +# +# This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS +# over TCP/IP) stack for Windows98 +# +# This file contains the mappings of IP addresses to NT computer names +# (NetBIOS) names. Each entry should be kept on an individual line. +# The IP address should be placed in the first column followed by the +# corresponding computer name. The address and the computer name +# should be separated by at least one space or tab. The "#" character +# is generally used to denote the start of a comment (see the exceptions +# below). +# +# This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts +# files and offers the following extensions: +# +# #PRE +# #DOM:<domain> +# #INCLUDE <filename> +# #BEGIN_ALTERNATE +# #END_ALTERNATE +# \0xnn (non-printing character support) +# +# Following any entry in the file with the characters "#PRE" will cause +# the entry to be preloaded into the name cache. By default, entries are +# not preloaded, but are parsed only after dynamic name resolution fails. +# +# Following an entry with the "#DOM:<domain>" tag will associate the +# entry with the domain specified by <domain>. This effects how the +# browser and logon services behave in TCP/IP environments. To preload +# the host name associated with #DOM entry, it is necessary to also add a +# #PRE to the line. The <domain> is always pre-loaded although it will not +# be shown when the name cache is viewed. +# +# Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT) +# software to seek the specified <filename> and parse it as if it were +# local. <filename> is generally a UNC-based name, allowing a +# centralized lmhosts file to be maintained on a server. +# It is ALWAYS necessary to provide a mapping for the IP address of the +# server prior to the #INCLUDE. This mapping must use the #PRE directive. +# In addition the share "public" in the example below must be in the +# LanMan Server list of "NullSessionShares" in order for client machines to +# be able to read the lmhosts file successfully. This key is under +# \machine\system\currentcontrolset\services\lanmanserver\ +# parameters\nullsessionshares +# in the registry. Simply add "public" to the list found there. +# +# The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE +# statements to be grouped together. Any single successful include +# will cause the group to succeed. +# +# Finally, non-printing characters can be embedded in mappings by +# first surrounding the NetBIOS name in quotations, then using the +# \0xnn notation to specify a hex value for a non-printing character. +# +# The following example illustrates all of these extensions: +# +# 102.54.94.97 rhino #PRE #DOM:networking #net group's DC +# 102.54.94.102 "appname \0x14" #special app server +# 102.54.94.123 popular #PRE #source server +# 102.54.94.117 localsrv #PRE #needed for the include +# +# #BEGIN_ALTERNATE +# #INCLUDE \\localsrv\public\lmhosts +# #INCLUDE \\rhino\public\lmhosts +# #END_ALTERNATE +# +# In the above example, the "appname" server contains a special +# character in its name, the "popular" and "localsrv" server names are +# pre-loaded, and the "rhino" server name is specified so it can be used +# to later #INCLUDE a centrally maintained lmhosts file if the "localsrv" +# system is unavailable. +# +# Note that the whole file is parsed including comments on each lookup, +# so keeping the number of comments to a minimum will improve performance. +# Therefore it is not advisable to simply add lmhosts file entries onto the +# end of this file. +</programlisting></para> + +</sect2> + +<sect2> +<title>HOSTS File</title> + +<para> +This file is usually located in MS Windows NT 4.0 or Windows 200x/XP in +the directory <filename>%SystemRoot%\SYSTEM32\DRIVERS\ETC</filename> and contains +the IP address and the IP hostname in matched pairs. It can be +used by the name resolution infrastructure in MS Windows, depending +on how the TCP/IP environment is configured. This file is in +every way the equivalent of the UNIX/Linux <filename>/etc/hosts</filename> file. +</para> +</sect2> + + +<sect2> +<title>DNS Lookup</title> + + +<para> +<indexterm><primary>DNS</primary></indexterm> +This capability is configured in the TCP/IP setup area in the network +configuration facility. If enabled, an elaborate name resolution sequence +is followed, the precise nature of which is dependent on how the NetBIOS +Node Type parameter is configured. A Node Type of 0 means that +NetBIOS broadcast (over UDP broadcast) is used if the name +that is the subject of a name lookup is not found in the NetBIOS name +cache. If that fails, then DNS, HOSTS, and LMHOSTS are checked. If set to +Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the +WINS server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast +lookup is used. +</para> + +</sect2> + +<sect2> +<title>WINS Lookup</title> + + +<para> +<indexterm><primary>WINS</primary></indexterm> +<indexterm><primary>Windows Internet Name Server</primary><see>WINS</see></indexterm> +<indexterm><primary>NetBIOS Name Server</primary><see>NBNS</see></indexterm> +A WINS (Windows Internet Name Server) service is the equivalent of the +rfc1001/1002 specified NBNS (NetBIOS Name Server). A WINS server stores +the names and IP addresses that are registered by a Windows client +if the TCP/IP setup has been given at least one WINS server IP address. +</para> + +<para> +To configure Samba to be a WINS server, the following parameter needs +to be added to the &smb.conf; file: +</para> + +<para><smbconfblock> +<smbconfoption name="wins support">Yes</smbconfoption> +</smbconfblock></para> + +<para> +<indexterm><primary>WINS</primary></indexterm> +To configure Samba to use a WINS server, the following parameters are +needed in the &smb.conf; file: +</para> + +<para><smbconfblock> +<smbconfoption name="wins support">No</smbconfoption> +<smbconfoption name="wins server">xxx.xxx.xxx.xxx</smbconfoption> +</smbconfblock></para> + +<para> +where <replaceable>xxx.xxx.xxx.xxx</replaceable> is the IP address +of the WINS server. +</para> + +<para>For information about setting up Samba as a WINS server, read +<link linkend="NetworkBrowsing">Network Browsing</link>.</para> + +</sect2> +</sect1> + +<sect1> +<title>Common Errors</title> + +<para> +TCP/IP network configuration problems find every network administrator sooner or later. +The cause can be anything from keyboard mishaps to forgetfulness to simple mistakes to +carelessness. Of course, no one is ever deliberately careless! +</para> + + <sect2> + <title>Pinging Works Only One Way</title> + + <para> + <quote>I can ping my Samba server from Windows, but I cannot ping my Windows + machine from the Samba server.</quote> + </para> + + <para> + The Windows machine was at IP address 192.168.1.2 with netmask 255.255.255.0, the + Samba server (Linux) was at IP address 192.168.1.130 with netmask 255.255.255.128. + The machines were on a local network with no external connections. + </para> + + <para> + Due to inconsistent netmasks, the Windows machine was on network 192.168.1.0/24, while + the Samba server was on network 192.168.1.128/25 &smbmdash; logically a different network. + </para> + + </sect2> + + <sect2> + <title>Very Slow Network Connections</title> + + <para> + A common cause of slow network response includes: + </para> + + <itemizedlist> + <listitem><para>Client is configured to use DNS and the DNS server is down.</para></listitem> + <listitem><para>Client is configured to use remote DNS server, but the + remote connection is down.</para></listitem> + <listitem><para>Client is configured to use a WINS server, but there is no WINS server.</para></listitem> + <listitem><para>Client is not configured to use a WINS server, but there is a WINS server.</para></listitem> + <listitem><para>Firewall is filtering out DNS or WINS traffic.</para></listitem> + </itemizedlist> + + </sect2> + + <sect2> + <title>Samba Server Name-Change Problem</title> + + <para> + <quote>The name of the Samba server was changed, Samba was restarted, and now the Samba server cannot be + pinged by its new name from an MS Windows NT4 workstation, but it does still respond to pinging using + the old name. Why?</quote> + </para> + + <para> + From this description, three things are obvious: + </para> + + <itemizedlist> + <listitem><para>WINS is not in use; only broadcast-based name resolution is used.</para></listitem> + <listitem><para>The Samba server was renamed and restarted within the last 10 or 15 minutes.</para></listitem> + <listitem><para>The old Samba server name is still in the NetBIOS name cache on the MS Windows NT4 workstation.</para></listitem> + </itemizedlist> + + <para> + To find what names are present in the NetBIOS name cache on the MS Windows NT4 machine, + open a <command>cmd</command> shell and then: + </para> + + <para> +<screen> +&dosprompt;<userinput>nbtstat -n</userinput> + + NetBIOS Local Name Table + + Name Type Status +------------------------------------------------ +&example.workstation.windows; <03> UNIQUE Registered +ADMINISTRATOR <03> UNIQUE Registered +&example.workstation.windows; <00> UNIQUE Registered +SARDON <00> GROUP Registered +&example.workstation.windows; <20> UNIQUE Registered +&example.workstation.windows; <1F> UNIQUE Registered + + +&dosprompt;nbtstat -c + + NetBIOS Remote Cache Name Table + + Name Type Host Address Life [sec] +-------------------------------------------------------------- +&example.server.samba; <20> UNIQUE 192.168.1.1 240 + +&dosprompt; +</screen> + </para> + + <para> + In this example, &example.server.samba; is the Samba server and &example.workstation.windows; is the MS Windows NT4 workstation. + The first listing shows the contents of the Local Name Table (i.e., identity information on + the MS Windows workstation), and the second shows the NetBIOS name in the NetBIOS name cache. + The name cache contains the remote machines known to this workstation. + </para> + + </sect2> + +</sect1> + +</chapter> |