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

[Kevin Tapperson]

Michael B Allen <mba2000 <at> ioplex.com> writes:

> 
> Tapperson Kevin said:
> >>> 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.
> <snip>
> > Do the challenge and encryption key really need to refer to the same
> > byte[] object
> 
> Yes.

Ok, thanks for the reply Mike.  I went back and re-evaluated the code in 
SmbTransport and SmbSession, and it makes more sense now.

We have been getting the "Invalid access to memory location" exception 
intermittently, and I have finally tracked down why.  Here is the sequence of 
events that can cause the exception to be thrown:

let's start with an NTLM type 1 message from a client browser...
1) client sends NTLM type 1
2) jcifs creates a new SmbTransport (transportA) to the domain controller (DC)
3) jcifs replies with the NTLM type 2 message (using the encryption key from 
transportA)
4) client sends NTLM type 3
5) jcifs creates a new SmbSession (sessionA) over transportA
6) jcifs performs the logon via sessionA over transportA
7) app server returns the page to the client (everything's good)
.
. (some time elapses; let's say about (jcifs.smb.client.soTimeout - 200) ms)
.
8) client sends an NTLM type 1 message (could be a different client; doesn't 
really matter)
9) jcifs re-uses the existing SmbTransport (transportA) to the DC
10) jcifs replies with the NTLM type 2 message (using the encryption key from 
transportA)
11) jcifs.smb.client.soTimeout has been reached for transportA - the transport 
socket is closed
12) client sends NTLM type 3
13) jcifs creates a new SmbTransport (transportB) to the DC
14) jcifs creates a new SmbSession (sessionB) over transportB
15) jcifs attempts to setup the session and do the logon via sessionB over 
transportB; this fails because the challenge the client is using was generated 
on transportA and doesn't match the encryption key for transportB


So, it looks like there is a failure window here.  If the transport socket 
times out after the type 2 message has been sent by jcifs, but before the type 
3 message has been received and the logon finished, then it will result in 
the "Invalid access to memory location" exception.

Is there a way to send a "keep alive" message over the transportA socket when 
its encryption key is being used as a challenge (between steps 9-10 above)?  
Some sort of no-op SMB message to keep the socket open?  This would keep the 
transportA socket open and allow the client up to jcifs.smb.client.soTimeout ms 
to respond with a type 3 message.  As the case is now, it doesn't really matter 
how fast the client is in responding with the type 3 message, it is simply dumb 
luck if the client hits the window where the socket could be closed and cause 
this failure.

I suppose that setting a higher value for jcifs.smb.client.soTimeout could 
potentially help this problem, as long as the app server is processing at least 
one type 3 message (and SMB logon) every jcifs.smb.client.soTimeout ms.  If 
this were the case, it would essentially keep the transport socket open 
forever.  However, any time a transport socket is closed, there is the 
possibility for failure.

Kevin Tapperson