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 NetServerEnum3.

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 NetServerEnum2 response.)

Here's what the NetServerEnum3 request structure looks like:

    struct
      {
      ushort RAPCode;
      uchar *ParamDesc;
      uchar *DataDesc;
      struct
        {
        ushort InfoLevel;
        ushort BufrSize;
        ulong  ServerType;
        uchar *Workgroup;
        uchar *LastEntry;
        } Params;
      } NetServerEnum3Req;

Compare that against the NetServerEnum2 request and you'll see that it differs only in the addition of the LastEntry field.

Some notes:

• The RAPcode for NetServerEnum3 is 215 (0x00d7).

• 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 3.4.3.1 regarding variations in the NetServerEnum2 ParamDesc string.)

• 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 reply packet.

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 parameters.