[jcifs] enumerating domains with Wins server

[Christopher R. Hertel]

My annotation writeup is available online and I've spoken with the 
Ethereal developers about improving the parsing of NetServerEnum3.

Thanks for bringing this up and making all these improvements possible!

Chris -)-----

http://ubiqx.org/cifs/Browsing.html#BRO.4.3.2

On Fri, May 28, 2004 at 10:38:02AM -0700, Gary Rambo wrote:
> Chris,
> 
> 1	The Windows browser passes the final server name back as the seed 
> entry in the NetServerEnum3 request, and gets the same name back as the 
> first server in the reply. I'm sure you are right that 'some servers 
> "might"' start the reply with the next entry following the seed, but I 
> was younger then and assumed that what I was seeing was somehow lawlike. 
> The oldest google reference I saw to NetServerEnum3 was an August 2002 
> security advisory, which may mean that most of the implementations were 
> constructed around the same time, so there may not *yet* be much divergence.
> 
> 2 & 3	Looking again at the packets I think you are right: the 32-bit 
> value certainly looks like the Enum2 serverType field, and the entire 
> response once again appears to be 26 bytes, as with Enum2.
> 
> Thanks.
> 
> Gary
> 
> 
> 
> Christopher R. Hertel wrote:
> >Gary,
> >
> >So... I'm working on writhing up NetServerEnum3 and I'm noticing the
> >following oddities:
> >
> >- In the trace you sent, the last entry in the NetServerEnum2 (that's '2') 
> >  response is "HXXXX".  (Well, it's not exactly that, but I'm fudging for 
> >  public posting.)
> >
> >  You (correctly--I mean what else could you do) pass that back to the
> >  server in the first NetServerEnum3 (that's '3') request.  The odd thing
> >  is that the server returns "HXXXX" as the *first* entry in the reply.
> >
> >  That's wierd, since the client now has "HXXXX" twice.  Is that what you 
> >  see when a Windows box is the client?  The client code will have to make 
> >  sure that the entry doesn't get displayed twice.  Just assuming that the 
> >  first entry in the second list is a duplicate won't work, since some 
> >  servers *might* start the NetServerEnum3 with the entry following 
> >  "HXXXX" (which is what I would expect).
> >
> >- In your message describing this (back in March) you said that the string 
> >  field containing the last returned entry replaces the serverType field.  
> >  I'm still seeing the serverType in the trace.  Am I missing something 
> >  or was that just early analysis?  I ask because, as I understand it, the 
> >  trace I'm seeing was generated using your modified jCIFS as the client
> >  and I want to make sure I understand what Windows is doing.
> >
> >Also, in your message you said that the NetServerEnum3 response was 
> >diminished with respect to the '2' response.  I'm not seeing it.  How does 
> >the message change?  It looks different in Ethereal but when I did down I 
> >think that's simply Ethereal not handling the packet correctly.
> >
> >Interested in anyone's feedback on these.  It's fun tracking down a new 
> >call.  :)
> >
> >Thanks, Gary!  This is interesting stuff!
> >
> >Chris -)-----
> >
> 
> -- 
> Gary Rambo
> Aventail Corporation
> Secure access for the real world.
> www.aventail.com

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
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