Re: Fwd: mount.cifs fails but smbclient succeeds

[Steve French <smfrench@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6064 bytes --]

Here is a patch to try


On Thu, Jul 25, 2019 at 3:59 PM Wout Mertens <wout.mertens@gmail.com> wrote:
>
> Thanks! I'll give that a try and let you know.
>
> Wout.
>
> On Thu, Jul 25, 2019 at 8:51 PM Steve French <smfrench@gmail.com> wrote:
> >
> > To clarify the differences you see:
> > 1) on the smb2 session setup requests you see the working client
> > (smbclient) setting the SMB2_FLAGS_PRIORITY flags (this shouldn't make
> > any difference because it is SMB3.1.1 specific flag unless the server
> > negotiated smb3.1.1)
> > 2) you see CAP_DFS (0x00000001) not CAP_EXTENDED_SECURITY (0x80000000)
> > set on the Capabilities field of the session setup response (the
> > negotiate protocol request if you specify vers=3 or vers=3.1 or
> > vers=3.1.1 or vers=3.0 should show these capabilities set on the
> > negotiate protocol request:
> >
> > SMB2_GLOBAL_CAP_DFS | SMB2_GLOBAL_CAP_LEASING |
> > SMB2_GLOBAL_CAP_LARGE_MTU | SMB2_GLOBAL_CAP_PERSISTENT_HANDLES |
> > SMB2_GLOBAL_CAP_ENCRYPTION | SMB2_GLOBAL_CAP_DIRECTORY_LEASING
> >
> > Would also be interesting to see if the signing required difference is related.
> >
> > I could give you a patch that forces the Capabilities field to include
> > more flags on session setup - it is easy enough to change the line
> > (round line 1181 of smb2pdu.c) - see SMB2_sess_alloc_buffer
> >
> > req->Capabilities = 0;
> >
> > to req_capabilities = SMB2_GLOBAL_CAP_DFS;
> >
> > On Thu, Jul 25, 2019 at 9:12 AM Wout Mertens <wout.mertens@gmail.com> wrote:
> > >
> > > Thank you so much Aurélien, smbcmp was really helpful!
> > >
> > > Is there a way to force mount.cifs to use DFS? (cifs-utils 6.8, kernel 4.19.57)
> > >
> > > It turns out that when smbclient connects, it sends that it supports
> > > DFS, but mount.cifs sends that it does NOT support DFS. Then smbclient
> > > connects to the host and figures out the correct server to talk to,
> > > and connects as needed, but mount.cifs just fails to do that.
> > >
> > > What I did was to sniff the smbclient traffic for the server that has
> > > the path I wanted, and then mount that directly using mount.cifs. That
> > > works, but I'm worried that if they move things around it will break
> > > again, or maybe they'll split the mount in two servers.
> > >
> > > Here's the comparison: (-: smbclient, +: mount.cifs)
> > > ======
> > > smbclient first  has an extra "Negotiate Protocol Request" + Response,
> > > which the mount.cifs doesn't do. Then there's a common "Negotiate
> > > Protocol Request" + Response,
> > > > Session Setup Request, NTLMSSP_NEGOTIATE  (same with the subsequent NTLMSSP_AUTH)
> > >          Server Component: SMB2
> > >      SMB2Header Length: 64
> > > -        Credit Charge: 1
> > > +        Credit Charge: 0
> > >          Channel Sequence: 0
> > >          Reserved: 0000
> > >          Command: Session Setup (1)
> > > -        Credits requested: 8192
> > > -        Flags: 0x00000010, Priority
> > > +        Credits requested: 130
> > > +        Flags: 0x00000000
> > >              .... .... .... .... .... .... .... ...0 = Response: This
> > > is a REQUEST
> > >              .... .... .... .... .... .... .... ..0. = Async command:
> > > This is a SYNC command
> > >              .... .... .... .... .... .... .... .0.. = Chained: This
> > > pdu is NOT a chained command
> > >              .... .... .... .... .... .... .... 0... = Signing: This
> > > pdu is NOT signed
> > > -            .... .... .... .... .... .... .001 .... = Priority: This
> > > pdu contains a PRIORITY
> > > +            .... .... .... .... .... .... .000 .... = Priority: This
> > > pdu does NOT contain a PRIORITY
> > >              ...0 .... .... .... .... .... .... .... = DFS operation:
> > > This is a normal operation
> > >              ..0. .... .... .... .... .... .... .... = Replay
> > > operation: This is NOT a replay operation
> > >          Chain Offset: 0x00000000
> > > -        Message ID: Unknown (2)
> > > -        Process Id: 0x00000000
> > > +        Message ID: Unknown (1)
> > > +        Process Id: 0x000040fc
> > > [...]
> > > -        Security mode: 0x01, Signing enabled
> > > -            .... ...1 = Signing enabled: True
> > > -            .... ..0. = Signing required: False
> > > -        Capabilities: 0x00000001, DFS
> > > -            .... .... .... .... .... .... .... ...1 = DFS: This host
> > > supports DFS
> > > +        Security mode: 0x02, Signing required
> > > +            .... ...0 = Signing enabled: False
> > > +            .... ..1. = Signing required: True
> > > +        Capabilities: 0x00000000
> > > +            .... .... .... .... .... .... .... ...0 = DFS: This host
> > > does NOT support DFS
> > >
> > > After that, they both do
> > >
> > > > Session Setup Response
> > > > Tree Connect Request Tree: \\corp.local\IPC$
> > > > Tree Connect Response
> > >
> > > and then smclient does
> > > > Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \corp.local\ib
> > > but mount.cifs does
> > > > Ioctl Request FSCTL_VALIDATE_NEGOTIATE_INFO
> > > ======
> > >
> > > I saw that there were fixes in 5.0 regarding crediting and DFS
> > > reconnect, would they make a difference?
> > >
> > > Wout.
> > >
> > > On Tue, Jul 9, 2019 at 9:38 AM Aurélien Aptel <aaptel@suse.com> wrote:
> > > >
> > > > "Wout Mertens" <wout.mertens@gmail.com> writes:
> > > > > Any suggestions? This is driving me crazy :-/
> > > >
> > > > If you make a network capture of smbclient connecting and a capture of
> > > > mount.cifs failing you can use smbcmp [1] to compare them.
> > > >
> > > > https://github.com/aaptel/smbcmp
> > > >
> > > > --
> > > > Aurélien Aptel / SUSE Labs Samba Team
> > > > GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
> > > > SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> > > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
> >
> >
> >
> > --
> > Thanks,
> >
> > Steve



-- 
Thanks,

Steve

[-- Attachment #2: 0001-smb3-send-CAP_DFS-capability-during-session-setup.patch --]
[-- Type: text/x-patch, Size: 1118 bytes --]

From 182c806c3d96adf57c32842178db06e44b46d247 Mon Sep 17 00:00:00 2001
From: Steve French <stfrench@microsoft.com>
Date: Thu, 25 Jul 2019 18:13:10 -0500
Subject: [PATCH] smb3: send CAP_DFS capability during session setup

We had a report of a server which did not do a DFS referral
because the session setup Capabilities field was set to 0
(unlike negotiate protocol where we set CAP_DFS).  Better to
send it session setup in the capabilities as well (this also
more closely matches Windows client behavior).

Signed-off-by: Steve French <stfrench@microsoft.com>
---
 fs/cifs/smb2pdu.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 53f889783e59..ee5d74988a9f 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1196,7 +1196,12 @@ SMB2_sess_alloc_buffer(struct SMB2_sess_data *sess_data)
 	else
 		req->SecurityMode = 0;
 
+#ifdef CONFIG_CIFS_DFS_UPCALL
+	req->Capabilities = cpu_to_le32(SMB2_GLOBAL_CAP_DFS);
+#else
 	req->Capabilities = 0;
+#endif /* DFS_UPCALL */
+
 	req->Channel = 0; /* MBZ */
 
 	sess_data->iov[0].iov_base = (char *)req;
-- 
2.20.1