Thanks! I'll give that a try and let you know. Wout. On Thu, Jul 25, 2019 at 8:51 PM Steve French <smfrench@xxxxxxxxx> 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@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
