WS-Discovery not working for me on 3.0.72
Advanced Network Neighborhood Browser and Samba Share Mounting Utility
Brought to you by:
areinholdt
Menu
▾
▴
Hi,
I've had no luck getting WSD working on the new branch. It compiles fine, and the option is there, and checked, in settings, and I can see local (DNS-SD) and workgroups (SMB1), but nothing for WSD machines.
Not sure what to look at to troubleshoot.
Dolphin finds all the machines on the network.
Hello Jason,
thank you for the feedback. I will have a look at this.
Best regards
Alexander
Hello Jason,
I found the problem. The lookup was intended to run 1 sec, but it returned immediately so that there was not enough time to collect the data. This should be fixed now. Please let me know if you are able to find the WSD machines in the next development release.
Kind regards
Alexander
Thank you.
I pulled and compiled and still not having any luck.
Is WSD supposed to show up under its own category?
The only thing showing up here is "LOCAL" and my 2 linux machines under it.
Again, dolphin sees my win10vm, and a physical Windows machine on the local network.
SMB1 is disabled on both the phys machine, and the vm.
EDIT: My linux machines are running wsdd also.
Last edit: Jason Straight 2020-11-24
Today I bought a Windows 10 license, installed Windows 10 in VirtualBox, could reproduce your problem and fixed it as far as I can see. I just want to improve the code a bit and will then commit it.
I just committed the changes. Maybe you would like to try it? Here is the patch.
Excellent. I'm not a wealthy person, but I owe you a dinner or something. Can't find any donations info for the project anywhere.
The discovery works great. Thanks.
I'm fiddling with resolution issues now.
The network I'm currently on (which I suspect will be like most people's) doesn't use local dynamic DNS. So, my host "hp-win10" is discovered by smb4k, but not resolved/reachable (no listing in IP address column).
If I add the ip4 or 6 address for "hp-win10" to /etc/hosts, then smb4k can access that host, list, and mount shares.
I notice that the way dolphin seems to get around that is by falling back to mdns 'hp-win10.local' if 'hp-win10' doesn't resolve.
Maybe that's a behavior that smb4k should mimic? I can't think of any other way to handle that, since using wins in /etc/nsswitch.conf doesn't work for resolving smb2+ hosts.
I am glad that the discovery works now!
If I understand correctly, the servers now appear in the network neighborhood browser, but the IP addresses are not resolved? And you are not able to get the listing of shares from the server without modifying the /etc/hosts?
That is correct.
That is interesting, because the IP address is not passed to libsmbclient which looks up the shares...
With dolphin (i. e. with the SMB kio-slave) you are able to get the list of shares? - If so, I have to investigate what they do differently.
Yes, dolphin works. It lists the host with just the hostname, but when I access the share the path includes the ".local" mdns domain name.
It used to be that libnss-mdns could be told to search the localdomain, or search domain that you would put in /etc/resolv.conf, but that was removed (unless compiled with special options), because (according to the manpage) it "broke things".
Even if that worked, it probably wouldn't be the ideal way, since almost nobody is going to have their /etc/nsswitch.conf configured to use it anyway.
I do see that nmblookup still returns the IP address for the host, but it returns 2 IP addresses, since the machine I'm accessing has a virtualbox device....
Hold the press! I had a hunch while writing that... If I remove the virtualbox device from that host, it replies with only 1 IP address and then smb4k works fine.
I also just tried with that machine having both a wired and wireless connection. smb4k fails to retrieve an IP address when the remote host returns more than 1.
I feel like using hostname.local is probably the safest route.
When the remote host returns addresses, they don't seem to be in any controllable order. So it's possible that just taking the first one could return an address that's on another network subnet entirely.
When I did lookups on my windows host, they returned in an order that I would have preferred, every time. The top one was ethernet, 2nd was wifi, and 3rd was vbox virtual device. I thought maybe order in the reply was determined by interface metrics, so I changed those and the order did not change.
So, even if you handle the query return of multiple IP addresses per host, you don't know which one to pick w/o doing subnet math to make sure the IP is within the same subnet.
Just to be thorough, I removed mdns entries from nsswitch.conf and tried dolphin. Dolphin assumes mdns will work and simply uses the ".local" domain. Without mdns entries in nsswitch.conf dolphin fails to reach the SMB host.
So that's all they're doing. Just pasting ".local" to the hostname and letting mdns take care of resolution.
Thank you for this thorough investigation. I need to think about how to implement this.
No problem. Wish I could do more to help.
I also noticed this morning, while at work, where I have set up local DNS for the domain williams.lan, that using dolphin to access a share resolved to hostname.williams.lan.
So it appears that dolphin uses a domain search of sorts during name resolution where it must try DNS first, then fall to mdns if that fails.
I don't know what the c++ equivalent of getent would be, but doing "getent hosts [hostname]" should follow any resolution configured in /etc/nsswitch.conf, which is probably what's wanted?
I'd have to try it at home, where I have no local DNS set up to be sure it resolves mdns, but it should.