Hi Paulo, > Hi Martijn, > > Martijn de Gouw <martijn.de.gouw@xxxxxxxxxxxxxxxxxxxxxxxxx> writes: > > Hi, > >> Martijn de Gouw <martijn.de.gouw@xxxxxxxxxxxxxxxxxxxxxxxxx> writes: >> >>> I tried kernel 5.4.6, including this fix, but still no luck: >>> [ 25.825075] CIFS: Attempting to mount //domain.com/common >>> [ 27.127925] CIFS VFS: BAD_NETWORK_NAME: \\domain.com\common >>> [ 31.406697] CIFS: Attempting to mount //DC01.domain.com/common/Pd_Std >>> [ 31.414527] srv rsp padded more than expected. Length 98 not 73 for cmd:1 mid:1 >>> [ 31.414533] Status code returned 0xc000006d STATUS_LOGON_FAILURE >>> [ 31.414537] CIFS VFS: \\DC01.domain.com Send error in SessSetup = -13 >>> [ 31.414544] CIFS VFS: cifs_mount failed w/return code = -13 >>> [ 31.414590] CIFS: Attempting to mount //DC01.domain.com/common/Pd_Std >>> [ 31.422410] Status code returned 0xc000006d STATUS_LOGON_FAILURE >>> [ 31.422416] CIFS VFS: \\DC01.domain.com Send error in SessSetup = -13 >>> [ 31.422423] CIFS VFS: cifs_mount failed w/return code = -13 >>> >>> Where 4.19 prints: >>> [ 132.012498] CIFS: Attempting to mount //domain.com/common >>> [ 132.183038] CIFS VFS: error -2 on ioctl to get interface list >>> [ 132.344343] CIFS: Attempting to mount //nas01/common$/pd_std >> >>> Thanks for testing it. >>> >>> Could you post dmesg output of both versions with debugging enabled as per >>> instructions in [1]? >> >> I attached the traces for kernel 4.19 and 5.4, I try to access the >> subdirectory after the '=====' separator in the log. I looks like in >> the past a different sesInfo was passed to cifs_get_spnego_key(). > >Thanks for the logs! > >I noticed that we're passing a wrong value for "ip=" down to cifs_mount(): > >[ 58.731307] fs/cifs/cifs_spnego.c: key description = ver=0x2;host=DC01.Prodrive.nl;ip4=10.1.1.6;sec=krb5;uid=0x2713;creduid=0x2713;user=mdg;pid=0x60b > >That is, > > 10.1.1.6 -> str02 > 10.1.1.14 -> DC01.Prodrive.nl > > which means that ip option should be set to 10.1.1.14. > > cifs_mount() will not attempt to resolve the hostname in case we have a > _valid_ ip address set in the mount options, so we end up connecting to > the wrong server (str02) and then failing to authenticate. > > Well, we could simply set "devname" to the resolved target (str02) and > we're done with it, but the problem with that is that it will break DFS > failover - that is, we will not be able to retry the other targets in > the referral in case we failed to connect it in cifs_mount(). > > I'm not entirely sure if that's the problem you're facing, but could you > please try below changes? I applied your patch to 5.4.6 and it seems to work. I attached the logs. Regards, Martijn
Attachment:
dfs-5.4.6-autofs-ippatch.log
Description: dfs-5.4.6-autofs-ippatch.log
