[jcifs] CIFS Interoperabilty Lab

Michael B. Allen mballen at erols.com
Sun Aug 26 12:55:32 EST 2001


The important event at the CIFS Conference for jCIFS is the
Interoperablity Lab. Most if not all of the major vendors have servers and
clients setup on the same network which presents a highly sophisticated
environment in which to test. Chris did a great job and spent quite a
bit of time testing jCIFS in the lab.

In short, jCIFS performed as advertised with the exception of 3 minor
bugs. I would like to recap the bugs that Chris found so that he may
approve my assesment before I prepare the jcifs-0.5.1 packages. All of
these bugs were fixed on the fly during testing and retested successfully
so I'm fairly certain the fixes are correct.

BUG #1 - I thought that VcNumber from SMB_COM_SESSION_SETUP_ANDX was an
unused legacy field. Apprently it is used in Win2K to indicate wheather
or not a client (host) has already initiated a session or if it is the
first. If the VcNumber is 0, the session being initiated is the first. If
VcNumber is not 0 it is an additional connection. jCIFS left this field
uninitialized and thus 0. Unforturnately, Win2K at least will kick off
the original session if an additional session is made with a VcNumber
of 0. It appears as though setting VcNumber to 1 solves this problem
(although it's not a problem for jCIFS to be kicked off because it will
quitely reconnect on the fly, it is a problem for other clients such
as smbclient and it is inefficient to keep knocking off connections of
other programs).

FIX #1 - Set VcNumber to 1.

BUG #2 - The broadcast flag in a NameQueryRequest was not being set for
broadcast querys. Believe it or not this will not actually cause a problem
under most envionments and therefore was been over looked. If however
the WINS server is on the same subnet it will respond to these queries
believing they are unicast queries. If the server jCIFS is trying to
connect to is not in WINS but is on the local subnet, the connect may
fail depending on who answers more quickly.

FIX #2 - Set the broadcast flag for broadcast queries. I forgot to
add one line of code when I added the new resolveOrder/LMHOSTS name
resolution functionality.

BUG #3 - An exception was being caught in the TRANS2_FIND_FIRST/NEXT2
operations that would result in SmbFile.list() returning null. A
NullPointerException would be thrown as a result. This is just not
consistent Exception handling (actually a NullPointerException should
never be thrown in code internal to the API). The original exception
would only occur if an error on the server occured and has nothing to do
with of jCIFS (it was discovered when ran against a very green version
of Samba 3).

FIX #3 - Remove the try/catch, return a String[] of zero elements, and
let any exceptions be caught by the try/catch of the caller where they
are logged.

-- 
Wow a memory-mapped fork bomb! Now what on earth did you expect? - lkml




More information about the jcifs mailing list