[cifs-protocol] [REG:119072621001605] [MS-SMB2] 184.108.40.206.4 SMB2_NETNAME_NEGOTIATE_CONTEXT_ID
edgaro at microsoft.com
Fri Jul 26 21:35:26 UTC 2019
After reviewing the source code, I logged a document bug against [MS-SMB2]. This should be addressed in a future release of the spec.
This context is not used or processed by the server but it's important that it's correct. It may be used by load balancers, etc.
Thank you for bringing this to our attention.
From: Bryan Burgin <bburgin at microsoft.com>
Sent: Friday, July 26, 2019 12:12 PM
To: Stefan Metzmacher <metze at samba.org>; cifs-protocol at lists.samba.org
Cc: support <support at mail.support.microsoft.com>
Subject: [REG:119072621001605] [MS-SMB2] 220.127.116.11.4 SMB2_NETNAME_NEGOTIATE_CONTEXT_ID
[Dochelp to bcc]
Thank you for your question. We created SR 119072621001605 to track this issue. An engineer will contact you soon.
From: Stefan Metzmacher <metze at samba.org>
Sent: Friday, July 26, 2019 1:23 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>; cifs-protocol at lists.samba.org
Subject: [MS-SMB2] 18.104.22.168.4 SMB2_NETNAME_NEGOTIATE_CONTEXT_ID
I just noticed a documentation bug in
[MS-SMB2] 22.214.171.124.4 SMB2_NETNAME_NEGOTIATE_CONTEXT_ID:
NetName (variable): A null-terminated Unicode string containing the
server name and specified by the client application.
Windows Server 1903 sends the name without null-termination, see the attached capture.
I just contacted dochelp for this and noticed (from reading the code) that the kernel sends null-termination for the SMB2_NETNAME_NEGOTIATE_CONTEXT_ID value.
I think you should fix that and backport it to stable releases, it would be good if all clients would implement it like windows.
I implemented it for Samba here:
More information about the cifs-protocol