[jcifs] querying a wins server for a list of workgroups

[Michael B. Allen]

I knew this one was coming :-P

jCIFS cannot list the servers on a subnet other than the one it's
running on (yet). It can enumerate all the workgroups for all subnets,
and if you know the name/ip of a server on another subnet it can list
it's shares. But it cannot find the master browser for another subnet
yet and therefore it cannot retrieve the list of servers for a workgroup
on that subnet. Explaination follows below ...

On Thu, Jul 26, 2001 at 12:06:42AM -0400, Ian Charnas wrote:
> Hey guys. I'll be as brief as I can. I have a network with [for our
> purposes] 3 segments: A, B, and C. Each segment is on its own switch,
> and broadcasts between switches are blocked by the router connecting
> the switches. This means we must use WINS so netbios clients and servers
> can find each other.
> 
> On segment A, I have a Windows NT 4 server named "wins1" running WINS.
> On segment B, I have a Win2k workstation named "workhorse"
> On segment C, I have a linux box running Samba.
> 
<snip diagnostic>
> 
> However, now I try to look up smb:// (to get a list of workgroups)
> .... but jcifs doesn't ask the wins server this time. Instead, jcifs
> sends a netbios NameQueryRequest to the broadcast address to find
> a master browser, and then it asks the master browser for a list of
> workgroups. Well, the master browser only knows of the workgroups within
> its network segment.

Actually I believe it should know all the workgroups. It may be necessary
that it is a *domain* master browser but at work the workgroups retrieved
from the master browser are workgroups that are not just on the local
subnet.

> The WINS server knows about all the workgroups in all the segments, so
> why isn't jcifs asking the wins server for this information? Am I doing

Because WINS won't return a list of this information. Try running a
packet sniffer and run Netwrok Neighborhood. I think you'll find that
a query for the <workgroup>0x1c name is sent to the WINS server which
then returns the IP address of the master browser for that workgroup
which might very well be on a different subnet.

I have not fixed this because I have to examine the traces and make sure
jCIFS does it the same way that NT client does. This *may* be as simple as
running another thread to look up the 0x1c name along with 0x20 and 0x1d.

It sounds like you have a pretty good understanding of this stuff. Why
don't you give it a look. Look at the QueryThread code in SmbURL and
you'll see what I'm talking about. If this is really how NT does it, it
should be pretty stait forward to add this 0x1c WINS lookup. You would
then be able to resolve master browsers on different subnets and viola
you will be able to enumerate every host on the *entire* network.

Otherwise you'll have to wait for jcifs-0.6dev1.

I know Chris should have something to say about this too as it affects
the SMB URL behavior. If smb://workgroup is a workgroup on another subnet
where broadcasts do not reach what's the protocol?

Mike