Consider the following sequence of CIFS commands: -Open_AndX some file "A", allowing create. Generally, this will pass. -Open a new tree -> andx chained to a unlink of that file "A". (e.g. TreeConnect_AndX chained to Unlink). This should fail with NT_STATUS_SHARING_VIOLATION -Disconnect From that new tree (Tree_Disconnect). -Returning to old true, Close file A. After this sequence of commands (which samba responds as expected to), the samba server will continually send responses to TreeConnect_AndX (although with no unlink chained to it). with some invalid Mid. It will not respond to any subsequent requests from the client; rather, it will continue flooding the client with Tree_Connect responses. A close or unlink appears necessary to triggering this problem.
Can you send me a some client code or binary that will send this sequence please so I can debug this ? Thanks, Jeremy.
Aaron, please try to keep the comments in the bug report rather than replying to email. It allows us to track things better between developers. --------- forwarded mail ------------------------- Well, it is actually in the form of a samba 4 torture test: Add this to torture/torture.c: */Samba bug that occurs with chained treecon/unlink*/ BOOL torture_samba_inf_response(void) { char * fname = "samba_inf.txt"; struct smbcli_state *cli; struct smbcli_request *req = NULL; if (!torture_open_connection(&cli)) { printf("Couldn't open connection!\n"); return False; } d_printf("Opening %s\n",fname); int fnum = smbcli_open(cli->tree, fname, O_RDWR | O_TRUNC | O_CREAT, DENY_NONE); d_printf("running tcon chained with unlink\n"); int tid = cli->tree->tid; req = smbcli_request_setup(cli->tree, SMBtconX, 4, 0); SSVAL(req->out.vwv, VWV(0), SMB_CHAIN_NONE); SSVAL(req->out.vwv, VWV(1), 0); SSVAL(req->out.vwv, VWV(2), 0); DATA_BLOB pw = data_blob(NULL, 0); SSVAL(req->out.vwv, VWV(3), pw.length); smbcli_req_append_blob(req, &pw); smbcli_req_append_string(req,lp_parm_string(-1, "torture", "share"), STR_TERMINATE | STR_UPPER); smbcli_req_append_string(req,"?????", STR_TERMINATE | STR_ASCII); smbcli_chained_request_setup(req, SMBunlink, 1, 0); /*correct samba4 torture "bug" w/ chained setup*/ req->out.data_size = 0; req->out.data = req->out.vwv + VWV(1)+2; req->out.wct = 1; SSVAL(req->out.vwv, VWV(0), FILE_ATTRIBUTE_SYSTEM | FILE_ATTRIBUTE_HIDDEN); smbcli_req_append_ascii4(req, fname, STR_TERMINATE); if (!smbcli_request_send(req)|| !smbcli_request_receive(req)) { smbcli_request_destroy(req); return False; } /*tree_connect receive.*/ cli->tree->tid = SVAL(req->in.hdr, HDR_TID); d_printf("disconnecting from new tree\n"); smb_tree_disconnect(cli->tree); cli->tree->tid = tid; /*return to old tree*/ d_printf("closing file\n"); smbcli_close(cli->tree,fnum); d_printf("removing file\n"); NTSTATUS ret = smbcli_unlink(cli->tree,fname); return NT_STATUS_IS_OK(ret); } and the torture-op: {"TreeConUnlink", torture_samba_inf_response, 0}, /*test for samba*/ and of course: bin/smbtorture '\\server\share' TreeConUnlink to launch the test. This test passes on a windows 2000 server. On a samba server, it will time-out after 60 seconds (no response is received for the Delete SMB command). With samba set to debug level 1, the many unmatched reply messages can be seen. -Aaron
Created attachment 1337 [details] Patch. This should fix it. Jeremy.
The problem was using Inbuffer to push a deferred open message onto the queue when we're in a chained message set - we're actually processing a different buffer then. Added current_inbuf as a static inside smbd/process.c to ensure the correct message gets pushed and processed. Jeremy.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.