Gary Rambo at Aventail sent a really cool message
to the jCIFS mailing list with an analysis and implementation of a
second Browse Service RAP call, known as
Basically, the NetServerEnum3 RAP exchange is an
follow-on to NetServerEnum2. It is used to read
additional Browse List entries if the BufrSize in the initial
NetServerEnum2 request was not sufficient to handle
the entire list. (That is, if
EntryCount < AvailCount in the
Here's what the NetServerEnum3 request structure
Compare that against the NetServerEnum2 request and
you'll see that it differs only in the addition of the
- The RAPcode for NetServerEnum3 is 215
- The NetServerEnum3 reply appears to be identical
to the NetServerEnum2 reply.
- The Status code in the NetServerEnum* reply will
be 0x00ea (234 == Additional data are available) if there
are more Browse List entries available.
- In the request, the ParamDesc string is given as
"WrLehDzz". The extra 'z'
(relative to the string used in the NetServerEnum2
request) is due to the added LastEntry string field.
It is possible that there is also a variation of this message
that does not include the Workgroup (a.k.a.
Enumeration Domain) field, in which case the
ParamDesc string would be
"WrLehDOz". No such beast has been
spotted in the wild, but it would make an interesting test case.
(See the annotation in section
variations in the NetServerEnum2
- In the NetServerEnum3 request, LastEntry
is set to the last name returned in the previous
NetServerEnum2 or NetServerEnum3
reply. It provides a starting point for the next batch of entries.
- As stated above, the last name in the NetServerEnum*
reply is sent to the server in the NetServerEnum3
request. In the traces studied so far, the subsequent reply will
repeat that entry as the first entry in the new sublist.
For example, if the first reply includes entries
AHO..TANENBAUM you would send TANENBAUM
in the NetServerEnum3 request. From (limited)
experience, the NetServerEnum3 reply will then
start with TANENBAUM.
The first problem here is that the entry will appear twice in
the list. The second problem is that you can't count on this
behavior from the server (this is CIFS we're talking about), so
you can't just toss one of those entries until you've compared
them to be sure that they match. Ugh.
- It appears as though the entries are returned in sorted order (but
never count on such things when writing code).
This is an obscure RAP exchange. (Its existence was a complete
surprise to me.) Ethereal (v0.10.4 was tested) is aware of it,
however, and can parse it...mostly. There's a little trouble with the
Support for NetServerEnum3 has been added to jCIFS client
code (starting with v0.9.0). You can test NetServerEnum3
behavior by fiddling with the BufrSize value and other