That was a good explaination.  Basically what I thought was happening,
but it doesn't help in this case.

This isn't OSA (yet), it's a 3172 via escon to VM's TCPIP (z/VM 4.2).
There was a problem with Samba and broadcast on this setup, but not
anymore.

But I don't think it would make any difference as Linux22 seems to be
working just fine and it shows up in the "browse lists".  All other
Samba guests, don't.

What might be a factor, was in the case of Linux22, Linux22 was
installed, SP1 applied, then Samba brought up (which called for a series
of packages to be installed.  Note SP1 fixes may not be on these newly
installed packages).  Samba shows as "Samba 3.0.4-SUSE".

All other images (which don't work properly), were installed with SP1
installed at Linux install time (SP1 was part of the CD collection and
was used by the install process).  This Samba shows as "Samba
3.0.9-2.1.5-SUSE".

It doesn't seem that the "man" pages were updated by SP1, as when you
use Yast to update the Samba parameters, parms such as "local master" as
set to true/false, but the man pages shows yes/no.  That shoots a hole
in my confidence in that part of the 'man' pages.

I am using WINS, and all images are pointed to the same IP address of
the WINS server.

I did take the Linux22 machine down for the weekend.  I had hoped that,
if it gained some special attributes within the Windows world, it would
loose them and perhaps be assigned to one of the other Linux images.  No
joy.

On the Linux22 side, I keep getting:

May  4 12:11:17 linux22 nmbd[12130]: [2005/05/04 12:11:17, 0]
nmbd/nmbd_incoming
dgrams.c:process_master_browser_announce(385)

May  4 12:11:17 linux22 nmbd[12130]:   process_master_browser_announce:
Not conf
igured as domain master - ignoring master announce.


which tells me that some machine continues to think that this image is
a "master browser".  Which it was, for a short time a week or two ago.
Perhaps no other system has taken over as a "master browser".

All my Samba images (Linux22  to Linux26), all specify either "backup
domain controller" or "no DC", and "domain master = no".  Some may
specify "local master = true" and some "local master=false".

Out of frustration, I've gone to the lenghts (ok short lengths) of
rebooting all the images just to make sure that the configuration files
are being reread and what I think should be used, is being used.

So, is there a Windows command (or Linux command) that will tell me who
is the PDC and/or the "master browser"?  Perhaps that command will help
me understand when I actually made a change to this process.

Thanks

Tom Duerbusch
THD Consulting


>>> [EMAIL PROTECTED] 05/04/05 11:27 AM >>>
> What I'm interested in is being able to diag a problem based on
error
> messages.

Open source applications rarely do error message manuals (in fact,
CUPS
is the only one I know of). You should assume that the source is the
only way you'll find this information.

> May  4 10:29:45 linux26 nmbd[4160]:
domain_master_node_status_fail:
> May  4 10:29:45 linux26 nmbd[4160]:   Doing a node status request to
> the domain
> master browser
> May  4 10:29:45 linux26 nmbd[4160]:   for workgroup WORKGROUP at IP
> 192.168.99.2
> 22 failed.

These 3 messages indicate that the current SMB local domain browser
did
not respond to a query, so the node is assuming that a domain browser
election is required.

Unless you have the layer 2 OSA microcode, these messages will always
occur from nmbd, which is attempting to do broadcast-based SMB traffic
which the OSA does not permit in layer 3 mode.

> The situation is that Linux22 (192.168.99.222) is a Samba 3.0
server.
> It is the only one that is really running properly.  That is, it is
> listed in the Windows Workgroups under Computers Near Me (W2K).
>
> Linux26 (192.168.99.226) is another Samba 3.0 server.
> Everything works
> there except that it is not listed under Workgroups in Computers
Near
> Me.

Check whether the server that does not appear is correctly registering
with WINS, and that the client is getting valid WINS information via
DHCP. You must have WINS enabled to use Samba servers in situations
where nmbd cannot broadcast, and later versions of Windows do not
accept
broadcast-based SMB resolution at all.

> It looks like it is trying to join or notify Linux22 and
> fails, which I
> suspect is the reason why it isn't listed as part of the
> Workgroup.  How
> it knows to look for Linux22?  I don't know.  Linux26 hasn't a clue
> about any other Linux machine running.

This is a SMB protocol thing, not really Samba's fault.

When SMB was designed, the original version of the protocol used raw
hardware frames to find other nodes and transport data. Part of the
initialization process for SMB communications was when each node
initialized, it transmits a query looking for a "master browser" on
the
same physical segment as the client and waits a fixed time period for
responses (usually 30 seconds or so -- this is why you always had a
delay when you opened Network Neighborhood on Win95/98 and OS/2
machines; it was waiting for the response to the browser probe frame).

The "master browser" in SMB v1 is used to map SMB names to MAC
addresses, so that the original SMB packets could be correctly
addresses
w/o having global knowledge of all the nodes (this is pre-WINS). The
"master browser" query contains a bunch of information about the
client,
including SMB version numbers, SMB implementation details, etc. If
there
is no "master browser" on the network segment or none respond, the
client assumes that it is now the master browser and should handle
responding to master browser requests if it sees on. If a master
browser
answers, the SMB version information is compared with the version
information on the client, and IF the master browser answer contains a
version number HIGHER than the client, the client uses the existing
master browser to do SMB name to MAC address translation.

If the CLIENT version number is HIGHER than the master browser answer
(or a couple of other cases appear), the client sends out a "force
election" frame, which is supposed to force all clients on the
physical
segment to respond with a client information frame similar in format
to
the master browser answer. These responses are sent via hardware
broadcast (so all clients hear them). Each client receives the
broadcast, does the version comparison, and the result is an
"election"
of a new master browser for the broadcast-based name resolution stuff.

In Samba, smbd handles the IP-oriented pieces of doing file service,
and
nmbd handles the broadcast-based piece. If you have network adapters
that support layer 2 access to the media (the LCS, CLAW, and OSA/L2
ucode), nmbd works properly.  If you have one of the layer 3 only
network adapters (any of the QDIO adapters prior to the layer 2 OSA
microcode), the device does not transmit or receive broadcast frames,
so
nmbd cannot work. (This stuff is all in non-routable frames, which is
why MS had to invent something like WINS to do a similar function over
IP.) The messages you see here are caused by nmbd trying to do it's
job
in an environment where it is not possible to receive broadcast
traffic
(the OSA is filtering it out), thus anything nmbd tries to do will
automatically fail.

The Samba configuration shipped on most of the distributions is the
same
as the one on the Intel Linux, with both smbd and nmbd enabled.

There is a good analysis of the SMB protocols in the "Samba Made Easy"
book by Wiley Press.

-- db

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390
or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to