linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paulo Alcantara <pc@cjr.nz>
To: Tom Talpey <tom@talpey.com>, Steven French <sfrench@samba.org>,
	Byron Stanoszek <gandalf@winds.org>,
	Shyam Prasad N <nspmangalore@gmail.com>
Cc: linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: CIFS regression mounting vers=1.0 NTLMSSP when hostname is too long
Date: Wed, 04 May 2022 17:58:54 -0300	[thread overview]
Message-ID: <87r15910c1.fsf@cjr.nz> (raw)
In-Reply-To: <df763cb0-83f2-35a5-a381-57cfd040becf@talpey.com>

Tom Talpey <tom@talpey.com> writes:

> I think the most conservative and spec-compliant choice should be made.
> SMB1 should not be pushing the envelope of interoperability, in this day
> and age.

OK.

> I believe the NetBIOS name is a fixed array of 16 octets, right? So, if
> the nodename is shorter, it needs to be padded with 0's.

Right.

> Did this code change recently? Why???

We used to not send the WorkstationName during NTLMSSP until recent
patch from Shyam:

	commit 49bd49f983b5026e4557d31c5d737d9657c4113e
	Author: Shyam Prasad N <sprasad@microsoft.com>
	Date:   Fri Nov 5 19:03:57 2021 +0000
	
	    cifs: send workstation name during ntlmssp session setup
	
	    During the ntlmssp session setup (authenticate phases)
	    send the client workstation info. This can make debugging easier on
	    servers.
	
	    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
	    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
	    Reviewed-by: Enzo Matsumiya <ematsumiya@suse.de>
	    Signed-off-by: Steve French <stfrench@microsoft.com>

Unfortunately some servers did not seem to enforce it to be 16 bytes
long, so the reason why we didn't catch it earlier.

Steve, Shyam, let me know if it does make sense to you and then I can
work on a patch to fix it properly.

  reply	other threads:[~2022-05-04 20:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-03 20:36 CIFS regression mounting vers=1.0 NTLMSSP when hostname is too long Byron Stanoszek
2022-05-04  1:35 ` Paulo Alcantara
2022-05-04  5:43   ` Steven French
2022-05-04 19:15     ` Paulo Alcantara
2022-05-04 20:18       ` Tom Talpey
2022-05-04 20:58         ` Paulo Alcantara [this message]
2022-05-06  2:03           ` Steve French
2022-05-06  2:19           ` ronnie sahlberg
2022-05-06 14:05             ` Paulo Alcantara
2022-05-04  7:13 ` Thorsten Leemhuis
2022-05-17 20:37 ` Paulo Alcantara
2022-05-22  4:40   ` Steven French
2022-05-23  2:32     ` Byron Stanoszek
2022-05-25  3:17   ` Byron Stanoszek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r15910c1.fsf@cjr.nz \
    --to=pc@cjr.nz \
    --cc=gandalf@winds.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nspmangalore@gmail.com \
    --cc=sfrench@samba.org \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).