On 2/21/19 5:59 PM, Tom Talpey wrote:
The reconnect is apparently using a dotted-quad as the servername, and you can see the auth is forced to NTLM as a consequence. Is that the way you initially mounted the share (i.e. mount 10.71.217.50:/smbshare /mnt)?
-----Original Message-----
From: linux-cifs-owner@xxxxxxxxxxxxxxx <linux-cifs-owner@xxxxxxxxxxxxxxx> On Behalf Of Steve French
Sent: Thursday, February 21, 2019 9:07 AM
To: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
Cc: CIFS <linux-cifs@xxxxxxxxxxxxxxx>
Subject: Re: Failure to reconnect after cluster failvoer
Couple quick thoughts.
Does this work on current kernels (5.0 for example).
Was thinking about patches that might affect this like:
- "cifs: connect to servername instead of IP for IPC$ share"
- "smb3: on reconnect set PreviousSessionId field"
- Paulo's patches (has cifs-utils coreq) to reconnect to new IP
address if hostname's IP address changed and his add support for
failover
- Paulo's patch to remove trailing slashes from server UNC name
I've reproduced this with 5.0-rc7 and the latest cifs-utils from git.
The share was mounted as follows (yes, by IP):
mount.cifs -o
vers=3.0,cache=loose,actimeo=0,username=x,domain=y,password=z
'//10.71.217.31/smbshare' /mnt
Here is the tcpdump when it fails to reconnect properly:
http://s000.tinyupload.com/index.php?file_id=55518118986864684971
The initial connection is at timestamp 0s, reconnection at 13s,
STATUS_NETWORK_NAME_DELETED at 60s.
For comparison, here is a tcpdump using the "fix" from my previous mail:
http://s000.tinyupload.com/index.php?file_id=04243963024741599425
The initial connection is at timestamp 0s, reconnection at 34s,
successful read request at 215s.
Note that the tree connect for IPC$ only happens _after_ the tree
connect for the share succeeds.
Thanks,
--
Ross Lagerwall
