Issue with IPv6 on Ubuntu 16.04 and possible related issue with Windows 10 v2004

[Hackmiester5000]

I'm new to wsdd, and I'm not sure if I have done some thing wrong or if I am missing a dependency, but I am having some problems. I tried to look for a solution online, but nothing I found seemed helpful.

I am using the current master branch (verified as of today) on Ubuntu 16.04, and I get an error if I allow IPv6 connectivity: $ ./wsdd.py -v -i wlan0 -n WISTORAGE 2020-09-08 19:54:39,142:wsdd INFO(pid 6540): using pre-defined UUID d6d789df-7751-542d-9cc7-911f64685646 2020-09-08 19:54:39,155:wsdd INFO(pid 6540): joined multicast group ('239.255.255.250', 3702) on 192.168.27.1%wlan0 2020-09-08 19:54:39,175:wsdd ERROR(pid 6540): error in main loop Traceback (most recent call last): File "./wsdd.py", line 1651, in main key.data.handle_request() File "./wsdd.py", line 1220, in handle_request self.handle_new_address(addr, ifa_family, iface) File "./wsdd.py", line 1028, in handle_new_address mch = MulticastHandler(addr_family, addr, interface, self.selector) File "./wsdd.py", line 62, in init self.init_v6() File "./wsdd.py", line 102, in init_v6 socket.IPPROTO_IPV6, IPV6_MULTICAST_ALL, 0) OSError: [Errno 92] Protocol not available

If I only allow IPv4, it seems that Windows 10 (v2004) is unable to discover my host, I see the Probe, but apparently no response is sent: $ ./wsdd.py -v -4 -i wlan0 -n WISTORAGE 2020-09-08 19:56:46,277:wsdd INFO(pid 6544): using pre-defined UUID d6d789df-7751-542d-9cc7-911f64685646 2020-09-08 19:56:46,289:wsdd INFO(pid 6544): joined multicast group ('239.255.255.250', 3702) on 192.168.27.1%wlan0 2020-09-08 19:57:32,356:wsdd INFO(pid 6544): 192.168.27.101:53810(wlan0) - - "Probe urn:uuid:8c0b718b-c52c-42b0-ac0f-b900a344f4a6 UDP" - -

If I increase the verbosity with -vv, it is clear that no "ProbeMatch" or "Resolve" is sent. (see attached log, Listing under line with:"DEBUG IPv4 -i WLAN0") If I add another interface that is visible via the Ethernet LAN, again, Windows 10 will not discover my host, but I CAN see it when running wsdd.py in client mode on another Ubuntu 16.04 machine. (See attached log , Listing under "DEBUG IPv4 -i wlan0 -i br0:0")

Wsdd_Win10_Problem.txt

Please let me know if you need any other information or tests run. Thanks, Bruce

[christgau]

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.

[Hackmiester5000]

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

[Hackmiester5000]

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

[christgau]

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

[Hackmiester5000]

Thanks for your help, I really appreciate how quickly you helped to resolve the issue.

Tschüss, Bruce

From: Steffen Christgau notifications@github.com Sent: Wednesday, September 9, 2020 2:12 PM To: christgau/wsdd wsdd@noreply.github.com Cc: Bruce McCready BMcCready@praxisproducts.net; Author author@noreply.github.com Subject: Re: [christgau/wsdd] Issue with IPv6 on Ubuntu 16.04 and possible related issue with Windows 10 v2004 (#57)

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

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/christgau/wsdd/issues/57#issuecomment-689730116, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQ2A6HWDKJ7WKAXNT5GQQ2LSE7ANPANCNFSM4RAOY7AQ.

Email secured by Check Point