[jcifs] DFS-Links and jcifs.smb.client.soTimeout

Tapperson Kevin Kevin.Tapperson at hcahealthcare.com
Thu May 19 19:51:08 GMT 2005


>> while testing some DFS-stuff with jCIFS 1.1.10 I noticed the following behavior:
>> 
>> When I'm trying to access a DFS-Link with a newly generated NPA-Object, I get 
>> the expected DfsReferral-Excpetion. Now, when I'm trying to access the same DFS-
>> Link a second time (with the old NPA-Object as well as with a new one) I get an 
>> "Invalid access to memory location"-Exception. This behavior only occurs when 
>> there are less than <jcifs.smb.client.soTimeout> milliseconds between the two 
>> trys. After waiting <jcifs.smb.client.soTimeout> milliseconds I get the 
>> DfsReferral-Exception again.
[snip...]
>
>Or it's possible that there is a bug in jCIFS but you would need to
>provide more information about the steps necessary to reproduce.

I just noticed a _possible_ bug in jcifs today that may be related here.  In the constructor for SmbComSessionSetupAndX, a compare is done to see if the auth challenge matches the server encryption key:

	if( auth.hashesExternal && auth.challenge != session.transport.server.encryptionKey )

The challenge/encryption key, however, is a byte[].  I assume that it is only required that the contents of the byte[] match and not that the two actually refer to the same object.  It appears that it would make more sense here to use !Arrays.equals(auth.challenge, session.transport.server.encryptionKey) instead of the != operator.

Do the challenge and encryption key really need to refer to the same byte[] object, or is it sufficient that the contents of the byte[] match?

Kevin Tapperson


More information about the jcifs mailing list