After upgrade from smbclient-3.4 to smbclient-3.5.0, I can't connect to my Asus router with Nautilus. (There's some older samba 3 on that router). It lists shares, but can't mount any of them. Shows a message box: "_russian_text_...DBus error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)..._russian_text_". At the same time I can access shares on XP laptop. I downgraded to smbclient-3.4.5-1 and now it works. logged message: Mar 12 18:19:00 IL kernel: gvfsd-smb[15470]: segfault at c35dec79 ip b7661068 sp b65bfb40 error 5 in libsmbclient.so.0[b71f9000+5a2000] Don't know where to find coredump, is it created? Built smbclient with "-g -O0". Here's the gdb backtrace after SIGSEGV caught: #0 0xb76d9f28 in talloc_get_name () from /usr/lib/libsmbclient.so.0 #1 0xb76dd2ac in _talloc_get_type_abort () from /usr/lib/libsmbclient.so.0 #2 0xb71a5c8c in cli_smb_req_send (req=0xb77098ee) at libsmb/async_smb.c:527 #3 0xb716d882 in cli_tcon_andx_send (mem_ctx=0x8c72ad8, ev=0x8c72f78, cli=0x8c51830, share=0xb7709876 "IPC$", dev=0xb77098f5 "IPC", pass=0x0, passlen=0) at libsmb/cliconnect.c:1458 #4 0xb716db52 in cli_tcon_andx (cli=0x8c51830, share=0xb7709876 "IPC$", dev=0xb77098f5 "IPC", pass=0x0, passlen=0) at libsmb/cliconnect.c:1537 #5 0xb719a8f7 in cli_check_msdfs_proxy (ctx=0x8c501d8, cli=0x8c51830, sharename=0x8c4d9b0 "share$", pp_newserver=0xb645eeec, pp_newshare=0xb645eee8, force_encrypt=false, username=0x8c50590 "il", password=0x8bc16f0 "", domain=0x8c505c8 "WORKGROUP") at libsmb/clidfs.c:1019 #6 0xb70c5031 in SMBC_server_internal (ctx=0x8c501d8, context=0x8c4f998, connect_if_not_found=true, server=0x8c4d970 "my.router", share=0x8c4d9b0 "share$", pp_workgroup=0xb645f134, pp_username=0xb645f13c, pp_password=0xb645f138, in_cache=0xb645f0b7) at libsmb/libsmb_server.c:536 #7 0xb70c579a in SMBC_server (ctx=0x8c501d8, context=0x8c4f998, connect_if_not_found=true, server=0x8c4d970 "my.router", share=0x8c4d9b0 "share$", pp_workgroup=0xb645f134, pp_username=0xb645f13c, pp_password=0xb645f138) at libsmb/libsmb_server.c:670 #8 0xb70c6726 in SMBC_stat_ctx (context=0x8c4f998, fname=0x8c50180 "smb://my.router/share%24", st=0xb645f19c) at libsmb/libsmb_stat.c:168
Created attachment 5498 [details] sysinfo
triage: to jra
still present in 3.5.1
To reproduce this bug find a way to invoke cli_tcon_andx_send() with parameters: cli->sec_mode=2 pass=NULL In this case the following block in cli_tcon_andx_create() will goto access_denied: ************************************************* /* in user level security don't send a password now */ if (cli->sec_mode & NEGOTIATE_SECURITY_USER_LEVEL) { passlen = 1; pass = ""; } else if (pass == NULL) { DEBUG(1, ("Server not using user level security and no " "password supplied.\n")); goto access_denied; } ************************************************* This in turn leaves unititialized the local variable 'struct tevent_req *subreq' in cli_tcon_andx_send(): ************************************************* struct tevent_req *cli_tcon_andx_send(TALLOC_CTX *mem_ctx, struct event_context *ev, struct cli_state *cli, const char *share, const char *dev, const char *pass, int passlen) { struct tevent_req *req, *subreq; NTSTATUS status; req = cli_tcon_andx_create(mem_ctx, ev, cli, share, dev, pass, passlen, &subreq); if (req == NULL) { return NULL; } status = cli_smb_req_send(subreq); *************************************************
Created attachment 5515 [details] Possible patch While I haven't really found a way to reproduce this, does the attached patch fix the bug for you? Volker
doesn't help. Now segfault is earlier: #0 0xb7047e18 in _tevent_req_data (req=0x0) at ../lib/tevent/tevent_req.c:383 #1 0xb70a8e68 in cli_smb_req_send (req=0x0) at libsmb/async_smb.c:527 #2 0xb70709b9 in cli_tcon_andx_send (mem_ctx=0x8f8a2a0, ev=0x8f8a310, cli=0x8f8aa30, share=0xb762437a "IPC$", dev=0xb76243f9 "IPC", pass=0x0, passlen=0) at libsmb/cliconnect.c:1459 void *_tevent_req_data(struct tevent_req *req) { return req->data; /* <- here */ } I already tried another patch. With it no segfault, but connect timeout instead: ******************************************** --- source3.old/libsmb/cliconnect.c 2010-03-21 12:50:52.000000000 +0300 +++ source3/libsmb/cliconnect.c 2010-03-21 12:48:33.000000000 +0300 @@ -1455,10 +1455,13 @@ if (req == NULL) { return NULL; } - status = cli_smb_req_send(subreq); - if (!NT_STATUS_IS_OK(status)) { - tevent_req_nterror(req, status); - return tevent_req_post(req, ev); + status = tevent_req_simple_recv_ntstatus(req); + if (NT_STATUS_IS_OK(status)) { + status = cli_smb_req_send(subreq); + if (!NT_STATUS_IS_OK(status)) { + tevent_req_nterror(req, status); + return tevent_req_post(req, ev); + } } return req; } ************************************
looks like this bug not present in today's git
This patch works. Please add it to 3.5.3 http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=34f0cff0664f1c160ee7442461e9f875e8d8f4dc;hp=dc689827114c46b3ca2a75082421dc2d98001ce7
Fixed in Samba 3.5.3. Thanks for the report!
*** Bug 7268 has been marked as a duplicate of this bug. ***