[jcifs] OT: Tracking down a rogue workgroup.

Christopher R. Hertel crh at ubiqx.mn.org
Thu Jan 21 18:32:25 MST 2010

Ray Van Dolson wrote:
> Thanks for the reply Christopher.
> On Thu, Jan 21, 2010 at 02:18:52PM -0800, Christopher R. Hertel wrote:
>> Oh, man... it's been so long since I looked at all of this.
>> Start here:  http://ubiqx.org/cifs/Browsing.html
>> The packet information is in there somewhere (I wrote it long enough
>> ago that I don't recall where).
>> jCIFS may be a better answer, but I have written up a tool that does
>> a nice job of generating name service queries.  It takes some putting
>> together, but you can find it here:  http://ubiqx.org/libcifs/
>> ...what you want (if you want to go this route at all) is the
>> nbtquery tool under the tools directory.  You'll need most of the
>> tree to compile the tool, but if you're familiar with C it shouldn't
>> be a problem.
>> Anyway, you should be able to perform directed name queries using
>> that tool (or the nmblookup tool that comes with Samba, but mine's a
>> little more utilitarian), which would help you find master browsers
>> and, eventually, the offending node.
> Sounds promising.  Would the master browsers contain a record of the
> host within their subnet if the host was offline?  I assume this
> expires after a while.

It does.

> One of our challenges is the host appears and disappears.  I'm thinking
> it'd be nice to write a tool/script that calls NetServerEnum2 to our
> domain controller and tells us when the workgroup shows up... that
> might help us establish a pattern or at least know when *not* to look.

It takes a while for a new entry to make it all the way to the domain master
browser.  I think my book has an approximate timing.

>> Another thing out there...  If you've got Windows systems,
>> particularly older ones, there are two W2K Resource Kit utilities
>> that may help.  You're looking for BrowStat and BrowMon.
>> Hope that's useful.
> Many thanks,
> Ray

More information about the jCIFS mailing list