Bug 12876 - libsmbclient server discovery fails when using SMB2
libsmbclient server discovery fails when using SMB2
Status: ASSIGNED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: libsmbclient
4.6.5
All Linux
: P5 regression
: 4.7
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on: 12863
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-04 21:53 UTC by julian.harnath
Modified: 2017-08-22 06:21 UTC (History)
1 user (show)

See Also:


Attachments

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":
https://git.samba.org/?p=samba.git;a=commitdiff;h=2726c1a1b0c69d618248b607eca
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.
https://bugzilla.samba.org/show_bug.cgi?id=11473
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).

http://www.dns-sd.org/

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

https://channel9.msdn.com/Events/Build/2015/3-79
https://ctrl.blog/entry/windows-mdns-dnssd

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 :-(.