Created attachment 11085 [details] sceen shot capturing the failure after negotiate protocol repsonse. The smbclient library while interacting with SMB2.02 based servers, is looking for credits after negotiate protocol and while doing session setup. ********************************************************** Connecting to 164.99.112.38 at port 445 [2015/05/25 18:24:27.169815, 3] ../source3/libsmb/cliconnect.c:1781(cli_session_setup_spnego_send) Doing spnego session setup (blob length=89) [2015/05/25 18:24:27.169876, 3] ../source3/libsmb/cliconnect.c:1808(cli_session_setup_spnego_send) got OID=1.2.840.113554.1.2.2 got OID=1.2.840.48018.1.2.2 got OID=1.3.6.1.4.1.311.2.2.10 [2015/05/25 18:24:27.169930, 3] ../source3/libsmb/cliconnect.c:1818(cli_session_setup_spnego_send) got principal=host/blr8-112-38.my2k8ad.com@ [2015/05/25 18:24:27.170017, 3] ../source3/libsmb/cliconnect.c:2147(cli_session_setup_done_spnego) SPNEGO login failed: NT_STATUS_INTERNAL_ERROR ********************************************************** Also seen the issue in read and write operation, even after fixing this issue with the probable fix. Attaching the combined fix handling the credit requirement even when the SMB server is running at SMB2.02 dialect level.
Created attachment 11086 [details] probable fix for handling the libsmbclient interaction with SMB2.02 based servers During SMB2 interaction the fix is checking the protocol level and skipping the credit checks. - While doing request compound submit - During read and write operation Please review and give your feedback.
(In reply to hargagan from comment #0) Can you be a bit more specific about your actual problem? We need to know which server you're using and we need exact steps to reproduce this. A real network capture would also be good to have, screen shots doesn't help much, sorry. SMB 2.02 supports credits and we need to understand the problem completely in order to provide a fix.
(In reply to Stefan (metze) Metzmacher from comment #2) I am using smbclient library calls against novell cifs server part of Novell OES latest builds and they are supporting smb2.02 version. This is not released yet, but the public beta release has happened some time back having this smb2.02 support. The issue happens when we use for calls like SMBC_open(), SMBC_read() etc against the novell cifs server. In the packet trace I am seeing only first SMBv1 negotiate happening and them it gets the response on SMB2. But when it tries to do session setup, that time I am seeing the error 'NT_STATUS_INTERNAL_ERROR' in the logs. After doing some investigation found that the smbclient library code is doing calculations for 'credits' and that is causing the error. After discussion with the team here came to know that credits is not supported in SMB2.02 and hence the patch. This is fixing the issue and it goes further to try out operations. Then I saw issues while we try to do read / write operations. There as well we are doing checks for credit which doesn't send the requests at all. To handle that the patch has changes. After some search cane to know that Windows 2008 (non R2, any sp) also supports smb2.02. I haven't tried this test against a windows 2008 server yet. I am going to try that and update the results, but this could take some time. Got this link from telling more about the credit support on smb2.02 : https://msdn.microsoft.com/en-us/library/cc246529.aspx
(In reply to hargagan from comment #3) Can you try the patch on https://bugzilla.samba.org/show_bug.cgi?id=10966 or simply try with a newer samba version (it should be fixed >= 4.1.15) SMB 2.02 doesn't support CreditCharge, but it does support CreditRequest/CreditResponse.
Created attachment 11087 [details] packet trace showing failure when SMB negprot request followed by SMB2 negprot repsonse. This is the packet capture "without" applying the patch. I still have to try out the patch. I will update on that soon.
(In reply to Stefan (metze) Metzmacher from comment #4) Unfortunately the patch doesn't seem to fix the issue. As seen in the packet trace snapshot, the smb negprot starts as SMB1 and then the response comes as SMB2. The patch seem to be handling the path when the request itself is send with SMB2. Please correct me if I am wrong here.
(In reply to hargagan from comment #6) Yes. Can you try with "client max protocol = SMB2" and upload a capture of the connect. And also capture a connect from a Windows client that starts with SMB1. Thanks!
(In reply to Stefan (metze) Metzmacher from comment #7) In any case the server has a bug, it should always grant any consumed credit...
(In reply to hargagan from comment #3) hargagan - an SMB2.02 server must grant credits. See the text here: https://msdn.microsoft.com/en-us/library/cc246529.aspx CreditRequest/CreditResponse (2 bytes): On a request, this field indicates the number of credits the client is requesting. On a response, it indicates the number of credits granted to the client. in the link you sent. It doesn't do "CreditCharge" calculations, but that's not the same as credits. I agree with Metze, looks like a server issue to me. Jeremy.
Created attachment 11091 [details] packet trace showing 'client min protocol = SMB2' in smb.conf
(In reply to hargagan from comment #10) I'm sorry it needs to be 'client min protocol = SMB2_02' in order to produce something useful...
Looks like a problem with the cifs server in question, hence closing this bug as invalid.