"SmbException: The parameter is incorrect" faced on all WD MyCloud recent products

[courville]

Trying to use latest jcifs-ng (59c3c0a) in my open-source android nova video player migrating from old jcifs-1.3.19 and got an unanimous feedback about problems with WD MyCloud NAS products resulting in a rollback.
Trying to get more logs and details through remote users is not the easiest. What I got is the following png adb logcat that shows SmbException: The parameter is incorrect.

Without any access to the device I will not be able to get more logs or wireshark captures.
Note that SMB2 is disabled by default in the app and can be activated via settings and thus with following config:

        prop.put("jcifs.smb.client.enableSMB2", "false");
        prop.put("jcifs.smb.client.useSMB2Negotiation", "false");
        prop.put("jcifs.smb.client.disableSMB1", "false");
        prop.put("jcifs.resolveOrder", "BCAST,DNS");
        prop.put("jcifs.smb.client.ipcSigningEnforced", "false");
        prop.put("jcifs.smb.client.disablePlainTextPasswords", "false");
        prop.put("jcifs.smb.client.dfs.disabled", "true");
        prop.put("jcifs.smb.client.disableSpnegoIntegrity", "false"); 

I am not sure it will help but, I guess it is worth opening an issue to track the problem.
I might acquire a such a device if you have no hint on the problem.

[mbechler]

Is this specifically linked to the most recent patches?

[courville]

I cannot tell since the previous alpha release was not deployed with enough large user base.
Current issue has been confirmed by at least 5 users with current git on a user base of 1500 beta users.

[mbechler]

Two options that come to mind and may be worth a try to figure out the cause:

• jcifs.smb.client.disableSpnegoIntegrity=true
• jcifs.smb.useRawNTLM=true

I would suspect that these are using samba servers, maybe one of your users can check the version, then I could test a matching version.

[courville]

In the open-source release of WD https://support-en.wd.com/app/products/product-detail/p/1369#WD_downloads, unpacking the release I see a samba-4.4.0 (GPL_MCH_6.6.1-123_20191114/ANDK/samba/samba-4.4.0). Not sure it matches current firmware version but recent enough OSS release (11/19/2019). I have not tried to seek for the config though.

[courville]

FYI I found the following smb.conf at root of the open-source release

[global]
security = user
null passwords = yes
guest account = guest
load printers = no
oplocks = no
public = yes
guest ok = yes
passdb backend = smbpasswd:/data/samba/etc/samba/smbpasswd
use sendfile = yes
strict locking = no
min receivefile size = 16384

[Public]
path = /data/samba/share
writable = yes
guest ok = yes

[mbechler]

I think I managed to reproduce the issue by testing some older samba versions. There seems to be a whole range of samba versions it tries to validate SPENGO and NTLM message intregrity (MICs) when a guest login is performed and then fails with INVALID_PARAMETER (this cannot work, as there is no valid session key): https://bugzilla.samba.org/show_bug.cgi?id=11847

While this clearly is a samba bug, there are a number of things we can do to avoid it and this probably deserves a mitigation, as it may be a somewhat common issue. I'll have to think about this a bit more.

In the meantime, setting jcifs.smb.client.disableSpnegoIntegrity=true should avoid the issue as well.

NT error packet at ../source3/smbd/sesssetup.c(263) cmd=115 (SMBsesssetupX) NT_STATUS_INVALID_PARAMETER
May 24 17:58:54 samba4 smbd[3626]: release lock order 1 for /usr/local/samba/var/lock/smbXsrv_session_global.tdb
May 24 17:58:54 samba4 smbd[3626]: check lock order 1 for /usr/local/samba/var/lock/smbXsrv_session_global.tdb
May 24 17:58:54 samba4 smbd[3626]: pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
May 24 17:58:54 samba4 smbd[3626]: SPNEGO login failed: NT_STATUS_INVALID_PARAMETER
May 24 17:58:54 samba4 smbd[3626]: GENSEC SPNEGO: failed to verify mechListMIC: NT_STATUS_INVALID_PARAMETER
May 24 17:58:54 samba4 smbd[3626]: server session key is invalid (len == 0), cannot do KEY_EXCH!
May 24 17:58:54 samba4 smbd[3626]: No such user GUEST [] - using guest account
May 24 17:58:54 samba4 smbd[3626]: Checking NTLMSSP password for \GUEST failed: NT_STATUS_NO_SUCH_USER
May 24 17:58:54 samba4 smbd[3626]: check_ntlm_password:  Authentication for user [GUEST] -> [GUEST] FAILED with error NT_STATUS_NO_SUCH_USER
May 24 17:58:54 samba4 smbd[3626]: check_ntlm_password: sam authentication for user [GUEST] FAILED with error NT_STATUS_NO_SUCH_USER
May 24 17:58:54 samba4 smbd[3626]: check_sam_security: Couldn't find user 'GUEST' in passdb.

[courville]

Thanks for following it through!
Regarding disableSpnegoIntegrity, I had to jcifs.smb.client.disableSpnegoIntegrity=false to make guest work on win10 (cf. #186) and reverting to true will cause some usage regressions...

[mbechler]

I have the feeling that I actually meant to suggest jcifs.smb.client.disableSpnegoIntegrity=true in #186. Maybe this was fixed by some other change.

[courville]

Ok thanks for the tip: I will check and report.

[courville]

Users have tested an experimental build of my application and report that jcifs.smb.client.disableSpnegoIntegrity=true fixes the "parameter is incorrect" issue when SMB2 is enabled but not when using SMB1 only.
For clarification sake here are the two configurations I use:

• SMB1

prop.put("jcifs.smb.client.disableSMB1", "false");
prop.put("jcifs.smb.client.enableSMB2", "false");
prop.put("jcifs.smb.client.useSMB2Negotiation", "false");
prop.put("jcifs.smb.client.ipcSigningEnforced", "false");
prop.put("jcifs.smb.client.disableSpnegoIntegrity", "true"); 
prop.put("jcifs.resolveOrder", "BCAST,DNS");
prop.put("jcifs.smb.client.disablePlainTextPasswords", "false");

• SMB2

prop.put("jcifs.smb.client.disableSMB1", "true");
prop.put("jcifs.smb.client.enableSMB2", "true");
prop.put("jcifs.smb.client.useSMB2Negotiation", "true");
prop.put("jcifs.smb.client.dfs.disabled", "true");
prop.put("jcifs.smb.client.disableSpnegoIntegrity", "true");
prop.put("jcifs.resolveOrder", "BCAST,DNS");
prop.put("jcifs.smb.client.disablePlainTextPasswords", "false");

[mbechler]

For SMB1 you could also try jcifs.smb.useRawNTLM=true

[mbechler]

I've added a workaround that should make guest login work without any special configuration. This disables the SPNEGO MIC when guest login is requested (use withGuestCredentials() or the appropriate NtlmPasswordAuthenticator constructors)

Login with invalid credentials will still fail with the error, but this is now converted into an SmbAuthException.

However, in my tests jcifs.smb.client.disableSpnegoIntegrity=true generally solves the issue (however, there are modern servers which require the MIC), so there may be an additional issue if this does not work for SMB1 in your case.

[courville]

Thanks: I will deploy a new beta and share with WD MyCloud users for collecting feedback.

[courville]

For the record it seems that with Western Digital NAS jcifs.smb.client.disableSpnegoIntegrity=true is still required even with latest guest login scheme.

[courville]

An update from feedback (without logs and captures) of WD users in the field: with disableSpnegoIntegrity=true still no connection is possible with SMB1 or SMB2 on WD cf. https://www.reddit.com/r/NovaVideoPlayer/comments/k793s6/not_reading_smb_on_firestick/

[courville]

An update from feedback (without logs and captures) of WD users in the field: with disableSpnegoIntegrity=true still no connection is possible with SMB1 or SMB2 on WD cf. https://www.reddit.com/r/NovaVideoPlayer/comments/k793s6/not_reading_smb_on_firestick/

Some updates on the investigation:

• disableSpnegoIntegrity=true does not help and thus should not be used
• using default jcifs resolveOrder prevents WD NAS login (it times out) and using jcifs.resolveOrder="BCAST,DNS" yields to a working configuration. However using jcifs.resolveOrder="BCAST,DNS" makes other users complain about not being able to connect in other configurations related to Changing jcifs resolveOrder makes connection issue due to wrong server IP used #258

[courville]

Let's declare this issue closed. Seems that it works now with jcifs-ng master. Will reopen if need be. Thank you a lot for the continuous dedicated support.