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@xxxxxxxxx> 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@xxxxxxxx> wrote: > > > > "Wout Mertens" <wout.mertens@xxxxxxxxx> 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
