Here is a patch to try On Thu, Jul 25, 2019 at 3:59 PM Wout Mertens wrote: > > Thanks! I'll give that a try and let you know. > > Wout. > > On Thu, Jul 25, 2019 at 8:51 PM Steve French 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 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 wrote: > > > > > > > > "Wout Mertens" 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