[PATCH] Add -e encryption support to SMB3 client protocol support, plus documentation updates.

[Michael Adam]

On 2013-08-20 at 08:58 -0700, Jeremy Allison wrote:
> On Tue, Aug 20, 2013 at 03:21:39PM +0200, Michael Adam wrote:
> > I am currently reviewing the patchset.
> > And it looks good.
> > 
> > I am only wondering about the (sneaked in) change for thei
> > iosize command:
> 
> It's not sneaked in :-).

I was referring to the fact that the commit message just
mentions the removal of the limitation for SMB2. But that
there is also a change for SMB1 included is not mentioned..

In reviewing, I updated the commit message accordingly.

> It's a change
> that metze made in the patchset that
> has already gone in, this change just
> updates the smbclient command and the
> manpage to match the internal functionality.

Ok, got you.

> > Originally 0x400 -- 0xFFFF00 was allowed.
> > Now suddenly 0 -- 0xFFFF00 is allowed.
> > with 0 meaning server controlled.
> 
> That's the way that the internal read/write
> code now works.
> 
> > Can it be that any x with 0 < x < 0x400
> > is mapped to 0x400 (the original minimum)
> > implicitly?
> 
> Well there's no harm in setting iosize to
> 1, it'll just be very inefficient. So I
> didn't see the need to restrict that.

It seems to me from looking at captures that
with SMB1, I always get 0x4000 byte writes
and 0xFC00 reads, irrespective of the iosize
setting, but more parallelised when using a
higher value or 0.
(Observed running a thus patched smbclient
against a plain w2k8r2.)

Also using SMB2+, I don't see different write
or read lengths when using other values than 0,
but different parallelism. Am I asking stupid
questions?...

> > And in the manpage, only the SMB1 limit
> > is described, not the (lack of) limit in
> > the SMB2+ case.
> 
> Well setting iosize = 0xFFFF00 (16Mb minus
> a bit) is an SMB1 limit, but to really get
> the (unlimited) SMB2 size you really need
> to set it to zero and let the credit handling
> take care of it.

But you can still set it to a positive value
bigger than 0xFFFF00 for SMB2+ and with a
different effect than setting 0xFFFF00, right?


OK, because the problems I mentioned above
are rather in the preliminary lower level patches
than in the present patchset itself, I review+
the patches and am bringing them to autobuild!

Attached find a follow-up patch that adds a
missing newline to the error messages for
out of bounds iosize value (they were missing
before your patch already, hence the proposed
extra commit).

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-client-add-missing-newlines-to-error-messages-for-in.patch
Type: text/x-diff
Size: 1034 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20130821/1ab84c73/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 215 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20130821/1ab84c73/attachment.pgp>