Bug 12876 - libsmbclient server discovery fails when using SMB2
Summary: libsmbclient server discovery fails when using SMB2
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: libsmbclient (show other bugs)
Version: 4.6.5
Hardware: All Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on: 12863
  Show dependency treegraph
Reported: 2017-07-04 21:53 UTC by julian.harnath
Modified: 2018-04-30 12:36 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description julian.harnath 2017-07-04 21:53:15 UTC
When setting the min/max client protocol version via smb.conf to:
client min protocol = SMB2
client max protocol = SMB3
then server/share discovery (i.e. opening the directory "smb://") with libsmbclient fails. This is reproducible both with Samba's own code as well as in my own code using the library.

Steps to reproduce:
(1) set the min/max client protocol version as above in smb.conf
(2) run "smbtree", or the example application from the Samba sources in examples/libsmbclient/testbrowse2.c
(3) no servers/shares are found

Some additional information:
* The fileserver is running Samba 4.5 on FreeBSD, and has its max protocol set to SMB3, so it's not an issue of an SMB1-only server
* I can connect to a share on the server using "smbclient" just fine, even with the above smb.conf settings. Wireshark confirms it's using SMB2 then. (But since I supply the path to the share manually to smbclient, there's no server discovery involved.)

If needed, I can also provide log files of the test case with SMBCTX debug level raised, or provide a packet capture of a failed attempt.
Comment 1 Stefan Metzmacher 2017-07-05 11:59:13 UTC
Let's see if we can fix this before 4.7.0
Comment 2 Giulio 2017-07-05 21:32:46 UTC
I was under the impression that the "servers list" (ie network discovery) is not available with SMB2/SMB3, therefore the behavior is normal?

For this very reason smbclient has been modified to force NT1/SMB1 when doing "-L":
this has its own problems if the remote server has SMB1 disabled (https://bugzilla.samba.org/show_bug.cgi?id=12863).


I'm testing with smbclient-4.7rc1:
- smbclient defaults to max protocol smb3
- smbclient -L -> automatically forces downgrade to NT1 and I see server list if remote server/master browser supports NT1
- If I use "client min protocol = SMB2", then smbclient -L gives
protocol negotiation failed: NT_STATUS_INVALID_PARAMETER
I think this is due to the forcing downgrade to NT1.


Both for smbclient and libsmbclient, I think we should first understand what is the expected behavior for getting the servers list when using SMB2/SMB3:
- when the remote server/master-browser supports SMB1, and when not.
- when the "client min protocol" is set to SMB2/SMB3, and when not


As far as I know, if you disable SMB1 on Windows 10, then Windows 10 will completely disable netbios discovery (ie: no downgrade to browse network, no more "computer browser" service), and will do discovery with LLMNR/WSD only.
Ie: windows 10 with SMB1 disabled won't see Samba on the network neighborhood (computers list).
Comment 3 julian.harnath 2017-07-07 19:22:48 UTC
Can anyone confirm or deny this? That share browsing is generally not available for protocol reasons when min client protocol >= SMB2?
Comment 4 julian.harnath 2017-07-07 19:23:33 UTC
Correction, I mean share listing, not browsing.
Comment 5 Stefan Metzmacher 2017-08-16 06:13:48 UTC
SMBC_opendir_ctx() doesn't seem to support SMB2/3 as it uses cli_NetServerEnum()

Jeremy, do you see any way to get SMBC_opendir_ctx() working with SMB2/3?

Otherwise this might be a show stopper for "client max protocol = SMB3" :-(

smbtree can be fixed by forcing SMB1 as a first step.
Comment 6 Stefan Metzmacher 2017-08-16 06:14:43 UTC
(In reply to julian.harnath from comment #4)

Share listing is supported over DCERPC (which can use any SMB versions)
Comment 7 Jeremy Allison 2017-08-16 21:26:04 UTC
Can't we change SMBC_opendir_ctx() to call mDNS browsing (as in do_smb_browse()) instead of cli_NetServerEnum() ? Not an immediate fix, but doable I think.
Comment 8 Stefan Metzmacher 2017-08-16 23:15:35 UTC
(In reply to Jeremy Allison from comment #7)

git grep -i dnssd doesn't find any configure check.

Which system library supports this?

I'm not sure that relying on the presence of such a library at build time
is a good thing, and I guess not much servers support this anyway.

I guess LLMNR would be needed...
Comment 9 Jeremy Allison 2017-08-17 00:12:41 UTC
DNSSD is an Apple invention (I think Macs still use it - they call it Bonjour I think).


We used to support this in the client. Looks like Windows 10 added support for it:


Maybe we should resurrect it ?
Comment 10 Stefan Metzmacher 2017-08-17 20:02:00 UTC
(In reply to Jeremy Allison from comment #9)

Maybe, but I guess this is nothing we can rush into 4.7.

I guess we should have a section that smb:// only works
with "client max protocol = NT1" to WHATSNEW.txt
and may fix this completely later.

What do you think?
Comment 11 Jeremy Allison 2017-08-17 21:32:50 UTC
Yes, this won't make 4.7.0 I think. Also, reading my previous comment links more carefully it looks like there are still bugs in the MS implementation of bonjour anyway :-(.
Comment 12 Stefan Metzmacher 2017-08-30 07:15:52 UTC
With the changes of bug #12863 this is no longer blocking 4.7.0
Comment 13 Harsh Shukla 2018-03-31 09:31:12 UTC
Is this bug open or resolved ?
Comment 14 Stefan Metzmacher 2018-04-29 20:57:22 UTC
(In reply to Harsh Shukla from comment #13)

It's open