From allen@ALPHA.NCSL.NIST.GOV Sun Jan 18 20:52:59 1998 Date: Fri, 16 Jan 1998 08:49:12 -0500 Reply-To: Common Internet File System Subject: Re: virtual circuits (was Re: new CIFS I-D) Andrew wrote: >There are some real problems with that doc as it stands. I don't think >it matches current implementations (I'm thinking in particular of the >MS servers). In my opinion theres a lot of problem with most of the docs as the they stand! >> No. If specifying a non-zero VcNumber they must also specify ?> a Session Key proffered in a preceding negotiate response. What they >> are saying is I already have one or more open connections for >> session and I want to add this one to it. >What surprises me about this is it would mean that smbclient wouldn't >work, but it does! smbclient always sends a non-zero VcNum but there >is no communication between different smbclient processes (which may >be running as totally different users). Yes the session setup works. It probably shouldn't by rule as stated in Lanman 1. >smbclient sends the session key that was returned by the negprot >response on the same socket (usually the immediately preceding >packet). I just tried to dump smbclient's exchange with NT4/SP3 and didn't get the session key dumped. It did dump MaxVcs however and that is zero. So you are allowed no virtual circuits ;-) Shall we take the interpretation that this means you are allowed no ADDITIONAL virtual circuits? It also would seem to indicate that NT atleast doesn't support "additional" VC's. >If I understand you right then you are saying that clients can only >use VcNumber!=0 if they already have a VcNumber==0 socket setup and >know the session key from that socket. Have I understood? Yes but let me modify my initial analysis slightly to correct a possible counting problem. If you go back to my original post you'll notice I kept specifying MaxVcs-1 as the maximum VcNumber. Assume that the limit is really MaxVcs (too much C training ;-) Setting VcNumber!=0 is defined to mean you are adding this circuit to the session identified by SessionKey. If in fact it is the circuit on which SessionKey was originally proffered and it is the first SS&X sent on the circuit, responding with VcNumber=1 simply confirms this circuit as the first circuit in the session. We now have session with one circuit. Seems OK to me. How about you? >If I have understood you then the fact that smbclient works seems to >show that this isn't right. That doesn't mean it isn't in the spec >though! Using the logic as modified above smbclient is dead on in its behavior as is the server. >> Now, about that nasty dissolution sentence. If your interpretation is >> taken, things get ugly. On your Unix system, all CIFS processes running on >> the Unix box are at the mercy of any twit that wants to blast SS&X SMB's >> with VcNumber=0 to all your CIFS servers. Without a "redirector" to >> control SS&X on a system wide basis this dissolution rule leaks badly. >indeed! Samba is not vulnerable because it doesn't actually drop >sessions based on VcNumber (in fact, the Samba server ignores the >VcNumber field entirely). No, but by your report NT does and this thread started in response to comments from other server developers implementing such a recovery. Not good, not good at all! >What I've been trying to say in this thread (and I'll be the first to >admit that it hasn't been the clearest thread this list has had!) is >that those servers that do implement the "drop other sessions when >they get a new connect" type of mechanisms need to do it carefully or >they risk causing havoc with embedded and user-space clients. Yes, and the mechanism NT is using isn't it. Works fine for W95 and WNT clients but not in general. On final question. Assuming all I have said stands muster, does the possibility of a server supporting sessions with multiple VC's have merit and should it be retained in the spec? I've been hacking a client API and went to extra effort to accomodate sessions with multiple VC's. I only briefly glanced at the SMBLIB code included in a newer release of SAMBA but I beleive it does so also. Dan From hawleyr@NETAPP.COM Sun Jan 18 20:50:20 1998 Date: Fri, 16 Jan 1998 07:52:47 -0800 From: Rob Hawley Reply-To: Common Internet File System To: CIFS@DISCUSS.MICROSOFT.COM Subject: Re: new CIFS I-D As I said in earlier message it depends what variant of the protocol you implement. If you implement the Win95 set and WinDD is SP5, then it will actually issue different sessions from the same station each with VC=0. In Feb last year we looked like Win95. We started receiving weird reports of file open problems. When we looked at the line trace what was happening was that one client would open a session and then open files. A second client would come along creating a new session with vc=0 and blow away the first guy's session. The solution was to treat vc=0 as an indication that we should start issuing Keep Alives. Once we did that everything was cool. Our currently shipping release implements the NT SMBs. That changes the WinDD behavior so that it now creates a single session and multiplexes multiple users over it. Mumble about whether that is a good idea or not, but that's how it works. I agree with Andrew that the whole discussion of VCs is inadequate. The VC indication is only meaningful as a flag to indicate whether the client believes this is the only open session. As far as I can tell the only meaningful numbers are 0 and non-zero. If you chose you can ignore the vcs and just issue Keep Alives anytime you suspect that there is the possibility of a duplicate. All implementations have to be prepared to accept multiple SessX on a single TCP session. If you don't happen to have WinDD or one of its cousins AND you implement the NT SMBs, then a fair simulation of WinDD is to create multiple users on the same NT system using the reskit tool SU. -----Original Message----- From: Andrew Tridgell Sent: Thursday, January 15, 1998 2:50 PM To: CIFS@discuss.microsoft.com Subject: Re: new CIFS I-D Rob wrote: > Actually an NT derivative product WinDD (aka WinCenter, etc) will > try to open a new vc for each user. does it? I don't have WinDD but from all the reports I've seen from Samba users that do it just uses multiple session setups. It uses only one socket. In fact, we had to fix a bug in Samba to handle the way it uses multiple session setups. We'd misunderstood/misimplemented the vuid stuff in SMB. It was a while ago, but I'm sure that WinDD used a single virtual circuit. Hmmm, I suspect we have a nomenclature problem here. A virtual circuit in my understanding is basically a TCP socket. Maybe other people call a virtual circuit a session setup defined security context? Cheers, Andrew From hawleyr@netapp.com Mon Jan 19 18:13:57 1998 Date: Mon, 19 Jan 1998 09:17:28 -0800 From: Rob Hawley To: 'Luke Kenneth Casson Leighton' Subject: RE: new CIFS I-D Yes the whole notion of VCs is a very bad abstraction. Really what is happening is that you need to support multiple SessX on the same session. The "VC number" is really used to speed recovery of dead sessions. Mumble about how you do that given the changes MS is proposing. What we will likely do is to go back to the scheme where we sent the equiv of a keep alive. This time we will probably have to force TCP to send it instead of using the NBT facility. Having said that then there is WinDD. They do not have a compliant implementation if you implement the Win95 subset. If folks do not implement the NT SMBs then they need to be aware of that.