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

[Christopher R. Hertel]

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