[PATCH] add suport for SMB3_10 and SMB3_11 protocols in smbstatus

[Michael Adam]

On 2015-09-02 at 15:52 +0000, Tom Talpey wrote:
> > -----Original Message-----
> > From: Stefan Metzmacher [mailto:metze at samba.org]
> > Sent: Wednesday, September 2, 2015 2:51 AM
> > To: Tom Talpey <ttalpey at microsoft.com>; Volker.Lendecke at SerNet.DE;
> > Ralph Wuerthner <ralphw at de.ibm.com>
> > Cc: Samba Technical <samba-technical at lists.samba.org>
> > Subject: Re: [PATCH] add suport for SMB3_10 and SMB3_11 protocols in
> > smbstatus
> > 
> > Hi Tom,
> > 
> > thanks for the suggestion!
> > 
> > > What exactly is "3_10"? There isn't such a dialect, the
> > > 3.1.1 version is the current and only 3.1.x. The previous
> > > SMB3's were 3.0 and 3.0.2.
> > 
> > That is 3.1.0 the dialect the preview versions of Windows 10 were using.
> > 
> > > I would strongly suggest using the canonical numbering conventions for
> > > reporting these. 2.0.2, 2.1, 3.0, 3.0.2 and 3.1.1.
> > 
> > If we do this we use use 2.0.2, 2.1.0, 3.0.0, 3.0.2 and 3.1.1, skipping
> > a trailing '0', is still confusion.
> 
> Well, Windows does not use the trailing .0's, as we have
> communicated previously.

Maybe it should. :-) It's just more systematic and exact.
Abbreviation by omission of trailing 0s in "colloquial language"
should of course still be allowed. ;-)

> I'd suggest not doing so in Samba, but it's your choice.

> > 
> > We can think about this for future versions of samba, but for now we
> > should be consistent
> > with the values used in smb.conf. And there we currently have:
> > 
> > static const struct enum_list enum_protocol[] = {
> >         {PROTOCOL_DEFAULT, "default"}, /* the caller decides what this
> > means */
> >         {PROTOCOL_SMB2_10, "SMB2"}, /* for now keep PROTOCOL_SMB2_10
> > */
> 
> This is a good choice - "SMB2" would therefore map to the
> version supported by Windows 7 and Windows Server 2008R2, which
> is the highest SMB2 dialect.
> 
> >         {PROTOCOL_SMB3_11, "SMB3"}, /* for now keep PROTOCOL_SMB3_11
> > */
> 
> Does this automatically enable dialects 3.0 and 3.0.2? If not,
> this choice will not interoperate for SMB3 with Windows 8,
> Windows Server 2012, Windows 8.1 and Windows Server 2012R2,
> because they do not support 3.1.1. If it does enable the lower
> dialects, then it's a good choice.

Yes. Our option controls the maximum offered smb version.
We can also configure the minimum version. All dialects between
these min and max versions are enabled (inclusive).

> >         {PROTOCOL_SMB3_11, "SMB3_11"},
> >         {PROTOCOL_SMB3_10, "SMB3_10"},
> 
> The 3.1 (3.1.0) protocol does not exist. It was used only in
> early Technical Previews of Windows 8.1, and these previews are
> now obsolete. Additionally, there are some bits in that dialect
> which were removed, as we discussed in SDC and SambaXP events.
> You should not be using these values.
> 
> >         {PROTOCOL_SMB3_02, "SMB3_02"},
> >         {PROTOCOL_SMB3_00, "SMB3_00"},
> >         {PROTOCOL_SMB2_24, "SMB2_24"},
> >         {PROTOCOL_SMB2_22, "SMB2_22"},
> 
> The 2.2.2 and 2.2.4 protocols also do not exist. These were
> used in the early previews of Windows 8, and were obsoleted
> when the dialect was officially assigned 3.0. These preview
> Windows betas are long-obsolete, and the dialects are entirely
> historical. No shipping product supports them.
> 
> >         {PROTOCOL_SMB2_10, "SMB2_10"},
> >         {PROTOCOL_SMB2_02, "SMB2_02"},
> >         {PROTOCOL_NT1, "NT1"},
> >         {PROTOCOL_LANMAN2, "LANMAN2"},
> >         {PROTOCOL_LANMAN1, "LANMAN1"},
> >         {PROTOCOL_CORE, "CORE"},
> >         {PROTOCOL_COREPLUS, "COREPLUS"},
> >         {PROTOCOL_COREPLUS, "CORE+"},
> >         {-1, NULL}
> > };
> > 
> > At least we need to support the current names as fallback in order
> > to avoid breaking existing configurations.
> 
> But, any configuration currently using 3_10, 2_22 or 2_24 is
> already broken since it will be rejected by any standard
> protocol compliant implementation.
> 
> > 
> > We can also think about removing all the preview dialects
> > ( SMB 2.2.2, 2.2.4 and 3.1.0).
> 
> As above, I believe they should be removed now.

Ok, thanks for the hints! We have traditionally kept these
intermediate dialects or protocol versions that were present
in previews and betas, and we had started the development of
our code against these.  It seemed the natural thing (and a
safe thing) for us to keep them.

In fact Metze and I just recently started discussing whether
to start removing the obsolete intermediate protocol versions.

I guess we'll provide some patches soon.

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150907/59b7dc7d/attachment.sig>