Samba and protocols

 

 

 

 

 

Introduction

This page is another sequel to the original Samba page, and provides some information about setting up Windows local networks to run via NetBIOS over TCP/IP.

It is based on Windows 95, Windows NT, and Windows 2000 running on the workstations.

It was written after I experienced considerable difficulties getting Windows 2000 to talk to Samba on the Linux servers. So what comes below is my solution - there are probably other ways of achieving the same result.

 

Workgroups for Windows

The protocols used by Microsoft to achieve peer to peer networking between Windows based workstations has evolved as the versions of the Windows operating systems have evolved.

Windows 95 and Windows NT by default both provide a choice of two protocols for use in workgroups - these are NetBEUI and IPX/SPX.

NetBEUI is a very simple protocol that requires virtually no configuration - it just works.

However it is limited in what it can do - the fact that it cannot be routed is the biggest problem with it.

The alternative protocol, IPX/SPX is a fully routable protocol, and was also used by Novell as the default protocol for Netware 4 servers.

In Windows networks, sitting above one or other of these two protocols is a software layer that roughly corresponds to the Session layer of the OSI seven layer model - it is known as NetBIOS.

NetBIOS is often referred to as a protocol - this is wrong - it is actually a service, that removes the requirement for the application layer to know anything about the network. NetBIOS does this job on behalf of the application layer.

So a Windows network can be set up so that NetBIOS runs over NetBEUI, or set up so that NetBIOS sits over IPX/SPX.

When Windows 2000 came along, things changed. Microsoft introduced a new form of networking for Windows 2000 workstations - based on TCP/IP.

So Windows 2000 machines could talk to each other using only TCP/IP.

However in order to provide backward compatability with previous versions of Windows networks, Windows 2000 also provides the ability to communicate via NetBIOS over NetBEUI, or over IPX/SPX.

 

So where does Samba fit in ?

Now it gets interesting - because Samba uses NetBIOS over TCP/IP as its communication system.

Although it seems that now there is quite an incompatability between these systems, there is a very easy solution - run everything on NetBIOS over TCP/IP.

All these versions of Windows will work fine in this way, and they can be set up to do it as follows.

 

For Windows 95

  • right click on Network Neighbourhood, and then click on "Properties"

  • highlight NetBEUI, and click on "Remove"

  • highlight IPX/SPX, and click on "Remove"

  • highlight TCP/IP, and click on "Properties"

    select the "Bindings" tab, and check that the boxes for "Client for Microsoft Networks" and "File and printer sharing for Microsoft Networks" are both ticked

    select the "NetBIOS" tab, and check that the box for "I want to enable NetBIOS over TCP/IP" is ticked. It will probably be greyed out, so you cannot change it.

  • keep clicking on the "OK" buttons until you run out of them. It should ask you about doing a reboot, which is required. I have assumed that your pc already has an IP address - if it has not, then nothing will work.

 

For Windows NT

  • right click on Network Neighbourhood, and select "Properties"

  • select the "Services" tab, and check that NETBIOS is installed

  • select the "Protocols" tab

  • highlight NetBEUI, and click on "Remove"

  • highlight IPX/SPX, and click on "Remove"

  • check that TCP/IP is now the only protocol left - if there are other protocols listed, then you may get problems, I don`t know for sure either way

  • select the "Bindings" tab, and check that NetBios is bound to TCP/IP, and that TCP/IP is bound to the network card

  • keep clicking on the "OK" buttons until you run out of them. It should ask you about doing a reboot, which is required. I have assumed that your pc already has an IP address - if it has not, then nothing will work.

 

For Windows 2000

  • right click on "My Network Places", and then click on "Properties"

  • right click on "Local Area Connection", and then click on "Properties"

  • if NetBEUI or NWLink IPX/SPX is installed, then uninstall them

  • highlight TCP/IP, and then click on "Properties"

  • click on "Advanced"

  • select the "Wins" tab

  • click on the radio button to "Enable NetBIOS over TCP/IP"

  • click on "OK", and then ignore the message about an empty primary WINS address - just say "Yes" to continue

  • keep clicking on the "OK" buttons until you run out of them. It might ask you about doing a reboot, which would be required. Again, I have assumed that your pc already has an IP address - if it has not, then nothing will work.

 

Having done all that, you now have a Windows network running via NetBIOS over TCP/IP, and which can include a Linux network server running Samba.

And all three versions of Windows as well as Linux are talking to each other.

 

Speeding things up

You may find that when using My Network Places in Windows 2000 to browse onto the Linux server, that things are a bit slow. Or very slow.

This appears to be that when 2000 is going for a search, it first of all tries to use its new TCP/IP based network system, and if that fails, it tries using NetBIOS over TCP/IP.

There are some things you can do to speed up the NetBIOS process. To see how they work, it is useful to look at how the NetBIOS connection process works.

The following sequence is, I believe, the default sequence of events for a connection via NetBIOS :-

  • 2000 looks in its internal lmhosts cache - if that fails, then

  • 2000 looks for a WINS server - if that fails, then

  • 2000 does a NetBIOS type broadcast - if that fails, then

  • 2000 looks in the lmhosts file - if that fails, then

  • 2000 looks in the hosts file - if that fails, then

  • 2000 looks for a DNS server - if that fails, it gives up

So the obvious place to start is with the lmhosts cache, which is a section of memory which reads the lmhosts file at boot up time, and remembers specific parts of it.

Which parts ?

Those entries which have #pre after them. So an lmhosts file could look like

  

192.192.192.193       alpha
192.192.192.194       beta        #pre
192.192.192.195       charlie     #pre
192.192.192.196       delta
192.192.192.197       echo
192.192.192.198       linux-2     #pre
192.192.192.199       linux-3     #pre

The lmhosts file is located in

C:\winnt\system32\drivers\etc\

In that ...\etc\ folder there is a sample lmhosts file, called "lmhosts.sam"

When Windows 2000 boots up, it reads the lmhosts file, and those entries which have the #pre after them are stored in the lmhosts cache.

It is better to have only those entries that are going to be frequently used by Windows 2000 in the lmhosts cache, because you don`t want to fill up your memory with little used data.

The results from doing this were disappointing, there was very little increase in speed.

So what next - after some more experimentation, I obtained considerable increase in speed by using fully qualified host names in the lmhosts file. So it now looks like :-
  

192.192.192.193       alpha.e-nor.loc.
192.192.192.194       beta.e-nor.loc.        #pre
192.192.192.195       charlie.e-nor.loc.     #pre
192.192.192.196       delta.e-nor.loc.
192.192.192.197       echo.e-nor.loc.
192.192.192.198       linux-2.e-nor.loc.     #pre
192.192.192.199       linux-3.e-nor.loc.     #pre

This provides a very worthwhile improvement.

However I continued to dig and experiment, and eventually found that things began to really take off if I used the hosts file.

The hosts file is in the same folder as the lmhosts file, ie, in

C:\winnt\system32\drivers\etc\

The hosts file which is provided by default is active, ie Windows 2000 is already using it - most of it is defined as comments by the use of the # at the beginning of each line. However the last line
  

127.0.0.1           localhost

is not commented out, and is the loopback lookup, so don`t destroy it.

The hosts file has different rules from the lmhosts file, and one of the things you can do is to have multiple names against the same ip address. This allows Windows 2000 to do lookups on local names, rather than requiring fully qualified names. So a typical hosts file could be :-

  

127.0.0.1             localhost

192.192.192.193       alpha.e-nor.loc.
192.192.192.194       beta.e-nor.loc.
192.192.192.195       charlie.e-nor.loc.
192.192.192.196       delta.e-nor.loc.
192.192.192.197       echo.e-nor.loc.
192.192.192.198       linux-2.e-nor.loc.
192.192.192.199       linux-3.e-nor.loc.

192.192.192.193       alpha
192.192.192.194       beta
192.192.192.195       charlie
192.192.192.196       delta
192.192.192.197       echo
192.192.192.198       linux-2
192.192.192.199       linux-3

So why does this use of the hosts file provide such a big difference in speed - according to the sequence shown above, it is one of the last places that 2000 looks for a lookup.

The only answer that I can come up with is that even though you trying to use NetBIOS, Windows 2000 starts the process by going down the TCP/IP road, rather than down the NetBIOS road.

For the TCP/IP road, the sequence of events is, I believe,

  • 2000 looks in the hosts file - if that fails, then

  • 2000 looks for a DNS server - if that fails, then

  • 2000 looks in the lmhosts cache - if that fails, then

  • 2000 looks for a WINS server - if that fails, then

  • 2000 tries a broadcast - if that fails, then

  • 2000 looks in the lmhosts file - if that fails, it gives up

So although both sequences look in the same places, they do it in a different order.

And in this sequence, the hosts file is the first place that 2000 looks.

 

Some trivia ....

The hosts file and the DNS server map ip addresses to host names, whereas the lmhosts file and WINS server map ip addresses to NetBIOS names.

A host name can be any length, whereas a NetBios name is always 16 characters long.

In most of the world, a host name might be the same as the NetBIOS name, but in the Microsoft world, they are always different. In the Microsoft world, a NetBIOS name is still sixteen characters long, but the sixteenth character is an identifier. So the actual name part is only fifteen characters long.

This therefore raises a question - if the lmhosts file is supposed to contain 16 character NetBIOS names, why does 2000 like having fully qualified host names in it ?

 

Working within Novell Netware environments

If the workstations within the Windows workgroup are also working within a Novell Netware environment, then there are some other points worth noting.

Firstly, if the workstation is running the Microsoft Client for Netware networks, then you cannot remove IPX/SPX.

IPX/SPX is the only protocol that the Microsoft Client for Netware networks can use.

If the workstation is running an up to date Novell client, then this is not a problem, as the Novell client will work quite happily on TCP/IP.

If you want to log on to Netware 4 servers, then again, you cannot remove IPX/SPX. Although you can see a Netware 4 server through TCP/IP, you cannot log on to it using TCP/IP.

You can use the installation process of a current Novell client to remove IPX/SPX from a workstation - choose the "Custom" installation procedure, and tick the boxes for "IP only", and for "Remove IPX".

 

A word about security

It is worth noting that by running NetBIOS over TCP/IP on a workstation, you are potentially allowing other workstations to see into the workstation. Make sure that external workstations can`t see the file system or data they should not be seeing, and don`t have the rights to modify things.

 

© 2002 Ron Turner

Return to the Linux index page