[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.
> 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,
More information about the jCIFS