[jcifs] ERROR_MORE_DATA from NetServerEnum2: NetServerEnum3

[Gary Rambo]

NetServerEnum3 turned up in a network trace between an XP client and a W2K or W2K3 PDC and appears to solve the 64K server list limit problem: it is similar to NetServerEnum2 but instead of taking a serverType parameter it takes a server name, the last server in the NetServerEnum2Response.

I wasn't able to find this in the Samba 3 code (although the include/rap.h does define RAP_NetServerEnum3), and I'm not sure how a Samba PDC will respond but I've tested it on several networks against Win2k PDCs with good results.

It can be tested by throttling back the jcifs.smb.client.transaction_buf_size to a small value. This will force Jcifs to use NetServerEnum3 to handle the overflow. The minimum value I've tested with is 576: Jcifs deducts 512 and the result should leave room enough for enumerating one server at a time.

The attached tar.gz file contains the NetServerEnum3.java and NetServerEnum3Response.java files, not quite identical to NetServerEnum3*; one line changes to SmbComTransaction.java and SmbTree.java, and a version of SmbFile.java with a previously noted change at lines 1472ff (removing the workgroup/domain name from the SmbFile constructor) and the code that uses NetServerEnum3 at lines 1495ff. This code determines that the case applies (MORE_DATA from listFiles() on a workgroup), gets the last server from the Enum2 list, prepares a failSafe value to determine that progress is being made, and sends the request. The response parsing is a diminished version of the Enum2Response parsing.

(The changes are made to the 0.8.2 code base.)

The Jcifs layout, especially the SmbComTransaction class, made this easy to implement.

Thanks.

Gary

Michael B Allen wrote:
> Eric said:
> 
>>>
>>>I thought RAPs only handled upto 64K of data?
>>>
>>
>>I *think* they can handle more (via secondary requests for additional
>>data); the appendix previously mentioned seems to imply this, and
>>glancing over samba's clitrans.c (cli_send_trans and
> 
> cli_receive_trans,
> 
>>which is what ends up getting called by clirap.c's cli_api) looks like
>>they implement something similar.  When I did the rap stuff, I didn't
>>really bother digging into it (it really was just some quick and dirty
>>poking around).  Could be useful to look at though.
> 
> 
> After a quick google:
> 
> Leach, Naik                                             [Page 10]
> 
> 
> INTERNET-DRAFT    CIFS/E Browser Protocol        January 10, 1997
> 
> 
> 
> A Master Browser MUST periodically announce itself to all browsers for
> <snip>
> 
>     Note: The list of servers that the Master Browser maintains and
>     returns to the Backup Browsers, is limited in size to 64K of
>     data. This will limit the number of systems that can be in a
>     browse list in a single workgroup or domain to approximately two
>     thousand systems.
> 
> I'm pretty sure this is why I thought RAPs could handle only 64K.
> 
> Mike
> 

-- 
Gary Rambo
Aventail Corporation
Secure access for the real world.
www.aventail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NetServerEnum3.tar.gz
Type: application/x-tar
Size: 22575 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20040315/0a43ce83/NetServerEnum3.tar-0001.tar