read/write multiplexed support

[Christopher R. Hertel]

>From your description, it seems that there is a lot going on.

Unfortunately, I don't personally know nearly enough about the OS/2
implementation of SMB.  I know that there is a good deal of documentation,
and from the captures you have provided it is clear that OS/2 supports many
features that other implementations do not.  Since I don't have experience
with the OS/2 implementation, I don't have a clear idea of how some of those
features work.

For example, Windows servers don't make use of most of the Timeout fields in
the LANMAN dialects.  Also, as I've already mentioned, Windows
implementations don't support MPX mode over connection-oriented transports.

I took a quick look through Leach/Naik.  The dialects prior to NT LM 0.12
provide bits that indicate RAW mode support in the NegProt response, but
nothing to indicate MPX support (or lack of it).  I think that the ability
to disable MPX support must have been added to NT.

Chris -)-----

Marcel Müller wrote:
> Christopher R. Hertel wrote:
>> It would also help to have the NegProt.  Since the dialect is prior to
>> NT LM
>> 0.12 we won't see capabilities bits, but we will see whether the Raw Mode
>> bits are set in the NegProt response.
> 
> I think you are right.
> 
> There are two scenarios.
> 1. The connection is slow from the beginning.
> 2. The connection is initially fast and slows down after a few hours.
> 
> In the second case there was always a timeout involved in some way. So I
> think we can forget about that, since the timeouts are only reproducible
> with a certain version of the IBM requester, which is not the most
> recent one.
> 
> But I conclude from that, that the speed (and the transfer protocol)
> does not change once the session is active.
> 
> But the first case is curious. I only have a vague guess. The disk in
> the server might be down at when the client connects in the first time.
> The spin up may take too long for some SMB request, again resulting in a
> timeout. Unfortunately I was not able to reproduce this by stopping the
> device explicitly with sdparm. But the data required at the session
> setup may still be in the cache, when the disk is down. Furthermore it
> is not that easy to do a tcp dump while the disk is down.
> 
> I now did some tweaks to the client configuration. In fact I disabled
> the multiplex modes in the wrkheuristics setting. This should at least
> force the differences between samba 3.0.x and samba 3.2.x to disappear.
> Since that, I was not able to reproduce the problem with samba 3.2.5
> with about 5 longer sessions. No Idea why. Maybe this happened only by
> chance. Maybe the client takes the raw and the multiplexed modes coequal
> and to disable one of them fixed it. This would also explain, why the
> communication with windows servers is always fast, because they never
> support both modes at once.
> 
> I will let you know if I have something new.
> As far as I see the solution will be in the surrounding of the
> negotiation, if any.
> 
> Btw, is it possible that the server still claims to support multiplexed
> modes at negotiation?
> 
> 
> Marcel

-- 
"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