[jcifs] querying a wins server for a list of workgroups
Christopher R. Hertel
crh at ubiqx.mn.org
Fri Jul 27 02:02:51 EST 2001
On Thu, Jul 26, 2001 at 03:23:41AM -0400, Michael B. Allen wrote:
> I knew this one was coming :-P
> > 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.
Nope. 0x1C names are very, very wierd.
Domain Controllers register these names. They are *group* names, not
unique. Until W2K, they were the *only* group names which got special
treatment from WINS. They are called "Group Special" or "Internet
Group" names. Here's the deal:
All DCs register the <ntdomain>0x1C name. The WINS server keeps a list of
the IPs that have registered that name. The list has a maximum of 25
entries. (Other group names are simply mapped to 255.255.255.255--which
is *not* RFC compliant but it's what Microsoft does. Sigh.)
The 0x1C name can be used to find PDCs or BDCs for authentication
The PDC also registers the <ntdomain>0x1B name, which does dual duty.
The 0x1B name is a unique name, not a group name. It identifies that
particular DC as the PDC, and it also identifies that node as a DMB.
Samba can register the 0x1B name for the DMB if there is no PDC, thus
allowing browse list sync without requiring a PDC.
> 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.
If there is a 0x1B name (not 0x1c) then you could (I suppose) query the
DMB for the browse list. Note that if you find a 0x1B but you don't find
a 0x1D name, then the workgroup does not exist on your subnet.
> 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 strait 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.
You *cannot* use WINS to find Local Master Browsers on remote subnets.
WINS doesn't store 0x1D names, and it only stores the 255.255.255.255
address for the __MSBROWSE__ name.
> Otherwise you'll have to wait for jcifs-0.6dev1.
> I know Chris should have something to say about this too as it affects
Evil grin. ;)
> the SMB URL behavior. If smb://workgroup is a workgroup on another subnet
> where broadcasts do not reach what's the protocol?
That's a good question. The answer, though, is that the
<remote_workgroup>0x00 group name would be registered with the WINS
server. Thus, the name exists within the namespace.
Adding a feature to jCIFS to allow it to query DMBs in addition to LMBs
doesn't break that, it just gives jCIFS the advantage of being able to
access browse lists in a more direct way. Windows systems have to wait
until their LMBs sync with their DMBs.
In some cases, the Windows system will never see browse lists outside
their subnet. This happens when their subnet contains only workgroups and
no ntdomains, thus no sync with a DMB. Again, jCIFS has an advantage if
it can find the 0x1B name of a "foreign" ntdomain and query the DMB
One more interesting thought... If you know the IP address of a remote
LMB (imagine a remote workgroup--no DMB), you should be able to ask it for
its browse list. There is currently no mechanism in the SMB URL to do
this. The draft could, however, be changed to allow:
to go through the same semantic 'is it a server or a workgroup' hoops that
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
More information about the jcifs