[jcifs] VC Number = 0 from XP but not 2003

[Brian Bowley]

Thank you, gentlemen, for your detailed responses. The KB item you mentioned is the same one I found that helped in my situation and is the best solution I've found. Below is what I have found from the testing I have done.

All of test results below were performed against a Windows Server 2008 share. The server implementation will affect the results as it may act differently for VC=0. For example, according to the Samba smb.conf documentation, "reset on zero vc" can be configured to either reset other connections on VC=0 or not.

Now for my test results on various platforms against the same Windows Server 2008 share:

===== Windows 7 and Windows Vista =====
Windows 7 and Windows Vista appear to be using SMB2 protocol. Even though the Windows OS is sending a VC number of zero, it did not affect (did not reset) the JCIFS connection.

===== Windows XP Professional =====
Accessing the shared drive outside of JCIFS caused Windows XP to create its own connection to the server. It used the SMB protocol and sent a VC=0 when it made the connection. This reset all other SMB connections from the same PC (including JCIFS).

There are two client system modifications I have found that helped with this issue:
1)	Add SmbDeviceEnabled to the registry and set it to 0. (See http://support.microsoft.com/kb/301673). This I have done on the XP client. I have tried this registry setting on the Windows 2008 Server PC but it had no effect.
2)	In the Properties window of the appropriate network connection, disable (uncheck) the "Client for Microsoft Windows". This will keep all users from using any network shares through the operating system. JCIFS connections still work fine.

===== Suse Linux 10 and Red Hat 5 =====
When I used "smbclient" to access a share, it used VC=1 which does not cause any issues with JCIFS.

Using any of the following commands sent a VC=0 which reset the other connections:
mount.cifs ...
mount -t smbfs ... (was not available on RH5)
mount -t cifs ...
Using any of these mount commands, it disconnected JCIFS at the time of the mount. After a period (15 minutes) of inactivity of the mounted drive, the connection was closed. If I re-accessed the mounted drive, it then automatically reconnected with VC=0 and disconnected JCIFS. The only way I found on the internet to correct this is to modify the source for the kernel to always send a VC=1. I did not test this.


Brian Bowley | Senior Software Engineer
Cleo Communications | bbowley at cleo.com | www.cleo.com

CLEO - Helping Move Your Business Forward
Find out how we are helping more than 30,000 customers Secure, Manage and Integrate data and documents.

-----Original Message-----
From: Christopher R. Hertel [mailto:crh at ubiqx.mn.org] 
Sent: Tuesday, September 07, 2010 9:48 PM
To: Michael B Allen
Cc: Brian Bowley; jcifs at lists.samba.org
Subject: Re: [jcifs] VC Number = 0 from XP but not 2003

Ouch.  The old VC=0 bug.

Windows servers still reset the connection if the client sends a
SessionSetupAndX with a VC number of zero.  This is due to an ancient
transport (supported by OS/2 and early NT systems) known as "Direct Hosted
IPX" that allowed multiple modem links to be combined into a single "virtual
circuit".  The idea was that each modem link would have a different VC
number, but they'd all be part of the same "session".

The problem was that if the client went down, there was no way for the
server to figure it out, so the client would send VC=0 as the "first"
connection when reconnecting and that would signal the server that all of
the old connections needed to be closed.

Microsoft has a KB article that explains what happens when multiple clients
attempt to connect from behind a NAT.

See:  http://support.microsoft.com/default.aspx?scid=KB;en-us;301673

Note the details, in the article.  This problem is supposed to be fixed for
NBT transport, but not for what I call Naked TCP transport.

Microsoft uses the term "Direct Hosting" to mean "without the NetBIOS
layer".  So what I call SMB over Naked TCP transport is known in Microsoft
circles as Direct Hosted TCP (or Direct Hosting, because they forgot they'd
done it for other transports).

If the connection is using port 445, the KB article would suggest that they
don't have a fix.

NOTE:  I will be at the SNIA CIFS Plugfest in less than two weeks, talking
with the Microsoft folks.  If this is packaged correctly, I can discuss it
with them.

Chris -)-----

Michael B Allen wrote:
> Hi Brian,
> 
> I have confirmed your diagnosis. Frame 458 is not as interesting
> because even though there is an RST from the server, it is immediately
> preceeded by an SMB_COM_FIND_CLOSE2. But frame 5656 is an
> SMB_COM_NT_CREATE_ANDX request that clearly gets cut off by an RST
> from the server immediately after the SMB_COM_SESSION_SETUP_ANDX with
> VC Number = 0 from the XP machine hosting JCIFS.
> 
> I have just tried an XP install I have here and it also uses VC Number
> = 0. However, a Windows 2003 Server I have uses VC Number = 0 for
> connecting to IPC$ but it uses VC Number = 1 for connecting to a
> conventional share (or maybe it's 1 because it's an additional session
> - the session on IPC$ was on the same socket).
> 
> So I definitively confirm your diagnosis: The session setup from XP is
> clearly cutting off the JCIFS transport.
> 
> Unfortunately I do not have a good solution for you. I don't know if
> there's even a way to change this behavior of Windows. Do you know
> Chris?
> 
> Mike
> 

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
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
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org