Re: Fwd: mount.cifs fails but smbclient succeeds

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

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)