+++ This bug was initially created as a clone of Bug #11849 +++ Hi, I'm not sure, but I think that the version of the patch that is currently already checked in broke something. I'm used to do discovery of local devices like that: smbclient -N -L localhost Then look for the master of the workgroup (let's say BIGMASTER) and do: smbclient -N -L BIGMASTER ...
Created attachment 12393 [details] Trace of a good and a broken smbclient Hi, Sorry for the long delay to generate the traces. Following the discussion on #11849, here are the requested logs. Test 1 and 2 are done with an unmodified version of Samba 4.2.12. Test 3 is done with a modified version where I reverted the second part of the following patch: https://git.samba.org/?p=samba.git;a=commitdiff;h=e72ad193a53e20b769f798d02c0610f91859bd38 "R4-BACKUP-1" is the client performing the request. "5BIGBACKUPSOFT" is the device target that present the issue. "LINKSYS08959" (not important), it is the network router, that is now the master of the isolated network. I don't think that the "Test2" will be relevant anymore as I had to change of network for an isolated one to generate the traces but so the workgroup "master" changed to be the network router and not anymore the 5bigbackupsoft. Let me know if there is something else that I can do to help you investigate this issue.
Hi @Stefan, Is it possible for you to have a look at my traces to see if there could be something interesting inside them?
Hi @Stefan, Do you have an idea for my issue, or do you need more info? Thank you
(In reply to Florent V from comment #3) Somehow the Windows server behaves different depending on an anonymous session setup with or without extended security. In the broken case the server just returns ERROR_NO_BROWSER_SERVERS_FOUND (6118), but I can't reproduce that with Windows 2000sp4, Windows Server 2003 3790, or Windows Server 2008 R2 Enterprise 7601 Service Pack 1. Maybe ERROR_NO_BROWSER_SERVERS_FOUND is just a temporary error, also got ERROR_REQ_NOT_ACCEP (71) once and a few seconds later it worked. I'll close this for now as I don't we can do anything here.
Hello, I could reproduce this bug by following a downstream but report on Ubuntu [1]. Note that this is still valid in samba 4.14. As mentioned in [1], a workaround for the issue would be to set "client use spnego = no" through the --option param. My current concern is about the notice on the documentation saying the "client use spnego = no" option will be removed in the future [2]. This would mean that the relevant browsing feature would no longer work. In this case, should that bit be completely removed from the command output in case a patch is not feasible here? Moreover, I am wondering what the implications of disabling SPNEGO usage for anonymous requests (for SMB1) would be here. Could you point me in the right direction? Am right to assume it would not introduce a regression on https://bugzilla.samba.org/show_bug.cgi?id=11841 since that was buggy for SMB2? Thanks! [1] https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1926119 [2] https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#CLIENTUSESPNEGO