[jcifs] Restoring connection after samba server restart

[Michael B Allen]

On Wed, Jul 27, 2011 at 11:29 AM, Dmytro Polivenok <polivenok at yandex.ua> wrote:
> Hi,
>
> We are experiencing issues with restoring connection after samba server restart. It is important for us and may be important to other people since we are using jCIFS from application on JBoss server and to recover connection we need to refresh connection somehow.
> We found that it is related to TID regeneration. TIDs are generated after server startup and on server restart all TIDs are regenerated. jCIFS caches TIDs and after server restart or shared folder recreation it is unable to access resource because uses old TIDs and doesn’t refreshes them.
>
>
>
> In SmbTree class in method void send(ServerMessageBlock request, ServerMessageBlock response)  at the end of the method there is following code:
>
>
>    try {
>
>        session.send(request, response);
>
>    } catch(SmbException se) {
>
>        if(se.getNtStatus() == se.NT_STATUS_NETWORK_NAME_DELETED) {
>
>            treeDisconnect(true);
>
>        }
>
>                throw se;
>
>    }
>
>
>
> Method treeDisconnect contains code related to removing old TIDs.
>
> When TID is invalid, NtStatus is equal to NT_STATUS_INVALID_PARAMETER.
>
>
> So I changed this code in the following way to refresh TID when it is invalid:
>
>
>
>    try {
>
>        session.send(request, response);
>
>    } catch(SmbException se) {
>
>        if(se.getNtStatus() == se.NT_STATUS_NETWORK_NAME_DELETED || se.getNtStatus() == se.NT_STATUS_INVALID_PARAMETER) {
>
>                        treeDisconnect(true);
>
>        }
>
>        throw se;
>
>    }
>
> What do you think about this?

Hi Dmytro,

JCIFS does not "cache" TIDs. A TID is a key that references a "tree"
(a mount of a share) so it just looks like something is being cached.
But if the server closes the socket to the client, JCIFS will rebuild
everything and it should recover just fine. I just tested this in the
last release actually (but with a Windows server). So I would argue
that if a "server restart" leaves the TCP connection open but
invalidates the TID on the server, that would be a bug in the server
and you should report the issue to whomever maintains that particular
server codebase.

However, the rules of behavior that JCIFS follows is that JCIFS should
do whatever the oldest supported version of Windows does (which as of
2011 would be Windows XP SP2). Meaning, if you can show that Windows
recovers gracefully from said error, we will fix it (or at least I
will add it to the TODO list to be fixed) in JCIFS.

So if you test Windows and find that handles this condition without a
problem, then please send me two packet captures:

  1) a capture of JCIFS failing as described above and
  2) a capture of Windows successfully recovering from the above
described condition.

Note that you should not post packet captures to the mailing list.
Please send them to me directly.

Also, please use a client that is NOT joined to the domain so that it
uses NTLM to authenticate and not Kerberos. Technically in this case
it should probably not make a difference but for the best possible
comparison you should make the client use NTLM. The ideal test would
be to use a Windows XP SP2 machine NOT joined to the domain, reboot
it, login using a local account, do Start > Run > cmd and then C:\>dir
\\path.fqdn.local\share and then enter the same credentials that you
used with JCIFS. This will result in a packet capture that should look
almost identical to running the examples/ListFiles.java example from
JCIFS and therefore will make a good comparison.

For getting a capture, look into netcap.exe from the Windows "Support
Tools" package or WireShark.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/