[jcifs] ERROR_MORE_DATA from NetServerEnum2: NetServerEnum3
grambo at aventail.com
Mon Mar 15 20:45:27 GMT 2004
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.
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
>>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
> 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.
Secure access for the real world.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 22575 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20040315/0a43ce83/NetServerEnum3.tar-0001.tar
More information about the jcifs