Issue with IPv6 on Ubuntu 16.04 and possible related issue with Windows 10 v2004 about wsdd HOT 5 CLOSED

on Ubuntu 16.04, [...] I get an error if I allow IPv6 connectivity:
[...]
socket.IPPROTO_IPV6, IPV6_MULTICAST_ALL, 0)
OSError: [Errno 92] Protocol not available

IPV6_MULTICAST_ALL has been introduced to Linux in version 4.20. Ubuntu 16.04 LTS comes with Linux 4.15 at best (if Wikipedia is right) and there's no (complete) check for availability of the option around the setsockopt call. I'll fix that, asap. Meanwhile you can just comment out lines 99 to 102.

Concerning the main issue, I have to find some time to have a closer look. If no ProbeMatch is sent when it should, there might be something wrong... I'll keep you informed.

from wsdd.

Thanks for your quick response.

FYI, to be thorough, I tried the wsdd2 that you linked to in your README.md, and My Windows 10 laptop doesn't discover my host with that either.

Again, if there is any information you need or test that you would like me to try, I'd be happy to help.

Thanks,
Bruce

from wsdd.

I commented out those lines and now it is showing up on my Windows 10. I seems that my version of Windows 10 prefers IPv6. Now, though, when I click on the icon for my host, WISTORAGE, and I get an error popup that says "\WISTORAGE is not accessible. You might not have permission to use this network resource. Contact the administrator to this server to find out if you have access permissions."
However, I can still map the shared drive using the IP Address, e.g., "\192.168.27.1\Storage"
I wonder if the issue is related to the fact that the name I'm passing to the -n option "WISTORAGE" is not related to the host name, or the original netbios name configured in the smb.conf which worked when smbd was still using the SMB1 protocol? I wouldn't think so, but this is all pretty new to me, so I am grasping at straws.

EDIT: I tried with another Windows 10 laptop, also at v2004, but behind by several updates and I get a different error when I click on the icon for my device, this error says "Windows cannot access \WISTORAGE\ Check the spelling ...." and when i click on the "show details" it says "Error code: 0x80070035. The network path was not found"

Thanks,
Bruce

from wsdd.

I commented out those lines and now it is showing up on my Windows 10.

Great. And that's it is. wsdd almost only purpose is to make sure your computer shows up in the network view of Windows. Anything "behind" that is out of its scope. Thus, I'm closing the issue.

I seems that my version of Windows 10 prefers IPv6.

...which is a good thing.

Now, though, when I click on the icon for my host, WISTORAGE, and I get an error popup that says "\WISTORAGE is not accessible. You might not have permission to use this network resource. Contact the administrator to this server to find out if you have access permissions."
However, I can still map the shared drive using the IP Address, e.g., "\192.168.27.1\Storage"

You have to try \\192.168.27.1, without "Storage", to get a similar request to the Samba server as when you would use \\WISTORAGE.

I wonder if the issue is related to the fact that the name I'm passing to the -n option "WISTORAGE" is not related to the host name, [....] I wouldn't think so, but this is all pretty new to me, so I am grasping at straws.

The important point here is that Windows resolves the (host) name that is shown in the network view. That is, you should have a DNS server or, IIRC, a working LLMNR which can resolve that name. Since you do not use the hostname of the machine running Samba it is likely you can't even ping the host under that name, i.e. the "hostname" cannot be resolved. The usual way to go is to use the real hostname of the machine for wsdd just as it is. This is done by default and wsdd -i wlan0 should just work. But as I said, everything behind showing a little icon in the network view is not a job for wsdd.

EDIT: I tried with another Windows 10 laptop [...] and when i click on the "show details" it says "Error code: 0x80070035. The network path was not found"

Yep, that confirms the above..

from wsdd.

from wsdd.