tevent: add test_event_fd1()
[Samba/gebeck_regimport.git] / docs-xml / Samba3-HOWTO / TOSHARG-Integrating-with-Windows.xml
blob68b9d49b69bc6f3f52002e43e05be18ecb797740
1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
3 <chapter id="integrate-ms-networks">
4  
5 <chapterinfo>
6         &author.jht;
7         <pubdate> (Jan 01 2001) </pubdate>
8 </chapterinfo>
9  
10 <title>Integrating MS Windows Networks with Samba</title>
12 <para>
13 <indexterm><primary>NetBIOS</primary></indexterm>
14 This chapter deals with NetBIOS over TCP/IP name to IP address resolution. If
15 your MS Windows clients are not configured to use NetBIOS over TCP/IP, then this
16 section does not apply to your installation. If your installation involves the use of
17 NetBIOS over TCP/IP, then this chapter may help you to resolve networking problems.
18 </para>
20 <note>
21 <para>
22 <indexterm><primary>NetBEUI</primary></indexterm>
23 <indexterm><primary>LLC</primary></indexterm>
24 NetBIOS over TCP/IP has nothing to do with NetBEUI. NetBEUI is NetBIOS
25 over Logical Link Control (LLC). On modern networks it is highly advised
26 to not run NetBEUI at all. Note also that there is no such thing as
27 NetBEUI over TCP/IP &smbmdash; the existence of such a protocol is a complete
28 and utter misapprehension.
29 </para>
30 </note>
32 <sect1>
33 <title>Features and Benefits</title>
35 <para>
36 Many MS Windows network administrators have never been exposed to basic TCP/IP
37 networking as it is implemented in a UNIX/Linux operating system. Likewise, many UNIX and
38 Linux administrators have not been exposed to the intricacies of MS Windows TCP/IP-based
39 networking (and may have no desire to be, either).
40 </para>
42 <para>
43 This chapter gives a short introduction to the basics of how a name can be resolved to 
44 its IP address for each operating system environment.
45 </para>
47 </sect1>
49 <sect1>
50 <title>Background Information</title>
52 <para>
53 <indexterm><primary>NetBIOS over TCP/IP</primary></indexterm>
54 <indexterm><primary>UDP port 137</primary></indexterm>
55 <indexterm><primary>TCP port 139</primary></indexterm>
56 <indexterm><primary>TCP port 445</primary></indexterm>
57 <indexterm><primary>UDP port 137</primary></indexterm>
58 Since the introduction of MS Windows 2000, it is possible to run MS Windows networking
59 without the use of NetBIOS over TCP/IP. NetBIOS over TCP/IP uses UDP port 137 for NetBIOS
60 name resolution and uses TCP port 139 for NetBIOS session services. When NetBIOS over
61 TCP/IP is disabled on MS Windows 2000 and later clients, then only the TCP port 445 is
62 used, and the UDP port 137 and TCP port 139 are not.
63 </para>
65 <note>
66 <para>
67 When using Windows 2000 or later clients, if NetBIOS over TCP/IP is not disabled, then
68 the client will use UDP port 137 (NetBIOS Name Service, also known as the Windows Internet
69 Name Service, or WINS), TCP port 139, and TCP port 445 (for actual file and print traffic).
70 </para>
71 </note>
73 <para>
74 <indexterm><primary>DNS</primary></indexterm>
75 <indexterm><primary>ADS</primary></indexterm>
76 <indexterm><primary>DDNS</primary></indexterm>
77 <indexterm><primary>SRV RR</primary></indexterm>
78 <indexterm><primary>IXFR</primary></indexterm>
79 <indexterm><primary>DHCP</primary></indexterm>
80 When NetBIOS over TCP/IP is disabled, the use of DNS is essential. Most installations that disable NetBIOS
81 over TCP/IP today use MS Active Directory Service (ADS). ADS requires
82 <indexterm><primary>DNS</primary><secondary>Dynamic</secondary></indexterm> dynamic DNS with Service Resource
83 Records (SRV RR) and with Incremental Zone Transfers (IXFR).  <indexterm><primary>DHCP</primary></indexterm>
84 Use of DHCP with ADS is recommended as a further means of maintaining central control over the client
85 workstation network configuration.
86 </para>
88 </sect1>
90 <sect1>
91 <title>Name Resolution in a Pure UNIX/Linux World</title>
93 <para>
94 The key configuration files covered in this section are:
95 </para>
97 <indexterm><primary>/etc/hosts</primary></indexterm>
98 <indexterm><primary>/etc/resolv.conf</primary></indexterm>
99 <indexterm><primary>/etc/host.conf</primary></indexterm>
100 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
102 <itemizedlist>
103         <listitem><para><filename>/etc/hosts</filename></para></listitem>
104         <listitem><para><filename>/etc/resolv.conf</filename></para></listitem>
105         <listitem><para><filename>/etc/host.conf</filename></para></listitem>
106         <listitem><para><filename>/etc/nsswitch.conf</filename></para></listitem>
107 </itemizedlist>
109 <sect2>
110 <title><filename>/etc/hosts</filename></title>
112 <para>
113 This file contains a static list of IP addresses and names.
114 <programlisting>
115 127.0.0.1       localhost localhost.localdomain
116 192.168.1.1     bigbox.quenya.org       bigbox  alias4box
117 </programlisting>
118 </para>
120 <para>
121 <indexterm><primary>/etc/hosts></primary></indexterm>
122 <indexterm><primary>name resolution</primary></indexterm>
123 The purpose of <filename>/etc/hosts</filename> is to provide a 
124 name resolution mechanism so users do not need to remember 
125 IP addresses.
126 </para>
128 <para>
129 <indexterm><primary>IP addresses</primary></indexterm>
130 <indexterm><primary>MAC address</primary></indexterm>
131 <indexterm><primary>physical network transport layer</primary></indexterm>
132 Network packets that are sent over the physical network transport 
133 layer communicate not via IP addresses but rather using the Media 
134 Access Control address, or MAC address. IP addresses are currently 
135 32 bits in length and are typically presented as four decimal 
136 numbers that are separated by a dot (or period) &smbmdash; for example, 168.192.1.1.
137 </para>
139 <para>
140 <indexterm><primary>MAC Addresses</primary></indexterm>
141 MAC addresses use 48 bits (or 6 bytes) and are typically represented 
142 as two-digit hexadecimal numbers separated by colons: 40:8e:0a:12:34:56.
143 </para>
145 <para>
146 Every network interface must have a MAC address. Associated with a MAC address may be one or more IP
147 addresses. There is no relationship between an IP address and a MAC address; all such assignments are
148 arbitrary or discretionary in nature. At the most basic level, all network communications take place using MAC
149 addressing. Since MAC addresses must be globally unique and generally remain fixed for any particular
150 interface, the assignment of an IP address makes sense from a network management perspective. More than one IP
151 address can be assigned per MAC address. One address must be the primary IP address &smbmdash; this is the
152 address that will be returned in the Address Resolution Protocol (ARP) reply.
153 </para>
155 <para>
156 <indexterm><primary>machine name</primary></indexterm>
157 When a user or a process wants to communicate with another machine, 
158 the protocol implementation ensures that the <quote>machine name</quote> or <quote>host 
159 name</quote> is resolved to an IP address in a manner that is controlled 
160 by the TCP/IP configuration control files. The file 
161 <filename>/etc/hosts</filename> is one such file.
162 </para>
164 <para>
165 <indexterm><primary>ARP/RARP</primary></indexterm>
166 When the IP address of the destination interface has been determined, a protocol called ARP/RARP is used to
167 identify the MAC address of the target interface. ARP is a broadcast-oriented method that uses User Datagram
168 Protocol (UDP) to send a request to all interfaces on the local network segment using the all 1s MAC address.
169 Network interfaces are programmed to respond to two MAC addresses only; their own unique address and the
170 address ff:ff:ff:ff:ff:ff. The reply packet from an ARP request will contain the MAC address and the primary
171 IP address for each interface.
172 </para>
174 <para>
175 <indexterm><primary>/etc/hosts</primary></indexterm>
176 The <filename>/etc/hosts</filename> file is foundational to all 
177 UNIX/Linux TCP/IP installations and as a minimum will contain 
178 the localhost and local network interface IP addresses and the 
179 primary names by which they are known within the local machine. 
180 This file helps to prime the pump so a basic level of name 
181 resolution can exist before any other method of name resolution 
182 becomes available.
183 </para>
185 </sect2>
188 <sect2>
189 <title><filename>/etc/resolv.conf</filename></title>
191 <para>
192 This file tells the name resolution libraries:
193 </para>
195 <itemizedlist>
196         <listitem><para>The name of the domain to which the machine 
197         belongs.
198         </para></listitem>
199         
200         <listitem><para>The name(s) of any domains that should be 
201         automatically searched when trying to resolve unqualified 
202         host names to their IP address.
203         </para></listitem>
204         
205         <listitem><para>The name or IP address of available domain 
206         name servers that may be asked to perform name-to-address 
207         translation lookups.
208         </para></listitem>
209 </itemizedlist>
211 </sect2>
214 <sect2>
215 <title><filename>/etc/host.conf</filename></title>
218 <para>
219 <indexterm><primary>/etc/host.conf</primary></indexterm>
220 <filename>/etc/host.conf</filename> is the primary means by which the setting in
221 <filename>/etc/resolv.conf</filename> may be effected. It is a critical configuration file. This file controls
222 the order by which name resolution may proceed. The typical structure is:
223 <programlisting>
224 order hosts,bind
225 multi on
226 </programlisting></para>
228 <para>Both addresses should be returned. Please refer to the 
229 man page for <filename>host.conf</filename> for further details.
230 </para>
232 </sect2>
235 <sect2>
236 <title><filename>/etc/nsswitch.conf</filename></title>
238 <para>
239 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
240 This file controls the actual name resolution targets. The 
241 file typically has resolver object specifications as follows:
242 <programlisting>
243 # /etc/nsswitch.conf
245 # Name Service Switch configuration file.
248 passwd:         compat
249 # Alternative entries for password authentication are:
250 # passwd:       compat files nis ldap winbind
251 shadow:         compat
252 group:          compat
254 hosts:          files nis dns
255 # Alternative entries for host name resolution are:
256 # hosts:        files dns nis nis+ hesiod db compat ldap wins
257 networks:       nis files dns
259 ethers:         nis files
260 protocols:      nis files
261 rpc:            nis files
262 services:       nis files
263 </programlisting></para>
265 <para>
266 Of course, each of these mechanisms requires that the appropriate 
267 facilities and/or services are correctly configured.
268 </para>
270 <para>
271 It should be noted that unless a network request/message must be 
272 sent, TCP/IP networks are silent. All TCP/IP communications assume a 
273 principal of speaking only when necessary.
274 </para>
277 <para>
278 <indexterm><primary>libnss_wins.so</primary></indexterm>
279 <indexterm><primary>NetBIOS names</primary></indexterm>
280 <indexterm><primary>make</primary></indexterm>
281 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
282 <indexterm><primary>wins</primary></indexterm>
283 Starting with version 2.2.0, Samba has Linux support for extensions to 
284 the name service switch infrastructure so Linux clients will 
285 be able to obtain resolution of MS Windows NetBIOS names to IP 
286 addresses. To gain this functionality, Samba needs to be compiled 
287 with appropriate arguments to the make command (i.e., <userinput>make 
288 nsswitch/libnss_wins.so</userinput>). The resulting library should 
289 then be installed in the <filename>/lib</filename> directory, and 
290 the <parameter>wins</parameter> parameter needs to be added to the <quote>hosts:</quote> line in 
291 the <filename>/etc/nsswitch.conf</filename> file. At this point, it 
292 will be possible to ping any MS Windows machine by its NetBIOS 
293 machine name, as long as that machine is within the workgroup to 
294 which both the Samba machine and the MS Windows machine belong.
295 </para>
297 </sect2>
298 </sect1>
301 <sect1>
302 <title>Name Resolution as Used within MS Windows Networking</title>
304 <para>
305 <indexterm><primary>computer name</primary></indexterm>
306 <indexterm><primary>machine name</primary></indexterm>
307 <indexterm><primary>NetBIOS name</primary></indexterm>
308 <indexterm><primary>SMB name</primary></indexterm>
309 MS Windows networking is predicated on the name each machine is given. This name is known variously (and
310 inconsistently) as the <quote>computer name,</quote> <quote>machine name,</quote> <quote>networking
311 name,</quote> <quote>NetBIOS name,</quote> or <quote>SMB name.</quote> All terms mean the same thing with the
312 exception of <quote>NetBIOS name,</quote> which can also apply to the name of the workgroup or the domain
313 name. The terms <quote>workgroup</quote> and <quote>domain</quote> are really just a simple name with which
314 the machine is associated. All NetBIOS names are exactly 16 characters in length. The
315 16<superscript>th</superscript> character is reserved.  It is used to store a 1-byte value that indicates
316 service level information for the NetBIOS name that is registered. A NetBIOS machine name is therefore
317 registered for each service type that is provided by the client/server.
318 </para>
320 <para>
321 <link linkend="uniqnetbiosnames">Unique NetBIOS names</link> and <link linkend="netbiosnamesgrp">group names</link> tables 
322 list typical NetBIOS name/service type registrations.
323 </para>
325 <table frame="all" id="uniqnetbiosnames">
326 <title>Unique NetBIOS Names</title>
327 <tgroup cols="2">
328 <colspec align="left"/>
329 <colspec align="justify"/>
330 <tbody>
331 <row><entry>MACHINENAME&lt;00&gt;</entry><entry>Server Service is running on MACHINENAME</entry></row>
332 <row><entry>MACHINENAME&lt;03&gt;</entry><entry>Generic machine name (NetBIOS name)</entry></row>
333 <row><entry>MACHINENAME&lt;20&gt;</entry><entry>LanMan server service is running on MACHINENAME</entry></row>
334 <row><entry>WORKGROUP&lt;1b&gt;</entry><entry>Domain master browser</entry></row>
335 </tbody>
336 </tgroup>
337 </table>
339 <table frame="all" id="netbiosnamesgrp">
340 <title>Group Names</title>
341 <tgroup cols="2">
342 <colspec align="left"/>
343 <colspec align="justify"/>
344 <tbody>
345 <row><entry>WORKGROUP&lt;03&gt;</entry><entry>Generic name registered by all members of WORKGROUP</entry></row>
346 <row><entry>WORKGROUP&lt;1c&gt;</entry><entry>Domain cntrollers/netlogon servers</entry></row>
347 <row><entry>WORKGROUP&lt;1d&gt;</entry><entry>Local master browsers</entry></row>
348 <row><entry>WORKGROUP&lt;1e&gt;</entry><entry>Browser election service</entry></row>
349 </tbody>
350 </tgroup>
351 </table>
353 <para>
354 <indexterm><primary>NetBIOS</primary></indexterm>
355 It should be noted that all NetBIOS machines register their own 
356 names as per <link linkend="uniqnetbiosnames">Unique NetBIOS names</link> and <link
357 linkend="netbiosnamesgrp">group names</link>. This is in vast contrast to TCP/IP 
358 installations where the system administrator traditionally 
359 determines in the <filename>/etc/hosts</filename> or in the DNS database what names 
360 are associated with each IP address.
361 </para>
363 <para>
364 <indexterm><primary>NetBIOS</primary></indexterm>
365 <indexterm><primary>/etc/hosts</primary></indexterm>
366 <indexterm><primary>NetBIOS name</primary></indexterm>
367 One further point of clarification should be noted. The <filename>/etc/hosts</filename> 
368 file and the DNS records do not provide the NetBIOS name information 
369 that MS Windows clients depend on to locate the type of service that may 
370 be needed. An example of this is what happens when an MS Windows client 
371 wants to locate a domain logon server. It finds this service and the IP 
372 address of a server that provides it by performing a lookup (via a 
373 NetBIOS broadcast) for enumeration of all machines that have 
374 registered the name type *&lt;1C&gt;. A logon request is then sent to each 
375 IP address that is returned in the enumerated list of IP addresses.
376 Whichever machine first replies, it then ends up providing the logon services.
377 </para>
379 <para>
380 <indexterm><primary>domain</primary></indexterm>
381 <indexterm><primary>workgroup</primary></indexterm>
382 The name <quote>workgroup</quote> or <quote>domain</quote> really can be confusing, since these 
383 have the added significance of indicating what is the security 
384 architecture of the MS Windows network. The term <quote>workgroup</quote> indicates 
385 that the primary nature of the network environment is that of a 
386 peer-to-peer design. In a workgroup, all machines are responsible for 
387 their own security, and generally such security is limited to the use of 
388 just a password (known as share-level security). In most situations 
389 with peer-to-peer networking, the users who control their own machines 
390 will simply opt to have no security at all. It is possible to have 
391 user-level security in a workgroup environment, thus requiring the use 
392 of a username and a matching password.
393 </para>
395 <para>
396 <indexterm><primary>SMB</primary></indexterm>
397 <indexterm><primary>Network Basic Input/Output System</primary><see>NetBIOS</see></indexterm>
398 <indexterm><primary>Logical Link Control</primary><see>LLC</see></indexterm>
399 <indexterm><primary>Network Basic Extended User Interface</primary><see>NetBEUI</see></indexterm>
400 <indexterm><primary>Internetworking Packet Exchange</primary><see>IPX</see></indexterm>
401 <indexterm><primary>NetWare</primary></indexterm>
402 <indexterm><primary>NetBT</primary></indexterm>
403 <indexterm><primary>NBT</primary></indexterm>
404 MS Windows networking is thus predetermined to use machine names 
405 for all local and remote machine message passing. The protocol used is 
406 called Server Message Block (SMB), and this is implemented using 
407 the NetBIOS protocol (Network Basic Input/Output System). NetBIOS can 
408 be encapsulated using LLC (Logical Link Control) protocol &smbmdash; in which case 
409 the resulting protocol is called NetBEUI (Network Basic Extended User 
410 Interface). NetBIOS can also be run over IPX (Internetworking Packet 
411 Exchange) protocol as used by Novell NetWare, and it can be run 
412 over TCP/IP protocols &smbmdash; in which case the resulting protocol is called 
413 NBT or NetBT, the NetBIOS over TCP/IP.
414 </para>
416 <para>
417 MS Windows machines use a complex array of name resolution mechanisms. 
418 Since we are primarily concerned with TCP/IP, this demonstration is 
419 limited to this area.
420 </para>
422 <sect2>
423 <title>The NetBIOS Name Cache</title>
425 <para>
426 <indexterm><primary>n-memory buffer</primary></indexterm>
427 <indexterm><primary>local cache</primary></indexterm>
428 <indexterm><primary></primary></indexterm>
429 All MS Windows machines employ an in-memory buffer in which is 
430 stored the NetBIOS names and IP addresses for all external 
431 machines that machine has communicated with over the 
432 past 10 to 15 minutes. It is more efficient to obtain an IP address 
433 for a machine from the local cache than it is to go through all the 
434 configured name resolution mechanisms.
435 </para>
437 <para>
438 <indexterm><primary>name lookup</primary></indexterm>
439 If a machine whose name is in the local name cache is shut 
440 down before the name is expired and flushed from the cache, then 
441 an attempt to exchange a message with that machine will be subject 
442 to timeout delays. Its name is in the cache, so a name resolution 
443 lookup will succeed, but the machine cannot respond. This can be 
444 frustrating for users but is a characteristic of the protocol.
445 </para>
447 <para>
448 <indexterm><primary>nbtstat</primary></indexterm>
449 <indexterm><primary>nmblookup</primary></indexterm>
450 <indexterm><primary>NetBIOS</primary></indexterm>
451 The MS Windows utility that allows examination of the NetBIOS 
452 name cache is called <quote>nbtstat.</quote> The Samba equivalent
453 is called <command>nmblookup</command>.
454 </para>
456 </sect2>
458 <sect2>
459 <title>The LMHOSTS File</title>
461 <para>
462 <indexterm><primary>LMHOSTS</primary></indexterm>
463 This file is usually located in MS Windows NT 4.0 or Windows 200x/XP in the directory
464 <filename>%SystemRoot%\SYSTEM32\DRIVERS\ETC</filename> and contains the IP address
465 and the machine name in matched pairs. The <filename>LMHOSTS</filename> file
466 performs NetBIOS name to IP address mapping.
467 </para>
469 <para>
470 It typically looks like this:
471 </para>
473 <para><programlisting>
474 # Copyright (c) 1998 Microsoft Corp.
476 # This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS
477 # over TCP/IP) stack for Windows98
479 # This file contains the mappings of IP addresses to NT computer names
480 # (NetBIOS) names. Each entry should be kept on an individual line.
481 # The IP address should be placed in the first column followed by the
482 # corresponding computer name. The address and the computer name
483 # should be separated by at least one space or tab. The "#" character
484 # is generally used to denote the start of a comment (see the exceptions
485 # below).
487 # This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
488 # files and offers the following extensions:
490 #      #PRE
491 #      #DOM:&lt;domain&gt;
492 #      #INCLUDE &lt;filename&gt;
493 #      #BEGIN_ALTERNATE
494 #      #END_ALTERNATE
495 #      \0xnn (non-printing character support)
497 # Following any entry in the file with the characters "#PRE" will cause
498 # the entry to be preloaded into the name cache. By default, entries are
499 # not preloaded, but are parsed only after dynamic name resolution fails.
501 # Following an entry with the "#DOM:&lt;domain&gt;" tag will associate the
502 # entry with the domain specified by &lt;domain&gt;. This effects how the
503 # browser and logon services behave in TCP/IP environments. To preload
504 # the host name associated with #DOM entry, it is necessary to also add a
505 # #PRE to the line. The &lt;domain&gt; is always pre-loaded although it will not
506 # be shown when the name cache is viewed.
508 # Specifying "#INCLUDE &lt;filename&gt;" will force the RFC NetBIOS (NBT)
509 # software to seek the specified &lt;filename&gt; and parse it as if it were
510 # local. &lt;filename&gt; is generally a UNC-based name, allowing a
511 # centralized lmhosts file to be maintained on a server.
512 # It is ALWAYS necessary to provide a mapping for the IP address of the
513 # server prior to the #INCLUDE. This mapping must use the #PRE directive.
514 # In addition the share "public" in the example below must be in the
515 # LanMan Server list of "NullSessionShares" in order for client machines to
516 # be able to read the lmhosts file successfully. This key is under
517 # \machine\system\currentcontrolset\services\lanmanserver\
518 # parameters\nullsessionshares
519 # in the registry. Simply add "public" to the list found there.
521 # The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
522 # statements to be grouped together. Any single successful include
523 # will cause the group to succeed.
525 # Finally, non-printing characters can be embedded in mappings by
526 # first surrounding the NetBIOS name in quotations, then using the
527 # \0xnn notation to specify a hex value for a non-printing character.
529 # The following example illustrates all of these extensions:
531 # 102.54.94.97     rhino     #PRE #DOM:networking  #net group's DC
532 # 102.54.94.102    "appname  \0x14"       #special app server
533 # 102.54.94.123    popular   #PRE         #source server
534 # 102.54.94.117    localsrv  #PRE         #needed for the include
536 # #BEGIN_ALTERNATE
537 # #INCLUDE \\localsrv\public\lmhosts
538 # #INCLUDE \\rhino\public\lmhosts
539 # #END_ALTERNATE
541 # In the above example, the "appname" server contains a special
542 # character in its name, the "popular" and "localsrv" server names are
543 # pre-loaded, and the "rhino" server name is specified so it can be used
544 # to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"
545 # system is unavailable.
547 # Note that the whole file is parsed including comments on each lookup,
548 # so keeping the number of comments to a minimum will improve performance.
549 # Therefore it is not advisable to simply add lmhosts file entries onto the
550 # end of this file.
551 </programlisting></para>
553 </sect2>
555 <sect2>
556 <title>HOSTS File</title>
558 <para>
559 This file is usually located in MS Windows NT 4.0 or Windows 200x/XP in 
560 the directory <filename>%SystemRoot%\SYSTEM32\DRIVERS\ETC</filename> and contains 
561 the IP address and the IP hostname in matched pairs. It can be 
562 used by the name resolution infrastructure in MS Windows, depending 
563 on how the TCP/IP environment is configured. This file is in 
564 every way the equivalent of the UNIX/Linux <filename>/etc/hosts</filename> file.
565 </para>
566 </sect2>
569 <sect2>
570 <title>DNS Lookup</title>
573 <para>
574 <indexterm><primary>DNS</primary></indexterm>
575 This capability is configured in the TCP/IP setup area in the network 
576 configuration facility. If enabled, an elaborate name resolution sequence 
577 is followed, the precise nature of which is dependent on how the NetBIOS 
578 Node Type parameter is configured. A Node Type of 0 means that
579 NetBIOS broadcast (over UDP broadcast) is used if the name 
580 that is the subject of a name lookup is not found in the NetBIOS name 
581 cache. If that fails, then DNS, HOSTS, and LMHOSTS are checked. If set to 
582 Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the 
583 WINS server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast 
584 lookup is used.
585 </para>
587 </sect2>
589 <sect2>
590 <title>WINS Lookup</title>
593 <para>
594 <indexterm><primary>WINS</primary></indexterm>
595 <indexterm><primary>Windows Internet Name Server</primary><see>WINS</see></indexterm>
596 <indexterm><primary>NetBIOS Name Server</primary><see>NBNS</see></indexterm>
597 A WINS (Windows Internet Name Server) service is the equivalent of the 
598 rfc1001/1002 specified NBNS (NetBIOS Name Server). A WINS server stores 
599 the names and IP addresses that are registered by a Windows client 
600 if the TCP/IP setup has been given at least one WINS server IP address.
601 </para>
603 <para>
604 To configure Samba to be a WINS server, the following parameter needs 
605 to be added to the &smb.conf; file:
606 </para>
608 <para><smbconfblock>
609 <smbconfoption name="wins support">Yes</smbconfoption>
610 </smbconfblock></para>
612 <para>
613 <indexterm><primary>WINS</primary></indexterm>
614 To configure Samba to use a WINS server, the following parameters are 
615 needed in the &smb.conf; file:
616 </para>
618 <para><smbconfblock>
619 <smbconfoption name="wins support">No</smbconfoption>
620 <smbconfoption name="wins server">xxx.xxx.xxx.xxx</smbconfoption>
621 </smbconfblock></para>
623 <para>
624 where <replaceable>xxx.xxx.xxx.xxx</replaceable> is the IP address 
625 of the WINS server.
626 </para>
628 <para>For information about setting up Samba as a WINS server, read 
629 <link linkend="NetworkBrowsing">Network Browsing</link>.</para>
631 </sect2>
632 </sect1>
634 <sect1>
635 <title>Common Errors</title>
637 <para>
638 TCP/IP network configuration problems find every network administrator sooner or later.
639 The cause can be anything from keyboard mishaps to forgetfulness to simple mistakes to
640 carelessness. Of course, no one is ever deliberately careless!
641 </para>
643         <sect2>
644                 <title>Pinging Works Only One Way</title>
646         <para>
647         <quote>I can ping my Samba server from Windows, but I cannot ping my Windows
648         machine from the Samba server.</quote>
649         </para>
651         <para>
652         The Windows machine was at IP address 192.168.1.2 with netmask 255.255.255.0, the
653         Samba server (Linux) was at IP address 192.168.1.130 with netmask 255.255.255.128.
654         The machines were on a local network with no external connections.
655         </para>
657         <para>
658         Due to inconsistent netmasks, the Windows machine was on network 192.168.1.0/24, while
659         the Samba server was on network 192.168.1.128/25 &smbmdash; logically a different network.
660         </para>
662         </sect2>
664         <sect2>
665         <title>Very Slow Network Connections</title>
667         <para>
668         A common cause of slow network response includes:
669         </para>
671         <itemizedlist>
672                 <listitem><para>Client is configured to use DNS and the DNS server is down.</para></listitem>
673                 <listitem><para>Client is configured to use remote DNS server, but the
674                 remote connection is down.</para></listitem>
675                 <listitem><para>Client is configured to use a WINS server, but there is no WINS server.</para></listitem>
676                 <listitem><para>Client is not configured to use a WINS server, but there is a WINS server.</para></listitem>
677                 <listitem><para>Firewall is filtering out DNS or WINS traffic.</para></listitem>
678         </itemizedlist>
680         </sect2>
682         <sect2>
683         <title>Samba Server Name-Change Problem</title>
685         <para>
686         <quote>The name of the Samba server was changed, Samba was restarted, and now the Samba server cannot be
687         pinged by its new name from an MS Windows NT4 workstation, but it does still respond to pinging using
688         the old name. Why?</quote>
689         </para>
691         <para>
692         From this description, three things are obvious:
693         </para>
695         <itemizedlist>
696                 <listitem><para>WINS is not in use; only broadcast-based name resolution is used.</para></listitem>
697                 <listitem><para>The Samba server was renamed and restarted within the last 10 or 15 minutes.</para></listitem>
698                 <listitem><para>The old Samba server name is still in the NetBIOS name cache on the MS Windows NT4 workstation.</para></listitem>
699         </itemizedlist>
701         <para>
702         To find what names are present in the NetBIOS name cache on the MS Windows NT4 machine,
703         open a <command>cmd</command> shell and then:
704         </para>
706         <para>
707 <screen>
708 &dosprompt;<userinput>nbtstat -n</userinput>
710               NetBIOS Local Name Table
712    Name                 Type          Status
713 ------------------------------------------------
714 &example.workstation.windows;            &lt;03&gt;  UNIQUE      Registered
715 ADMINISTRATOR     &lt;03&gt;  UNIQUE      Registered
716 &example.workstation.windows;            &lt;00&gt;  UNIQUE      Registered
717 SARDON           &lt;00&gt;  GROUP       Registered
718 &example.workstation.windows;            &lt;20&gt;  UNIQUE      Registered
719 &example.workstation.windows;            &lt;1F&gt;  UNIQUE      Registered
722 &dosprompt;nbtstat -c
724              NetBIOS Remote Cache Name Table
726    Name                 Type       Host Address     Life [sec]
727 --------------------------------------------------------------
728 &example.server.samba;  &lt;20&gt;  UNIQUE      192.168.1.1          240
730 &dosprompt;
731 </screen>
732         </para>
734         <para>
735         In this example, &example.server.samba; is the Samba server and &example.workstation.windows; is the MS Windows NT4 workstation.
736         The first listing shows the contents of the Local Name Table (i.e., identity information on
737         the MS Windows workstation), and the second shows the NetBIOS name in the NetBIOS name cache.
738         The name cache contains the remote machines known to this workstation.
739         </para>
741         </sect2>
743 </sect1>
745 </chapter>