I'm currently adding the support to do: smbclient //server/share -mSMB2 and have it work. I have connections and opening/closing/deleting files and directories working. Still finishing up directory listing and read/write. Will attach the patchset here for 4.1 once I'm done. Jeremy.
Created attachment 9014 [details] initial git-am patch for 4.1.x Not asking for review, this is a big blob of a patch that I'll break up into reviewable patches. Just parking it here so I don't lose it :-). Jeremy.
FYI. I've almost finished my splitting up of this patch into micro-commits. Should be ready for review by Monday. Jeremy.
Created attachment 9123 [details] git-am fix for master and 4.1.0 Here's the "official" patchset, broken up for 4.1.x and master. Works well (as far as my testing goes). Significantly improves read speeds. I'll propose for master now. Jeremy.
Created attachment 9135 [details] git-am fix for 4.1.0. Will upload final version that went into master once that's done. Jeremy.
Created attachment 9136 [details] Patches for v4-1-test Jeremy, please also provide documentation updates for the release...
Created attachment 9139 [details] git-am fix for 4.1.0 Submitted to master (storing here so I don't lose it :-). This patchset adds support for --encrypt, or -e command line options to smbclient and smbcacls when SMB3 protocol is requested using -mSMB3. It also adds a new "timeout" command and -t option to smbclient to set the per-operation timeout. This is needed as once SMB3 encryption is selected the server response time can be very slow when requesting large numbers (256) of large encrypted packets (1MB) from a Windows 2012 virtual machine. This allows a user to tune their allowable wait time. Also contains documentation updates for the changes made to complete SMB2+ support in our client tools. Please review and push if you're happy. Cheers, Jeremy.
(In reply to comment #5) > Created attachment 9136 [details] > Patches for v4-1-test > > Jeremy, please also provide documentation updates for the release... Good point! Documentation updates are needed for 4.1.0.
Setting Product to Samba 4.1 (instead of 4.0).
While this is great stuff, indeed, it this new feature really for 4.1 so short before the release...
Yes :-). This feature has been in development for a while, plus I explicitly pointed out (before freeze) this is something we need in 4.1. OEMs are running into environments with *NO* SMB enabled. We must have working SMB2+ client tools for 4.1.0. Jeremy.
Created attachment 9148 [details] Complete (jumbo) patchset git-am format for 4.1.0. Here is the jumbo patchset - containing the patches reviewed by Metze and myself, the additional patch created by Volker to fix the fnum == -1 Coverity problem, and finally the ability to encrypt smbclient SMB3 traffic using the -e flag and the documentation updates. Once the final part of the patchset (the -e and docs updates) are reviewed and pushed into master this should be the complete patch set for 4.1.0. Jeremy.
*** Bug 9829 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > Created attachment 9148 [details] > Complete (jumbo) patchset git-am format for 4.1.0. > > Here is the jumbo patchset - containing the patches reviewed by Metze and > myself, the additional patch created by Volker to fix the fnum == -1 Coverity > problem, and finally the ability to encrypt smbclient SMB3 traffic using the -e > flag and the documentation updates. > > Once the final part of the patchset (the -e and docs updates) are reviewed and > pushed into master this should be the complete patch set for 4.1.0. > > Jeremy. Should we ship another release candidate containing this patchset?
(In reply to comment #10) > Yes :-). This feature has been in development for a while, plus I explicitly > pointed out (before freeze) this is something we need in 4.1. > > OEMs are running into environments with *NO* SMB enabled. We must have working > SMB2+ client tools for 4.1.0. While I still don't buy the argument (why should OEMs have *NO* SMB support when smbclient can't do SMB2? and why was this not a problem for 4.0?) and we are violating many of our release policies, I won't object the addition, because luckily the impact on the server code is minimal. :-) I looked at the patchset, and it generally looks good. I will do more tests, but at least the last part (encryption via "-e" still needs to go through master. Stay tuned...
1). Yes, I think shipping another release candidate is a good idea. 2). OEMs are finding there are customer environments with SMB1 disabled, only SMB2+ allowed. This isn't a problem for Samba server-only OEMs, but there are other OEMs (I can name them privately) who depend on the client tools. They also need working cross-compiling (but that's another argument :-). 3). I don't think we're violating release policies. Back in July I raised the case that this was required for a 4.1.0 release. Everyone ignored me of course, but I did request this :-). 2). This provides additional functionality we really need for a good 4.1 release announcement (otherwise we don't have much to announce :-). I'm happy for this to go in via master first of course, then I'll update the patchset with the "cherry-picked-from" meta-data for the 4.1.0 patchset. Cheers, Jeremy.
One more thing in support of this patchset for 4.1.0.. I really want to enable -e encryption for SMB3 connections from out client tools. In the current climate the only rational response is encrypt *everything*. Let's make that possible for our users ! Jeremy.
(In reply to comment #16) > One more thing in support of this patchset for 4.1.0.. > > I really want to enable -e encryption for SMB3 connections from out client > tools. In the current climate the only rational response is encrypt > *everything*. Let's make that possible for our users ! Make that default if the server supports it? :-) Volker
I don't think we're quite at the place where we can encrypt by default (yet:-). Jeremy.
(In reply to comment #18) > I don't think we're quite at the place where we can encrypt by default (yet:-). Why not?
(a) Because it really affects our default speed. (b) Because it means a bunch of code/docs changes to negate the -e option. Jeremy.
Created attachment 9159 [details] git-am fix for 4.1.0. Ok, here's the complete patchset cherry-picked from master. Applies cleanly to 4.1.0. Jeremy.
Obnox, how long will it approximately take to review the latest patchset? Does it make sense to add alternative reviewers in this case?
Comment on attachment 9159 [details] git-am fix for 4.1.0. Looks good to me for 4.1
Comment on attachment 9159 [details] git-am fix for 4.1.0. OK.
Karolin, please pick for 4.1
(In reply to comment #25) > Karolin, please pick for 4.1 Pushed to autobuild-v4-1-test.
Pushed to v4-1-test. Closing out bug report. Thanks!