[jcifs] CIFS Interoperabilty Lab

[Christopher R. Hertel]

These are good.

Yeah, the VcNumber value is a contencious issue.  Several people have
ideas regarding how it *should* be used but the underlying problem is that
DOS and its decendants use a single interface layer to talk to an SMB
server.  On a W2K system, SMB processing is handled in the "kernel".  
That means that there is a single point at which VC numbers can be
assigned and managed.

On a system running jCIFS, smbclient, etc., each instance is separate.  
There is no way to coordinate virtual circuit numbers so there is no way
ensure that only the *first* connection is given a value of zero.  
Unfortunately, W2K servers assume that the IP/VcNumber combination
indicate a unique host so if the IP is the same and a new connection is
made with VcNumber==0 W2K will kill all older connections from the same
host.  Try it yourself.

It would be better if W2K would simply send an SMB Echo or some-such to
see if the clients are still alive and connected.

Chris -)-----

On Sat, Aug 25, 2001 at 10:55:32PM -0400, Michael B. Allen wrote:
> 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
> 

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org