client: browse doesn't work with only win98 in workgroup

Christopher R. Hertel crh at ubiqx.mn.org
Sat Mar 1 22:49:26 GMT 2003


Okay, I understand the problem now.

The problem is that W/9x boxes do not recognize the generic "*SMBSERVER"
name in the NBT Session Setup Request.  Also, W/9x boxes will send back an
error if the called name is not correct in the NBT Session Setup Request.
You should get a NEGATIVE SESSION RESPONSE (0x83) message with an error code
of:
  0x82:  Called Name Not Present

Since W/9x systems do not support the generic "*SMBSERVER" name, this error
message is correct.  Basically, it's the NBT equivalent of "That port isn't
listening for a connection".

The solution is to find the Server Service name on the remote machine.
This is typically done by sending a Node Status query and looking for a name
with a suffix byte value of 0x20.

More inline below...

Derrell.Lipman at UnwiredUniverse.com wrote:
> 
> "Christopher R. Hertel" <crh at ubiqx.mn.org> writes:
> 
> > Derrell,
> >
> > Can you give me a better idea of what you are trying to do?
> >
> > Above, you say you are trying to find all hosts that are members of a
> > given workgroup.  The question is: why?  What is it that you are
> > actually trying to accomplish?
> 
> I'm working on providing a tree-style view of the network in a fashion
> similar to what Windows Explorer does.  The top level of an SMB/CIFS
> network is something like "Microsoft Windows Network".  The next level
> down is the list of workgroups/domains within the network;

Okay.  At this level what you need to do is talk to *a\ny* Local Master
Browser on the local LAN.  If you know a specific workgroup name you can use
that, otherwise you can find a list of workgroups by querying for the
"\x01\x02__MSBROWSE__\x02<01>" name.  (That last <01> is the suffix byte,
value 0x01).

If the network is relatively stable, the LMBs will have exchanged data with
one another, and any LMB will have the list of all other workgroups that are
known.

Anyway, once you have one (or more) LMB IP addresses, you can try to query
for the Browse List.  In this case, you want only the workgroup/domain
entries, so what you should see on the wire is a NetServerEnum2 Domain Enum
request.

> then the hosts within each workgroup;

Nope.  You can only get the list of servers in the workgroup that are
advertising services.  The list of all hosts which are workgroup members is
not kept by the browse service.

...but that's not what you really want, anyway.  What you really want is the
list of known servers.  That's a NetServerEnum2 with all the server type
bits turned on.  The LMB (or any available backup browser) should have this
list.

> then the shares within each share, etc.

Shares offered by the server.  Okay.  Note that some servers require
authentication before they allow enumeration of shares.

> I don't know what version of Windows will be the master browser, and I
> don't want to force it by using Samba as the master browser.

Right.

> Therefore I have to be able to enumerate the hosts within a workgroup
> regardless of what versions of Windows happen to be on the network.

That's not a problem, as long as you have a valid CALLED name in the NBT
Session Request.  Samba ignores the CALLED name, W/NT and W2K accept the
generic "*SMBSERVER" name (so Samba can 'guess'), and I don't know about
W/XP.  W/9x, as you've seen, requires the correct name in this field.

> > Keep in mind that there is a *very* big difference between the set of
> > hosts that are members of a workgroup and the set of servers offering
> > services within that workgroup.  Two distinct systems are used to
> > gather those two lists.
> 
> The latter works fine.  If I already know the host name, I can see the
> shares on that host.

No.  That's not what I said.
The "latter" in my note above is the "set of servers offering services
within a workgroup" which is exactly what you're having trouble finding.

> The problem is enumerating the hosts within a workgroup.

I know that this is pedantic, but it's important to understand that there is
a difference between the set of hosts in a workgroup and the servers
offering SMB services in the workgroup.  A host may be a client and it may
not be offering SMB services, in which case it will not show up when you try
listing the servers in the workgroup.

> In the case of smbwrapper and smbsh, one is supposed to be able to do:
> 
>   ls /smb
> 
> to see the list of workgroups/domains, and
> 
>   ls /smb/WORKGROUP
> 
> to see the list of hosts within the workgroup "WORKGROUP", and

...all of the servers in the workgroup...

>   ls /smb/WORKGROUP/HOST
> 
> to see a list of shares on the computer called "HOST".

Right.  We leverage that hierarchy with the SMB URL.  See:
  http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-04.txt

> All of these work with the method implemented in smbwrapper, except for
> enumerating the list of hosts within a workgroup where the master browser
> for the workgroup is a Windows 98 or Windows 95 machine.

Ah!  Okay.  As Richard asked... What tool are you using (libsmbclient?) to
do this?  It may be that you need to do the extra reverse-resolution step
yourself.

> If there is a Windows 2000 server acting as the master browser for the
> workgroup, then obtaining the list of hosts within the workgroup works
> fine.  However, the cli_session_request() call fails (gets a result of
> 0x83 from the peer) when the master browser is a win98 machine, so the
> list of hosts within the workgroup is therefore unavailable.

...as explained above.

> Does this help clarify the problem?  If not, please query me again and
> I'll try to explain differently.

See also the link below to my docs.  There's enough in the docs to help
explain all of this.

Chris -)-----

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org


More information about the samba-technical mailing list