Re: Fwd: mount.cifs fails but smbclient succeeds

[Wout Mertens <wout.mertens@gmail.com>]

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