Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Samba HowTo Guide
Prev Home Next

NetBIOS over TCP/IP

Samba implements NetBIOS, as does MS Windows NT/200x/XP, by encapsulating it over TCP/IP. NetBIOS-based networking uses broadcast messaging to effect browse list management. When running NetBIOS over TCP/IP, this uses UDP-based messaging. UDP messages can be broadcast or unicast.

Normally, only unicast UDP messaging can be forwarded by routers. The remote announce parameter to smb.conf helps to project browse announcements to remote network segments via unicast UDP. Similarly, the remote browse sync parameter of smb.conf implements browse list collation using unicast UDP.

The methods used by MS Windows to perform name lookup requests (name resolution) is determined by a configuration parameter called the NetBIOS node-type. There are four basic NetBIOS node types:

  • b-node (type 0x01): The Windows client will use only NetBIOS broadcast requests using UDP broadcast.

  • p-node (type 0x02): The Windows client will use point-to-point (NetBIOS unicast) requests using UDP unicast directed to a WINS server.

  • m-node (type 0x04): The Windows client will first use NetBIOS broadcast requests using UDP broadcast, then it will use (NetBIOS unicast) requests using UDP unicast directed to a WINS server.

  • h-node (type 0x08): The Windows client will use (NetBIOS unicast) requests using UDP unicast directed to a WINS server, then it will use NetBIOS broadcast requests using UDP broadcast.

The default Windows network client (or server) network configuration enables NetBIOS over TCP/IP and b-node configuration. The use of WINS makes most sense with h-node (hybrid mode) operation so that in the event of a WINS breakdown or non-availability, the client can use broadcast-based name resolution.

In those networks where Samba is the only SMB server technology, wherever possible nmbd should be configured on one machine as the WINS server. This makes it easy to manage the browsing environment. If each network segment is configured with its own Samba WINS server, then the only way to get cross-segment browsing to work is by using the remote announce and the remote browse sync parameters to your smb.conf file.

If only one WINS server is used for an entire multisegment network, then the use of the remote announce and the remote browse sync parameters should not be necessary.

As of Samba-3, WINS replication is being worked on. The bulk of the code has been committed, but it still needs maturation. This is not a supported feature of the Samba-3.0.20 release. Hopefully, this will become a supported feature of one of the Samba-3 release series. The delay is caused by the fact that this feature has not been of sufficient significance to inspire someone to pay a developer to complete it.

Right now Samba WINS does not support MS-WINS replication. This means that when setting up Samba as a WINS server, there must only be one nmbd configured as a WINS server on the network. Some sites have used multiple Samba WINS servers for redundancy (one server per subnet) and then used remote browse sync and remote announce to effect browse list collation across all segments. Note that this means clients will only resolve local names and must be configured to use DNS to resolve names on other subnets in order to resolve the IP addresses of the servers they can see on other subnets. This setup is not recommended but is mentioned as a practical consideration (i.e., an “if all else fails” scenario). NetBIOS over TCP/IP is an ugly and difficult to manage protocol. Its replacement, NetBIOSless SMB over TCP/IP is not without its own manageability concerns. NetBIOS based networking is a life of compromise and trade-offs. WINS stores information that cannot be stored in DNS; consequently, DNS is a poor substitute for WINS given that when NetBIOS over TCP/IP is used, Windows clients are designed to use WINS.

Lastly, take note that browse lists are a collection of unreliable broadcast messages that are repeated at intervals of not more than 15 minutes. This means that it will take time to establish a browse list, and it can take up to 45 minutes to stabilize, particularly across network segments.

When an MS Windows 200x/XP system attempts to resolve a host name to an IP address, it follows a defined path:

  1. Checks the hosts file. It is located in %SystemRoot%\System32\Drivers\etc.

  2. Does a DNS lookup.

  3. Checks the NetBIOS name cache.

  4. Queries the WINS server.

  5. Does a broadcast name lookup over UDP.

  6. Looks up entries in LMHOSTS, located in %SystemRoot%\System32\Drivers\etc.

Given the nature of how the NetBIOS over TCP/IP protocol is implemented, only WINS is capable of resolving with any reliability name lookups for service-oriented names such as TEMPTATION<1C> a NetBIOS name query that seeks to find network logon servers. DNS has no concept of service-oriented names such as this. In fact, the Microsoft ADS implementation specifically manages a whole range of extended service-oriented DNS entries. This type of facility is not implemented and is not supported for the NetBIOS over TCP/IP protocol namespace.

Samba HowTo Guide
Prev Home Next

 
 
  Published under the terms fo the GNU General Public License Design by Interspire