Created attachment 15509 [details]
smb.conf

Created attachment 15510 [details]
Pcap

(In reply to Christopher Cox from comment #2)

Capture frames can't be decoded into SMB by wireshark. Can you try the capture again and make sure you just capture full frames going between client and server.

On 10/3/19 2:47 PM, samba-bugs@samba.org wrote:
> https://bugzilla.samba.org/show_bug.cgi?id=14151
> 
> --- Comment #3 from Jeremy Allison <jra@samba.org> ---
> (In reply to Christopher Cox from comment #2)
> 
> Capture frames can't be decoded into SMB by wireshark. Can you try the capture
> again and make sure you just capture full frames going between client and
> server.
> 

Maybe my tcpdump is rusty.  I figured it was capturing enough.  What 
options do you recommend?

Actually, what would really help isn't the wireshark trace - but for you to set a gdb breakpoint on 

smb1cli_req_writev_submit()

and post me a gdb backtrace from that point.

If you know how to use gdb, being able to go up one frame to tstream_smbXcli_np_readv_trans_start() and then print out the contents of the cli_nps struct variable that would confirm.

I'm pretty sure that inside there you'll have:

cli_nps->is_smb1 = true (1)

and it should be false (0).

Now the question is *why*...

Oh, I think you may be blundering into a bug that got fixed in later Samba versions.

Inside your version of:

source3/client/client.c:browse_host() you have:

4897 /****************************************************************************
4898  Try and browse available connections on a host.
4899 ****************************************************************************/
4900 
4901 static bool browse_host(bool sort)
4902 {
4903         int ret;
4904         if (!grepable) {
4905                 d_printf("\n\tSharename       Type      Comment\n");
4906                 d_printf("\t---------       ----      -------\n");
4907         }
4908 
4909         if (browse_host_rpc(sort)) {
4910                 return true;
4911         }
4912 
4913         if((ret = cli_RNetShareEnum(cli, browse_fn, NULL)) == -1) {
4914                 NTSTATUS status = cli_nt_error(cli);
4915                 d_printf("Error returning browse list: %s\n",
4916                          nt_errstr(status));
4917         }
4918 
4919         return (ret != -1);
4920 }

Note that if 'browse_host_rpc(sort)' fails then it continues to the SMB1-specific cli_RNetShareEnum() call.

Modern versions of Samba have:

4900 /****************************************************************************
4901  Try and browse available connections on a host.
4902 ****************************************************************************/
4903 
4904 static bool browse_host(bool sort)
4905 {
4906         int ret;
4907 
4908         if (!grepable) {
4909                 d_printf("\n\tSharename       Type      Comment\n");
4910                 d_printf("\t---------       ----      -------\n");
4911         }
4912 
4913         if (browse_host_rpc(sort)) {
4914                 return true;
4915         }
4916 
4917         if (lp_client_min_protocol() > PROTOCOL_NT1) {
4918                 return false;
4919         }
4920 
4921         ret = cli_RNetShareEnum(cli, browse_fn, NULL);
4922         if (ret == -1) {
4923                 NTSTATUS status = cli_nt_error(cli);
4924                 d_printf("Error returning browse list: %s\n",
4925                          nt_errstr(status));
4926         }
4927 
4928         return (ret != -1);
4929 }

Note the fix at lines 4917-4919 that prevents falling through into cli_RNetShareEnum() if the SMB2 rpc call failed.

In your smbclient debug level 10 log you have:

rpc_api_pipe: host doc_svr2
cli_api_pipe failed: NT_STATUS_IO_TIMEOUT

*Then* followed by the smb1cli_req_writev_submit: called for dialect[SMB3_00] server[doc_svr2] error.

I think that means the server timed out the dcerpc_srvsvc_NetShareEnumAll() call, so it blundered into the old SMB1 code.

So that error message is a red herring.

The real problem is why the server isn't reponding to the dcerpc_srvsvc_NetShareEnumAll() call I think.

FYI, when talking to a MacOSX server you should always set 'client min protocol = SMB2' as Apple written Mac servers will never support SMB1.

See bug:

https://bugzilla.samba.org/show_bug.cgi?id=14152

I just logged, as it still needs some changes in master/Samba-current releases.

The netbios port (139) is closed on doc_svr2.  But again, Windows can enumerate the shares, Mac can enumerate the shares... but maybe it's why smbclient can't?

(I'm just guesing... feel free to ignore if n/a)