I just rebooted my machine and even many minutes later, the wsdd.py is still using 100% cpu (one core):

A restart of the wsdd service fixed the problem. I can't think of a reason for this to happen but I don't really know the source code.

Hi, using latest git version (0.6) of wsdd, I'm getting errors (see below, please) although it still works.

# uname -a
Linux geras 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux
# cat /etc/debian_version
10.4
# /usr/local/bin/wsdd --verbose --interface br0 --chroot /run/wsdd/chroot/ -u nobody:nogroup
2020-06-06 18:47:09,950:wsdd INFO(pid 9265): using pre-defined UUID c4424de1-fe72-51b7-b552-adb441448b53
2020-06-06 18:47:09,961:wsdd INFO(pid 9265): chrooted successfully to /run/wsdd/chroot/
2020-06-06 18:47:09,961:wsdd INFO(pid 9265): running as nobody:nogroup (65534:65534)
2020-06-06 18:47:09,962:wsdd INFO(pid 9265): joined multicast group ('239.255.255.250', 3702) on 192.168.118.1%br0
2020-06-06 18:47:09,965:wsdd ERROR(pid 9265): error in main loop
Traceback (most recent call last):
  File "/usr/local/bin/wsdd", line 1626, in main
  File "/usr/local/bin/wsdd", line 1195, in handle_request
KeyError: 3
2020-06-06 18:47:09,974:wsdd INFO(pid 9265): 192.168.118.143 - - "POST /c4424de1-fe72-51b7-b552-adb441448b53 HTTP/1.1" 200 -
2020-06-06 18:47:09,977:wsdd INFO(pid 9265): 192.168.118.143 - - "POST /c4424de1-fe72-51b7-b552-adb441448b53 HTTP/1.1" 200 -
2020-06-06 18:47:10,016:wsdd INFO(pid 9265): 192.168.118.114 - - "POST /c4424de1-fe72-51b7-b552-adb441448b53 HTTP/1.1" 200 -

After refreshing 'Network' window on Windows 10 machine:

2020-06-06 18:49:10,784:wsdd INFO(pid 9265): 192.168.118.143:60472(br0) - - "Probe urn:uuid:31f774e8-bb70-47eb-8aa0-ec5157dfdb53 UDP" - -
2020-06-06 18:49:10,831:wsdd INFO(pid 9265): 192.168.118.143:60474(br0) - - "Resolve urn:uuid:85046a4f-62e6-4337-829b-2183943dea7d UDP" - -
2020-06-06 18:49:10,843:wsdd INFO(pid 9265): 192.168.118.143 - - "POST /c4424de1-fe72-51b7-b552-adb441448b53 HTTP/1.1" 200 -
2020-06-06 18:49:11,503:wsdd INFO(pid 9265): 192.168.118.143:60474(br0) - - "Resolve urn:uuid:3f737d43-1ffc-46f6-bf73-714c1de7d468 UDP" - -
2020-06-06 18:49:11,504:wsdd WARNING(pid 9265): invalid resolve request: address (urn:uuid:de8a0699-ffe6-593c-9964-c867d65adce0) does not match own one (urn:uuid:c4424de1-fe72-51b7-b552-adb441448b53)

I was able to work around this issue by changing:

self.socket.bind((os.getpid(), rtm_groups))

to

self.socket.bind((0, rtm_groups))

Based on this issue in an existing project (with the explanation there): zerotier/ZeroTierOne#994

The commit that fixes this is here (the username changed, so it was a slight pain to get to):

zerotier/ZeroTierOne@3dec78f

Thanks for the great library!

Using your example systemd script, the service fails to start. See corresponding code and versions below. When ran with the same parameters plus -v, it appears to run as expected interactively.

python3 -V

Python 3.6.3

cat /etc/redhat-release

Red Hat Enterprise Linux Server release 7.6 (Maipo)

cat /etc/systemd/system/wsdd.service

[Unit]
Description=Web Services Dynamic Discovery host daemon
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/wsdd -i team0
User=nobody
Group=nobody

[Install]
WantedBy=multi-user.target

systemctl status wsdd.service

● wsdd.service - Web Services Dynamic Discovery host daemon
   Loaded: loaded (/etc/systemd/system/wsdd.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2019-02-05 00:07:21 EST; 2s ago
  Process: 15656 ExecStart=/usr/bin/wsdd -i team0 (code=exited, status=127)
 Main PID: 15656 (code=exited, status=127)

Feb 05 00:07:21 rhel.local.lan systemd[1]: Started Web Services Dynamic Discovery host daemon.
Feb 05 00:07:21 rhel.local.lan systemd[1]: wsdd.service: main process exited, code=exited, status=127/n/a
Feb 05 00:07:21 rhel.local.lan systemd[1]: Unit wsdd.service entered failed state.
Feb 05 00:07:21 rhel.local.lan systemd[1]: wsdd.service failed.

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

Hi.

When I start wsdd.py, it shows up on all the windows machines on my network.

When I refresh the network screen on the file manager on my window machine the listing goes away and this shows up in the logs:

2020-05-21 20:34:57,186:wsdd INFO(pid 20232): 192.168.1.63:50606(eth0) - - "Probe urn:uuid:acd725de-771e-4100-942f-76eb892f08b9 UDP" - -

While for any other machine on the network the log looks like this:

2020-05-21 20:36:31,646:wsdd INFO(pid 20232): fe80::121:c206:878f:60e6:49667(eth0) - - "Resolve urn:uuid:d1e4ae36-5586-4ca5-90e6-8362f4fc1183 UDP" - -
2020-05-21 20:36:41,645:wsdd INFO(pid 20232): fe80::121:c206:878f:60e6:49667(eth0) - - "Resolve urn:uuid:2a3d4e9e-72ac-4f93-8f75-09ccf3a64d31 UDP" - -
2020-05-21 20:36:43,585:wsdd INFO(pid 20232): fe80::6486:e186:f76b:a362:64998(eth0) - - "Probe urn:uuid:61c51e71-2ee0-4ca9-8ab0-389442736764 UDP" - -
2020-05-21 20:36:43,636:wsdd INFO(pid 20232): fe80::6486:e186:f76b:a362:65000(eth0) - - "Resolve urn:uuid:40efadff-2ef3-4e22-80e5-4bf49d0bc9de UDP" - -
2020-05-21 20:36:43,650:wsdd INFO(pid 20232): fe80::6486:e186:f76b:a362 - - "POST /e8b55173-13b7-5527-9c95-dd5735dbeed0 HTTP/1.1" 200 -

Hi,

Found your tool a couple days ago and I have run into an issue. When I manually run wsdd, it works great. When I reboot, systemd attempts to start it and fails to find a multicast address, or it binds to the virbr0 multicast address. When I disable libvirtd and reboot, it fails to find a usable multicast on eno1. When I specify which interface to use with the -i eno0 flag, it fails to find a usable multicast address to bind to.

After my system is fully booted and I am logged in, I can manually launch it with/without any flags I want and it will work no issues. I have also tried launching a cron job with @reboot in crontab entry and that fails as well with same log output.

Here is my unit file:

# cat /etc/systemd/system/wsdd.service
[Unit]
Description=Web Services Dynamic Discovery host daemon
; Start after the network has been configured
After=network-online.target
Wants=network-online.target
; It makes sense to have Samba running when wsdd starts, but is not required
;Wants=smb.service

[Service]
Type=simple
ExecStart=/usr/bin/wsdd -i eno1 -w WOKRGROUP -vv
; Replace those with an unprivledged user/group that matches your environment,
; like nobody/nogroup or daemon:daemon or a dedicated user for wsdd
User=nobody
Group=nobody
; The following lines can be used for a chroot execution of wsdd.
; Also append '--chroot /run/wsdd/chroot' to ExecStart to enable chrooting
;AmbientCapabilities=CAP_SYS_CHROOT
;ExecStartPre=/usr/bin/install -d -o nobody -g nobody -m 0700 /run/wsdd/chroot
;ExecStopPost=rmdir /run/wsdd/chroot

[Install]
WantedBy=multi-user.target

here is ip addr show

# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether c0:3f:d5:68:2a:4b brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.150/24 brd 10.0.0.255 scope global dynamic noprefixroute eno1
       valid_lft 603733sec preferred_lft 603733sec
    inet6 2601:8c3:4001:3010:c23f:d5ff:fe68:2a4b/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 298sec preferred_lft 298sec
    inet6 fe80::c23f:d5ff:fe68:2a4b/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:46:a2:20 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:46:a2:20 brd ff:ff:ff:ff:ff:ff

With no args and libvirtd running I see this in the logs:

Apr 25 16:49:32 lakota audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=wsdd comm="systemd" exe="/usr/lib/systemd/systemd" ho>
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,945:wsdd WARNING(pid 1449): no interface given, using all interfaces
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,946:wsdd INFO(pid 1449): using pre-defined UUID ff1409e7-8867-51cc-8518-d51b72b8b322
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,954:wsdd DEBUG(pid 1449): ignoring loop-back interface lo
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,954:wsdd DEBUG(pid 1449): ignoring loop-back interface lo
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,954:wsdd DEBUG(pid 1449): ignoring loop-back interface lo
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,955:wsdd INFO(pid 1449): joined multicast group ('239.255.255.250', 3702) on 192.168.122.1%virbr0
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,956:wsdd DEBUG(pid 1449): transport address on virbr0 is 192.168.122.1
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,956:wsdd DEBUG(pid 1449): will listen for HTTP traffic on address ('192.168.122.1', 5357)
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,966:wsdd DEBUG(pid 1449): constructed xml for WSD message: b'<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:pnpx="http:>
Apr 25 16:49:32 lakota wsdd[1449]: 2020-04-25 16:49:32,966:wsdd DEBUG(pid 1449): scheduling Hello message via virbr0 to ('239.255.255.250', 3702)

with no libvirtd or specified interface it fails with:

-- Reboot --
Apr 25 17:26:16 lakota audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=wsdd comm="systemd" exe="/usr/lib/systemd/systemd" ho>
Apr 25 17:26:17 lakota wsdd[1371]: 2020-04-25 17:26:17,251:wsdd INFO(pid 1371): using pre-defined UUID ff1409e7-8867-51cc-8518-d51b72b8b322
Apr 25 17:26:17 lakota wsdd[1371]: 2020-04-25 17:26:17,265:wsdd DEBUG(pid 1371): ignoring loop-back interface lo
Apr 25 17:26:17 lakota wsdd[1371]: 2020-04-25 17:26:17,265:wsdd DEBUG(pid 1371): ignoring loop-back interface lo
Apr 25 17:26:17 lakota wsdd[1371]: 2020-04-25 17:26:17,266:wsdd DEBUG(pid 1371): ignoring loop-back interface lo
Apr 25 17:26:17 lakota wsdd[1371]: 2020-04-25 17:26:17,266:wsdd ERROR(pid 1371): No multicast addresses available. Exiting.
Apr 25 17:26:17 lakota systemd[1]: wsdd.service: Main process exited, code=exited, status=1/FAILURE
Apr 25 17:26:17 lakota systemd[1]: wsdd.service: Failed with result 'exit-code'.

I have looked through the previous issues and found some similar things, but nothing that is exactly what I am seeing. I have verified which branch I downloaded (master) and even tried a couple other branches and tried the Fedora 31 repo dnf install just to see if that helped. Nothing I have tried has fixed it.

Thanks in advance for your help.

wsdd is currently not able to handle changes of interfaces, like new IP addresses as a result of a new DHCP lease or switched networks, addresses become non-tentative (see #18), or the addition or removal of interfaces. Those events can be handled with netlink(7) sockets under Linux, or route(4) sockets under FreeBSD.

This would also prevent DAD race conditions during system boot as observed by users in #18.

Hi. Cheers for the great software, between this and avahi my network is sorted.

Quick question, for active directory, should I use the DNS domain or the NETBIOS domain name with -d?

I just installed this tool under CentOS 8 using dnf install. The program has installed correctly, I've allowed 3702 and 5357 on the server firewall but no windows 10 computers can see it...

Server Specs:

• AMD FX(tm)-4100 Quad-Core Processor
• 8 GB RAM
• G98 [GeForce 8400 GS Rev. 2]
• CentOS 8 (64 bits)
• Hostname: server
• Netbios name: server.local

Client Specs:

• Surface Book 2 15 inch
• Windows 10 x64 PRO

Hi there,
Many thanks for the project.
Would you please be kind to compile the projects with for usual arm targets? I'm currently using a ubuntu 20.04 on pi4, but those bins are not present in your host.

Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://pkg.ltec.ch/public focal InRelease' doesn't support architecture 'arm64'

Please note that the python script works fine for me.

WSD implementations (in general) are said to possibly allow traffic amplification attacks. It has to be checked if wsdd is affected by this as well.

References:

• https://blogs.akamai.com/sitr/2019/09/new-ddos-vector-observed-in-the-wild-wsd-attacks-hitting-35gbps.html
• https://www.zdnet.com/article/protocol-used-by-630000-devices-can-be-abused-for-devastating-ddos-attacks/

Even when wsdd is not, some more remarks should be added to the readme/man page: Do not expose to the internet, check firewall rules.

~$ ./wsdd.py -H 2
Traceback (most recent call last):
  File "/usr/bin/wsdd", line 711, in \<module\>
    main()
  File "/usr/bin/wsdd", line 698, in main
    parse_args()
  File "/usr/bin/wsdd", line 585, in parse_args
    args = parser.parse_args(sys.argv[1:])
  File "/usr/lib/python3.5/argparse.py", line 1735, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python3.5/argparse.py", line 1767, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python3.5/argparse.py", line 1973, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/lib/python3.5/argparse.py", line 1913, in consume_optional
    take_action(action, args, option_string)
  File "/usr/lib/python3.5/argparse.py", line 1841, in take_action
    action(self, namespace, argument_values, option_string)
  File "/usr/lib/python3.5/argparse.py", line 959, in __call__
    items.append(values)
AttributeError: 'int' object has no attribute 'append'

I don't know python well enough to easily see if this causes problems in functionality elsewhere (maybe you're wanting to append it so you can set a hop limit per interface or something?), but I can make it stop throwing errors at me:

--- wsdd.py
+++ wsdd-fixed.py
@@ -548,7 +548,7 @@
     parser.add_argument(
         '-H', '--hoplimit',
         help='hop limit for multicast packets (default = 1)',
-        action='append', default=1)
+        type=int, default=1)
     parser.add_argument(
         '-u', '--uuid',
         help='UUID for the target device',

If it's at all relevant:

~$ python3 -V
Python 3.7.1

Hello,

I was wondering if you would consider making wsdd available as a Gentoo ebuild. Currently there is no wsd daemon in Gentoo and I think a lot of people would find your wsdd very useful.

Thank you.

Hi,

today I found that WSDD service throws error at startup. This is what I get when I run following command:

systemctl status wsdd

and result is:

Oct 10 20:59:45 raspberrypi wsdd[664]: super().init(mch.listen_address, RequestHandlerClass)
Oct 10 20:59:45 raspberrypi wsdd[664]: File "/usr/lib/python3.7/socketserver.py", line 452, in init
Oct 10 20:59:45 raspberrypi wsdd[664]: self.server_bind()
Oct 10 20:59:45 raspberrypi wsdd[664]: File "/usr/bin/wsdd", line 805, in server_bind
Oct 10 20:59:45 raspberrypi wsdd[664]: super().server_bind()
Oct 10 20:59:45 raspberrypi wsdd[664]: File "/usr/lib/python3.7/http/server.py", line 137, in server_bind
Oct 10 20:59:45 raspberrypi wsdd[664]: socketserver.TCPServer.server_bind(self)
Oct 10 20:59:45 raspberrypi wsdd[664]: File "/usr/lib/python3.7/socketserver.py", line 466, in server_bind
Oct 10 20:59:45 raspberrypi wsdd[664]: self.socket.bind(self.server_address)
Oct 10 20:59:45 raspberrypi wsdd[664]: socket.gaierror: [Errno -9] Address family for hostname not supported

I has a latest version of WSDD and I run it on Raspberry Pi 3B+ and Buster.

A D-Bus interface would be particularly useful for applications to be able to do service discovery using wsdd. gvfs, the user-space filesystem used by GNOME and others, could use it to find Windows 10 SMB machines on the local network (see https://gitlab.gnome.org/GNOME/gvfs/-/issues/506)

Hello,
Not an issue but I just couldn't find an mail address for my request.

I have created files to generate a wsdd Debian package. The package installs wsdd as service unit. wsdd's command line parameters are configurable by the file /etc/wsdd.conf.
It would be my pleasure to contribute this to wsdd.

regards Felix

To be honest i'm not even sure that I'm using this correctly I wanted to discover the share on my network from my linux machine I started with wsdd -D -i wlp2s0 hoping it would just spit out a list of shares on my network but instead I the following error and it hangs forever. I'm using the aur package which is version 0.6.1

Thanks,

2020-09-08 21:01:57,093:wsdd WARNING(pid 9093): Discovery enabled but no listen option provided. Falling back to port 5359
2020-09-08 21:02:00,274:wsdd ERROR(pid 9093): error in main loop
Traceback (most recent call last):
  File "/usr/bin/wsdd", line 1630, in main
    key.data.handle_request(key)
  File "/usr/bin/wsdd", line 170, in handle_request
    handler.handle_request(msg, address)
  File "/usr/bin/wsdd", line 518, in handle_request
    self.handle_message(msg, self.mch, address)
  File "/usr/bin/wsdd", line 348, in handle_message
    retval = handler(header, body)
  File "/usr/bin/wsdd", line 558, in handle_probe_match
    self.perform_metadata_exchange(endpoint, xaddr)
  File "/usr/bin/wsdd", line 606, in perform_metadata_exchange
    self.handle_metadata(stream.read(), endpoint, xaddr)
  File "/usr/bin/wsdd", line 619, in handle_metadata
    self.known_devices[device_uuid] = WSDDiscoveredDevice(
  File "/usr/bin/wsdd", line 424, in __init__
    self.update(xml_str, xaddr, interface)
  File "/usr/bin/wsdd", line 454, in update
    self.props['DisplayName'], self.props['BelongsTo'], addr,
KeyError: 'DisplayName'

updated makefile (only affected lines shown)

ifneq (,$(wildcard /etc/systemd/system/.))
install -o root -g root etc/systemd/wsdd.service /etc/systemd/system
else
install -o root -g root etc/rc.d/wsdd /etc/init.d
endif

In etc/systemd/wsdd.service, change /usr/bin to /usr/local/bin (or change the install above to /usr/bin)

ExecStart=/usr/local/bin/wsdd --shortlog

I give my interfaces names based on position in the computer, and so my main interface is ‘lower0’.

Unfortunately this interface would be excluded by .startswith('lo'), even if the interface were specified with the -i option.

Windows does not show the wsdd host after reboot. If you restart wsdd, then it is shown in Windows Explorer again.

See https://forum.openmediavault.org/index.php/Thread/26324-Windows-10-Build-1809-und-OMV-Shares-sind-in-der-Netzwerkumgebung-verf%C3%BCgbar/?postID=199653#post199653

First, let me say that this is a great creation.

I have a couple of firewalld files that might be of interest to those running on Fedora, and the like. The ones that come in the Fedora 32 package do not work (no multicast address). They are xml files can go in /usr/lib/firewalld/services (or /etc/firewalld/services). They are "wsdd.xml" and "wsdd-http.xml" (first includes the second - so just one service to add to the firewall).

On the problems with the bridge/multiple interface issues with Linux, I think the duplication problem is because the kernel does some not so standard stuff with multicast messages, that can be turned off with a special ioctl (IP_MULTICAST_ALL). The problem is mentioned here:
Why are multicast messages on the same port but from different groups combined?
So I turned off IP_MULTICAST_ALL on the mc listener socket, and and then I can run straight up with multiple interfaces with no duplicate responses.

I put this change in the attached patch file (based on 0.6.1), along with some changes from logger.warn -> logger.warning (obsolete interface). I tested this on my very small vm environment (Fedora 32 (real - 2 interfaces) with Windows 10 (virtual) and Fedora 31 (virtual) seems to work - no dups, Windows sees both Linux machines.

Finally, there's one rare problem that I did run across. Wsdd handles address changes & missing devices nicely, except in the case where one actually deletes the device and recreates it. What seems to happen is that the OS actually does away with the underlying socket. So, when brought up again, even though wsdd will see a new address indication, it's really listening to nothing. To do this correctly, I think you would really have to listen for RTM_DELLINK on the netlink socket, remove the listener, mark the interface dead, probably issue a new Hello when recreated.

Stew

Attached 3 files:

wsdd.xml.txt
wsdd-http.xml.txt
wsdd-linux_ip_multicast_all.patch.txt

environment:
raspberrypi 4
OS: Buster Lite
Installed samba server

I followed your instructions:

1. mkdir /usr/bin/wssd
2. wget https://raw.githubusercontent.com/christgau/wsdd/master/src/wsdd.py
3. mv wsdd.py wsdd
4. chmod +x wsdd
5. run it ./wsdd -i eth0 -4

It now just hangs. Nothing happens. No errors. Nothing. Just sits there and I have to Ctrl-C to break out.

Am I doing something wrong? Thank you!

I currently use ufw on Debian 10. How to set rules for the below for my local network? Sorry but new to this.

Both incoming and outgoing multicast traffic on port 3702 must be allowed. For IPv4, the multicast address is 239.255.255.250, for IPv6 the link local SSDP multicast address (fe02::c) is used.

Incoming TCP traffic (and related outgoing traffic) on port 5357 must be allowed.

hi,
I've successfully install the wsdd deamon on a Debian 9.6 with OpenMediaVault 4.1.15. I can now see my NAS from all my Windows 10 workstations. Great job !

I've a cyclic log in syslog :

Dec 19 15:59:16 gayavault wsdd[22668]: 2018-12-19 15:59:16,630:wsdd INFO(pid 22668): handling WSD http://schemas.xmlsoap.org/ws/2005/04/discovery/Resolve type message (urn:uuid:361022dd-a158-424b-86e2-91d4c818865b)
Dec 19 15:59:16 gayavault wsdd[22668]: 2018-12-19 15:59:16,631:wsdd ERROR(pid 22668): error in main loop
Dec 19 15:59:16 gayavault wsdd[22668]: Traceback (most recent call last):
Dec 19 15:59:16 gayavault wsdd[22668]: File "/usr/bin/wsdd", line 680, in serve_wsd_requests
Dec 19 15:59:16 gayavault wsdd[22668]: key.data.handle_request()
Dec 19 15:59:16 gayavault wsdd[22668]: File "/usr/bin/wsdd", line 415, in handle_request
Dec 19 15:59:16 gayavault wsdd[22668]: msg = wsd_handle_message(msg, self.interface)
Dec 19 15:59:16 gayavault wsdd[22668]: File "/usr/bin/wsdd", line 396, in wsd_handle_message
Dec 19 15:59:16 gayavault wsdd[22668]: wsd_handle_resolve(resolve, interface.transport_address))
Dec 19 15:59:16 gayavault wsdd[22668]: File "/usr/bin/wsdd", line 295, in wsd_handle_resolve
Dec 19 15:59:16 gayavault wsdd[22668]: raise ValueError('invalid resolve request: address does not match')
Dec 19 15:59:16 gayavault wsdd[22668]: ValueError: invalid resolve request: address does not match

Can i help to understand and to manage this exception ?

Thank you.
Jean-Christophe

I would like to announce multiple devices from another network segment since the VPN wont forward site-local multicast.

Can wsdd be modified to announce multiple Hostname<->IP devices?

Perhaps it could be provided as a "hosts" file format for a simple first implementation:

192.168.10.11   host1
192.168.10.12   host2
...

Alternatively, could wsdd implement a proxy such that they could coordinate and forward the announcements?

I am using linux mint 19.1. Thes service just works find with the system booted up and the command "sudo systemctl start wsdd". But Systemd throws the following error when started automatically in the boot process:

● wsdd.service - Web Services Dynamic Discovery host daemon
Loaded: loaded (/etc/systemd/system/wsdd.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Fri 2019-03-08 10:09:46 CET; 28min ago
Process: 880 ExecStart=/usr/bin/wsdd -4 -i enp2s0 (code=exited, status=0/SUCCESS)
Main PID: 880 (code=exited, status=0/SUCCESS)

mar 08 10:09:45 TALLER05 systemd[1]: Started Web Services Dynamic Discovery host daemon.
mar 08 10:09:45 TALLER05 wsdd[880]: 2019-03-08 10:09:45,978:wsdd ERROR(pid 880): No multicast addresses available. Exiting

Do i have to require some other service in wsdd.service file? my service file is:

[Unit]
Description=Web Services Dynamic Discovery host daemon
Requires=network.target
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/wsdd -4 -i enp2s0
#User=nobody
#Group=nobody

[Install]
WantedBy=multi-user.target

It would be nice if /etc/conf.d/wsdd was supported to set command arguments to wsdd

Add:
/etc/conf.d/wsdd
WSDD_OPTS="-i eth1"

Change
/etc/init.d/wsdd
OPTS="-w ${GROUP} ${OPTS}" to OPTS="-w ${GROUP} ${WSDD_OPTS}"

I am not sure how to do this with systemd.

I would like to get this included in the official portage repo. Has this been attempted? Would you be opposed? I can send a PR to official gentoo if you want with the ebuilds.

Thanks!

$ sudo -s
$ echo "deb https://pkg.ltec.ch/public/ " lsb_release -c | cut -f2 " main" >> /etc/apt/sources.list
$ apt-key adv --fetch-keys https://pkg.ltec.ch/public/conf/ltec-ag.gpg.key
$ apt update
$ apt install wsdd
$ service wsdd start

I couldn't get the wsdd.service unit to work on startup, it would fail with the following:

oct 04 14:10:31 principal python3[849]: detected unhandled Python exception in '/usr/local/bin/wsdd'
oct 04 14:10:31 principal wsdd[849]: Traceback (most recent call last):
oct 04 14:10:31 principal wsdd[849]:   File "/usr/local/bin/wsdd", line 840, in <module>
oct 04 14:10:31 principal wsdd[849]:     sys.exit(main())
oct 04 14:10:31 principal wsdd[849]:   File "/usr/local/bin/wsdd", line 833, in main
oct 04 14:10:31 principal wsdd[849]:     retval = serve_wsd_requests(addresses)
oct 04 14:10:31 principal wsdd[849]:   File "/usr/local/bin/wsdd", line 776, in serve_wsd_requests
oct 04 14:10:31 principal wsdd[849]:     http_srv = klass(interface.listen_address, WSDHttpRequestHandler)
oct 04 14:10:31 principal wsdd[849]:   File "/usr/lib64/python3.7/socketserver.py", line 452, in __init__
oct 04 14:10:31 principal wsdd[849]:     self.server_bind()
oct 04 14:10:31 principal wsdd[849]:   File "/usr/local/bin/wsdd", line 64, in server_bind
oct 04 14:10:31 principal wsdd[849]:     super().server_bind()
oct 04 14:10:31 principal wsdd[849]:   File "/usr/lib64/python3.7/http/server.py", line 137, in server_bind
oct 04 14:10:31 principal wsdd[849]:     socketserver.TCPServer.server_bind(self)
oct 04 14:10:31 principal wsdd[849]:   File "/usr/lib64/python3.7/socketserver.py", line 466, in server_bind
oct 04 14:10:31 principal wsdd[849]:     self.socket.bind(self.server_address)
oct 04 14:10:31 principal wsdd[849]: OSError: [Errno 99] Cannot assign requested address

I went ahead and added a time.sleep(10) right after parse_args() on main() as a stop gap measure, but there's got to be a proper fix.

I'm using Ubuntu 18.04 desktop for my samba shares. I've set wsdd up as a service and when I run sudo systemctl start wsdd it works great and I can see my server from my Windows 10 machine (Explorer > Network).

But when Ubuntu reboots, I can't see the share from Windows. See log below. I've done systemctl daemon-reload, systemctl start wsdd and systemctl enable wsdd. In the wsdd.service I'm using User=nobody and Group=nogroup.

When I run systemctl start wsdd (without sudo) it asks me for authentication.

When I run sudo systemctl status wsdd it says wsdd[1737]: WARNING: no interface given, using all interfaces

Any ideas what I'm doing wrong?

wsdd[1332]: Traceback (most recent call last):
wsdd[1332]:   File "/usr/bin/wsdd", line 846, in <module>
wsdd[1332]:     sys.exit(main())
wsdd[1332]:   File "/usr/bin/wsdd", line 839, in main
wsdd[1332]:     retval = serve_wsd_requests(addresses)
wsdd[1332]:   File "/usr/bin/wsdd", line 782, in serve_wsd_requests
wsdd[1332]:     http_srv = klass(interface.listen_address, WSDHttpRequestHandler)
wsdd[1332]:   File "/usr/lib/python3.6/socketserver.py", line 456, in __init__
wsdd[1332]:     self.server_bind()
wsdd[1332]:   File "/usr/bin/wsdd", line 64, in server_bind
wsdd[1332]:     super().server_bind()
wsdd[1332]:   File "/usr/lib/python3.6/http/server.py", line 136, in server_bind
wsdd[1332]:     socketserver.TCPServer.server_bind(self)
wsdd[1332]:   File "/usr/lib/python3.6/socketserver.py", line 470, in server_bind
wsdd[1332]:     self.socket.bind(self.server_address)
wsdd[1332]: OSError: [Errno 99] Cannot assign requested address
systemd[1]: wsdd.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: wsdd.service: Failed with result 'exit-code'.

Server: FreeBSD 11.4 x64
Client: Windows 7 Professional SP1 x64
wsdd version: 0.6

Server: interface em0 = 192.168.1.51
Client: 192.168.1.50

Both systems are bare-metal, and on the same physical lan segment. No virtualisation is involved. While the machines have IPs in private space, NAT is only involved if/when packets go out the default gateway and through an unrelated router; NAT concerns therefore should not apply here.

On W7, I've verified -- and tried repeatedly restarting -- the "Function Discovery Resource Publication" (FDResPub) and "Function Discovery Provider Host" (fdPHost) services to no avail.

wsdd is started as: /usr/local/bin/python3.7 /usr/local/bin/wsdd -w WORKGROUP -4 -i em0 -v -v -v

Let's see what ports/IPs it's listening on:

daemon   python3.7  86702 6  udp4   239.255.255.250:3702  *:*
daemon   python3.7  86702 7  udp4   *:16702               *:*
daemon   python3.7  86702 8  tcp4   192.168.1.51:5357     *:*

wsdd starts up and emits the following messages (please ignore the daemon part of the syslog message; this is a FreeBSD-ism and not your fault):

Jun 22 20:22:26 icarus daemon[86701]: 2020-06-22 20:22:26,550:wsdd DEBUG(pid 86702): new address 192.168.1.51 on em0
Jun 22 20:22:26 icarus daemon[86701]: 2020-06-22 20:22:26,551:wsdd DEBUG(pid 86702): handling traffic for 192.168.1.51 on em0
Jun 22 20:22:26 icarus daemon[86701]: 2020-06-22 20:22:26,551:wsdd INFO(pid 86702): joined multicast group ('239.255.255.250', 3702) on 192.168.1.51%em0
Jun 22 20:22:26 icarus daemon[86701]: 2020-06-22 20:22:26,551:wsdd DEBUG(pid 86702): transport address on em0 is 192.168.1.51
Jun 22 20:22:26 icarus daemon[86701]: 2020-06-22 20:22:26,551:wsdd DEBUG(pid 86702): will listen for HTTP traffic on address ('192.168.1.51', 5357)
Jun 22 20:22:26 icarus daemon[86701]: 2020-06-22 20:22:26,552:wsdd DEBUG(pid 86702): constructed xml for WSD message: b'<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:pnpx="http://schemas.microsoft.com/windows/pnpx/2005/10" xmlns:pub="http://schemas.microsoft.com/windows/pub/2005/07" xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex"><soap:Header><wsa:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Hello</wsa:Action><wsa:MessageID>urn:uuid:c3110579-b500-11ea-91da-003048d222d0</wsa:MessageID><wsd:AppSequence InstanceId="1592882546" MessageNumber="0" SequenceId="urn:uuid:c3110785-b500-11ea-91da-003048d222d0" /></soap:Header><soap:Body><wsd:Hello><wsa:EndpointReference><wsa:Address>urn:uuid:2c2c4f89-43b2-5a0d-b73a-e622360b0358</wsa:Address></wsa:EndpointReference><wsd:XAddrs>http://192.168.1.51:5357/2c2c4f89-43b2-5a0d-b73a-e622360b0358</wsd:XAddrs><wsd:MetadataVersion>1</wsd:MetadataVersion></wsd:Hello></soap:Body></soap:Envelope>'
Jun 22 20:22:26 icarus daemon[86701]: 2020-06-22 20:22:26,553:wsdd DEBUG(pid 86702): scheduling Hello message via em0 to ('239.255.255.250', 3702)

Now on the Windows 7 client, I initiate a Shift-Refresh in the Network Neighbourhood window. We see the following in the wsdd log, but the server never appears on the client.

Jun 22 20:22:26 icarus daemon[86701]: 2020-06-22 20:22:26,553:wsdd DEBUG(pid 86702): scheduling Hello message via em0 to ('239.255.255.250', 3702)
Jun 22 20:22:58 icarus daemon[86701]: 2020-06-22 20:22:58,629:wsdd INFO(pid 86702): 192.168.1.50:61316(em0) - - "Probe urn:uuid:8228b1c5-e4e0-48f8-9b6b-418986a1ad0c UDP" - -
Jun 22 20:22:58 icarus daemon[86701]: 2020-06-22 20:22:58,629:wsdd DEBUG(pid 86702): incoming message content is b'<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof"><soap:Header><wsa:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</wsa:Action><wsa:MessageID>urn:uuid:8228b1c5-e4e0-48f8-9b6b-418986a1ad0c</wsa:MessageID></soap:Header><soap:Body><wsd:Probe><wsd:Types>wsdp:Device</wsd:Types></wsd:Probe></soap:Body></soap:Envelope>'
Jun 22 20:22:58 icarus daemon[86701]: 2020-06-22 20:22:58,630:wsdd DEBUG(pid 86702): constructed xml for WSD message: b'<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:pnpx="http://schemas.microsoft.com/windows/pnpx/2005/10" xmlns:pub="http://schemas.microsoft.com/windows/pub/2005/07" xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex"><soap:Header><wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches</wsa:Action><wsa:MessageID>urn:uuid:d62fa52e-b500-11ea-91da-003048d222d0</wsa:MessageID><wsa:RelatesTo>urn:uuid:8228b1c5-e4e0-48f8-9b6b-418986a1ad0c</wsa:RelatesTo><wsd:AppSequence InstanceId="1592882546" MessageNumber="1" SequenceId="urn:uuid:d62fa7fd-b500-11ea-91da-003048d222d0" /></soap:Header><soap:Body><wsd:ProbeMatches><wsd:ProbeMatch><wsa:EndpointReference><wsa:Address>urn:uuid:2c2c4f89-43b2-5a0d-b73a-e622360b0358</wsa:Address></wsa:EndpointReference><wsd:Types>wsdp:Device pub:Computer</wsd:Types><wsd:MetadataVersion>1</wsd:MetadataVersion></wsd:ProbeMatch></wsd:ProbeMatches></soap:Body></soap:Envelope>'
Jun 22 20:22:58 icarus daemon[86701]: 2020-06-22 20:22:58,676:wsdd INFO(pid 86702): 192.168.1.50:61318(em0) - - "Resolve urn:uuid:4a35450f-4543-43e0-b442-65cfcfa84a42 UDP" - -
Jun 22 20:22:58 icarus daemon[86701]: 2020-06-22 20:22:58,676:wsdd DEBUG(pid 86702): incoming message content is b'<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery"><soap:Header><wsa:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Resolve</wsa:Action><wsa:MessageID>urn:uuid:4a35450f-4543-43e0-b442-65cfcfa84a42</wsa:MessageID></soap:Header><soap:Body><wsd:Resolve><wsa:EndpointReference><wsa:Address>urn:uuid:2c2c4f89-43b2-5a0d-b73a-e622360b0358</wsa:Address></wsa:EndpointReference></wsd:Resolve></soap:Body></soap:Envelope>'
Jun 22 20:22:58 icarus daemon[86701]: 2020-06-22 20:22:58,677:wsdd DEBUG(pid 86702): constructed xml for WSD message: b'<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:pnpx="http://schemas.microsoft.com/windows/pnpx/2005/10" xmlns:pub="http://schemas.microsoft.com/windows/pub/2005/07" xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex"><soap:Header><wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/ResolveMatches</wsa:Action><wsa:MessageID>urn:uuid:d636cdda-b500-11ea-91da-003048d222d0</wsa:MessageID><wsa:RelatesTo>urn:uuid:4a35450f-4543-43e0-b442-65cfcfa84a42</wsa:RelatesTo><wsd:AppSequence InstanceId="1592882546" MessageNumber="2" SequenceId="urn:uuid:d636d01b-b500-11ea-91da-003048d222d0" /></soap:Header><soap:Body><wsd:ResolveMatches><wsd:ResolveMatch><wsa:EndpointReference><wsa:Address>urn:uuid:2c2c4f89-43b2-5a0d-b73a-e622360b0358</wsa:Address></wsa:EndpointReference><wsd:Types>wsdp:Device pub:Computer</wsd:Types><wsd:XAddrs>http://192.168.1.51:5357/2c2c4f89-43b2-5a0d-b73a-e622360b0358</wsd:XAddrs><wsd:MetadataVersion>1</wsd:MetadataVersion></wsd:ResolveMatch></wsd:ResolveMatches></soap:Body></soap:Envelope>'
Jun 22 20:22:58 icarus daemon[86701]: 2020-06-22 20:22:58,809:wsdd DEBUG(pid 86702): known message (urn:uuid:4a35450f-4543-43e0-b442-65cfcfa84a42): dropping it
Jun 22 20:22:58 icarus daemon[86701]: 2020-06-22 20:22:58,867:wsdd DEBUG(pid 86702): known message (urn:uuid:8228b1c5-e4e0-48f8-9b6b-418986a1ad0c): dropping it

And that's it. I see no other logs from wsdd.

If we do a packet capture on the server via tcpdump -p -i em0 -l -n "host 192.168.1.51", we see two-way packet communication, until the server sends the client some UDP payload and then nothing past that happens. Please note this capture was for a different request than the one shown above, but the behaviour/etc. is identical every time:

20:35:40.574272 IP 192.168.1.51.16702 > 192.168.1.50.50581: UDP, length 1247
20:35:40.619179 IP 192.168.1.51.16702 > 192.168.1.50.50583: UDP, length 1343
20:35:40.620956 IP 192.168.1.50.53384 > 192.168.1.51.5357: Flags [S], seq 631281493, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
20:35:40.620976 IP 192.168.1.51.5357 > 192.168.1.50.53384: Flags [S.], seq 1520944053, ack 631281494, win 65535, options [mss 1460,nop,wscale 7,sackOK,eol], length 0
20:35:40.621080 IP 192.168.1.50.53384 > 192.168.1.51.5357: Flags [.], ack 1, win 16425, length 0
20:35:40.621209 IP 192.168.1.50.53384 > 192.168.1.51.5357: Flags [P.], seq 1:220, ack 1, win 16425, length 219
20:35:40.621330 IP 192.168.1.50.53384 > 192.168.1.51.5357: Flags [P.], seq 220:953, ack 1, win 16425, length 733
20:35:40.621339 IP 192.168.1.51.5357 > 192.168.1.50.53384: Flags [.], ack 953, win 505, length 0
20:35:40.721580 IP 192.168.1.51.16702 > 192.168.1.50.50581: UDP, length 1247
20:35:40.851109 IP 192.168.1.51.16702 > 192.168.1.50.50583: UDP, length 1343

This problem is 100% reproducible consistently, so troubleshooting should be possible.

Do you have any thoughts on what could be wrong?

Hello,
I have been trying to get this to work now on three systems (1VM, 1 RPi and 1 NAS (All on Alpine Linux)) and all have the same behaviour, Windows clients only see the host once after the service starts.
Every client/host is configured with a static IP and running on IPv4 only mode.

As soon as any client tries a network refresh (as in either pressing F5 or the refresh button in the explorer) the host disappears from the list and never shows up again, also not after a reboot of the client, until the service is restarted on the host.

The wsdd daemon runs with the following flags: "-4 -i eth1"
The log also only shows the POST only once and then never shows anything after that until restart of the daemon.

Is there anything I missed in setting it up? Am I the only one having that problem?
I read the other issues that might be related to this but that I could have tried I tried.

Alpine Linux uses OpenRC so no systemd. And I allow everything through iptables that needs it and it "works" but basically only once and after that it's going back to entering either the hostname or the IP address.

Specifying both -i eth1 and -4 works fine,
just with a minor issue, the name and domain name are ALL CAPS.
NETBIOS is all ALL CAPS only, but WSD is not.
(log 4)

Following tests don't show the machine running wsdd, "Ubuntu", on a machine trying to see the first one, "Win10".

Without specifying "-4", (with or without -i eth1), "Probe" is received on IP6 (once on IP4), sometimes "Resolve" from IP6 follows on next line, (I didn't allow IP6 on eth1 adapter but the settings on QNAP seems dodgy on this anyway), no "POST" follows
(log 1)

Specifying "-4", but without specifying "-i eth1"
"Resolve" always follows "Probe", no "POST". Both Resolve and Probe reports IP address used by eth1, (192.168.8.103:65295(eth0)), while eth0 is on 10.0.5.239
(log 2)

Specifying -i eth0 will pass no "Probe" which is expected as NAT (to which eth0 is plugged) will not translate a broadcast,
but log in above case shows eth0
(log 3)

Before each "Probe" line in logs below, I issued a refresh on Win10 (File Explorer > Network > refresh button)
Only log section with both -4 and -i eth1 specified, showed Ubuntu on Win10's Network tab in File Explorer

The "Ubuntu" is LXC (chroot, ...) running on QNAP NAS (so-called Linux Station feature)
Ubuntu was assigned two network "cards". The NAS decided how to use them, but it works and I didn't bother to try changing it.
eth0, is "plugged-in" to Virtual Switch with NAT and DHCP servers, but has higher metric (should not be used as a gateway)
eth1 is connected to PHY - real Network Adapter

I didn't turn on IP6 on neither PHY, nor the Virtual Switch. It's a choice in the NAS Settings. I can turn it on for test if needed.

Win10 is Windows Pro 10 1809

log 1

no -i no -4

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -n huhu -v -s -w WORKGROUP
WARNING: no interface given, using all interfaces
INFO: using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
INFO: joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
INFO: joined multicast group ('239.255.255.250', 3702) on 10.0.5.239%eth0
INFO: joined multicast group ('ff02::c', 3702, 22364, 158) on fe80::7b6b:82a0:1475:6160%eth1
INFO: joined multicast group ('ff02::c', 3702, 22364, 160) on fe80::83e:e1e9:d627:a983%eth0
INFO: fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:123c3105-12d8-4ab4-89da-6a704d8961a7 UDP" - -
INFO: fe80::5d27:ee50:5c54:3db%eth1:65296(eth1) - - "Resolve urn:uuid:120f9043-ac05-4e6a-aeca-fac8d58bb093 UDP" - -

admin@ubuntu_1804:/etc/systemd$ sudo /usr/bin/wsdd -n huhu -v -s -w WORKGROUP
[sudo] password for admin:
WARNING: no interface given, using all interfaces
INFO: using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
INFO: joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
INFO: joined multicast group ('239.255.255.250', 3702) on 10.0.5.239%eth0
INFO: joined multicast group ('ff02::c', 3702, 22364, 158) on fe80::7b6b:82a0:1475:6160%eth1
INFO: joined multicast group ('ff02::c', 3702, 22364, 160) on fe80::83e:e1e9:d627:a983%eth0
INFO: fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:9359d205-eea7-42d9-b084-97937d0f9cfa UDP" - -

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -v
2019-06-10 02:20:59,795:wsdd WARNING(pid 17695): no interface given, using all interfaces
2019-06-10 02:20:59,795:wsdd INFO(pid 17695): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 02:20:59,808:wsdd INFO(pid 17695): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 02:20:59,874:wsdd INFO(pid 17695): joined multicast group ('239.255.255.250', 3702) on 10.0.5.239%eth0
2019-06-10 02:20:59,943:wsdd INFO(pid 17695): joined multicast group ('ff02::c', 3702, 22364, 158) on fe80::7b6b:82a0:1475:6160%eth1
2019-06-10 02:20:59,947:wsdd INFO(pid 17695): joined multicast group ('ff02::c', 3702, 22364, 160) on fe80::83e:e1e9:d627:a983%eth0
2019-06-10 02:21:10,621:wsdd INFO(pid 17695): fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:feaa365e-71cb-4876-9638-ef78aefea373 UDP" - -

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -v
2019-06-10 03:22:32,962:wsdd WARNING(pid 23565): no interface given, using all interfaces
2019-06-10 03:22:32,963:wsdd INFO(pid 23565): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 03:22:32,977:wsdd INFO(pid 23565): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 03:22:33,061:wsdd INFO(pid 23565): joined multicast group ('239.255.255.250', 3702) on 10.0.5.239%eth0
2019-06-10 03:22:33,111:wsdd INFO(pid 23565): joined multicast group ('ff02::c', 3702, 22364, 158) on fe80::7b6b:82a0:1475:6160%eth1
2019-06-10 03:22:33,115:wsdd INFO(pid 23565): joined multicast group ('ff02::c', 3702, 22364, 160) on fe80::83e:e1e9:d627:a983%eth0
2019-06-10 03:22:40,026:wsdd INFO(pid 23565): fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:e1a29ed7-6346-442e-a213-414c806c3528 UDP" - -
2019-06-10 03:23:04,700:wsdd INFO(pid 23565): fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:e7f03eac-953a-4203-be34-596739f595d9 UDP" - -

-i eth1

admin@ubuntu_1804:/etc/systemd$ sudo /usr/bin/wsdd -i eth1 -n huhu -v -w WORKGROUP
2019-06-10 01:56:29,087:wsdd INFO(pid 15289): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 01:56:29,099:wsdd INFO(pid 15289): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 01:56:29,180:wsdd INFO(pid 15289): joined multicast group ('ff02::c', 3702, 22364, 158) on fe80::7b6b:82a0:1475:6160%eth1
2019-06-10 01:56:44,450:wsdd INFO(pid 15289): fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:ea5430dc-8f81-4375-9a6f-372a74a55355 UDP" - -

admin@ubuntu_1804:/etc/systemd$ sudo /usr/bin/wsdd -i eth1 -v
2019-06-10 02:16:45,590:wsdd INFO(pid 17268): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 02:16:45,602:wsdd INFO(pid 17268): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 02:16:45,682:wsdd INFO(pid 17268): joined multicast group ('ff02::c', 3702, 22364, 158) on fe80::7b6b:82a0:1475:6160%eth1
2019-06-10 02:16:49,373:wsdd INFO(pid 17268): fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:5e488cbe-5324-4273-b268-a06601bd830c UDP" - -
2019-06-10 02:17:00,176:wsdd INFO(pid 17268): fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:fa2e1279-60fb-464f-ab47-c84ad6e6937d UDP" - -

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -i eth1 -v
2019-06-10 03:01:36,405:wsdd INFO(pid 21587): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 03:01:36,470:wsdd INFO(pid 21587): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 03:01:46,574:wsdd INFO(pid 21587): joined multicast group ('ff02::c', 3702, 22364, 158) on fe80::7b6b:82a0:1475:6160%eth1
2019-06-10 03:01:46,579:wsdd INFO(pid 21587): 192.168.8.103:53385(eth1) - - "Probe urn:uuid:1dc6b942-c9c3-4e3d-9d0e-8c7454d12adf UDP" - -
2019-06-10 03:01:46,640:wsdd INFO(pid 21587): fe80::5d27:ee50:5c54:3db%eth1:65296(eth1) - - "Resolve urn:uuid:8997a8fd-451c-496c-b2c3-dba07eba7145 UDP" - -

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -i eth1 -v
2019-06-10 03:14:43,779:wsdd INFO(pid 22823): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 03:14:43,792:wsdd INFO(pid 22823): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 03:14:43,926:wsdd INFO(pid 22823): joined multicast group ('ff02::c', 3702, 22364, 158) on fe80::7b6b:82a0:1475:6160%eth1
2019-06-10 03:14:55,296:wsdd INFO(pid 22823): fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:3b53c12f-eb3d-49aa-ac0d-270abf9d659c UDP" - -
2019-06-10 03:15:29,065:wsdd INFO(pid 22823): fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:1350dc38-d2bd-48ae-975a-b697c80938e2 UDP" - -
2019-06-10 03:16:28,492:wsdd INFO(pid 22823): fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:b0137695-cdc4-4783-93fa-d6c4ecc3f44a UDP" - -

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -i eth1 -v
2019-06-10 03:16:58,829:wsdd INFO(pid 23039): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 03:16:58,849:wsdd INFO(pid 23039): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 03:16:58,896:wsdd INFO(pid 23039): joined multicast group ('ff02::c', 3702, 22364, 158) on fe80::7b6b:82a0:1475:6160%eth1
2019-06-10 03:17:02,980:wsdd INFO(pid 23039): fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:1ffcf024-97c0-402a-b624-5b24a8f40f4b UDP" - -

log 2

-4

admin@ubuntu_1804:/etc/systemd$ sudo /usr/bin/wsdd -4 -v -w WORKGROUP
2019-06-10 02:10:40,599:wsdd WARNING(pid 16637): no interface given, using all interfaces
2019-06-10 02:10:40,600:wsdd INFO(pid 16637): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 02:10:40,614:wsdd INFO(pid 16637): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 02:10:40,696:wsdd INFO(pid 16637): joined multicast group ('239.255.255.250', 3702) on 10.0.5.239%eth0
2019-06-10 02:11:01,225:wsdd INFO(pid 16637): 192.168.8.103:53385(eth0) - - "Probe urn:uuid:e3313fa9-48a2-4f93-bf3d-47456493815b UDP" - -
2019-06-10 02:11:02,609:wsdd INFO(pid 16637): 192.168.8.103:65295(eth0) - - "Resolve urn:uuid:c40c4b6b-7800-402e-b8d9-aeb6bfcb668e UDP" - -
2019-06-10 02:11:38,748:wsdd INFO(pid 16637): 192.168.8.103:53385(eth0) - - "Probe urn:uuid:946871aa-e14b-4eee-aef3-8399fc4bbf40 UDP" - -
2019-06-10 02:11:41,275:wsdd INFO(pid 16637): 192.168.8.103:65295(eth0) - - "Resolve urn:uuid:caad32b7-aadb-4816-89f1-a563cbb643a1 UDP" - -

admin@ubuntu_1804:/etc/systemd$ sudo /usr/bin/wsdd -n Huhu -4 -v -w WORKGROUP
2019-06-10 02:13:17,009:wsdd WARNING(pid 16894): no interface given, using all interfaces
2019-06-10 02:13:17,010:wsdd INFO(pid 16894): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 02:13:17,026:wsdd INFO(pid 16894): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 02:13:17,094:wsdd INFO(pid 16894): joined multicast group ('239.255.255.250', 3702) on 10.0.5.239%eth0
2019-06-10 02:13:20,665:wsdd INFO(pid 16894): 192.168.8.103:53385(eth0) - - "Probe urn:uuid:3b87cab4-f803-4caf-a94e-6b16996ae9e2 UDP" - -
2019-06-10 02:13:21,856:wsdd INFO(pid 16894): 192.168.8.103:65295(eth0) - - "Resolve urn:uuid:b7183da1-74ba-40c0-af25-4e4ff4a97212 UDP" - -

admin@ubuntu_1804:/etc/systemd$ sudo /usr/bin/wsdd -4 -v
2019-06-10 02:17:17,127:wsdd WARNING(pid 17328): no interface given, using all interfaces
2019-06-10 02:17:17,128:wsdd INFO(pid 17328): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 02:17:17,140:wsdd INFO(pid 17328): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 02:17:17,217:wsdd INFO(pid 17328): joined multicast group ('239.255.255.250', 3702) on 10.0.5.239%eth0
2019-06-10 02:17:22,539:wsdd INFO(pid 17328): 192.168.8.103:53385(eth0) - - "Probe urn:uuid:a55bb073-d9c4-4256-8eff-83795a0e16e3 UDP" - -
2019-06-10 02:17:25,524:wsdd INFO(pid 17328): 192.168.8.103:65295(eth0) - - "Resolve urn:uuid:cb241500-da80-4e78-9587-a86a0735d306 UDP" - -

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -4 -v
2019-06-10 03:08:50,298:wsdd WARNING(pid 22265): no interface given, using all interfaces
2019-06-10 03:08:50,299:wsdd INFO(pid 22265): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 03:08:50,311:wsdd INFO(pid 22265): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 03:08:50,352:wsdd INFO(pid 22265): joined multicast group ('239.255.255.250', 3702) on 10.0.5.239%eth0
2019-06-10 03:08:58,761:wsdd INFO(pid 22265): 192.168.8.103:53385(eth0) - - "Probe urn:uuid:49a8c5c0-d99e-4f89-9fce-4b29388f8b78 UDP" - -
2019-06-10 03:08:59,244:wsdd INFO(pid 22265): 192.168.8.103:65295(eth0) - - "Resolve urn:uuid:2771ac45-d3ec-4456-a120-68efcbef283c UDP" - -

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -4 -v
2019-06-10 03:20:50,225:wsdd WARNING(pid 23404): no interface given, using all interfaces
2019-06-10 03:20:50,226:wsdd INFO(pid 23404): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 03:20:50,243:wsdd INFO(pid 23404): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 03:20:50,376:wsdd INFO(pid 23404): joined multicast group ('239.255.255.250', 3702) on 10.0.5.239%eth0
2019-06-10 03:20:59,799:wsdd INFO(pid 23404): 192.168.8.103:53385(eth0) - - "Probe urn:uuid:3ca0e68a-55e5-4ca0-b05d-367ad1680fc5 UDP" - -
2019-06-10 03:21:01,345:wsdd INFO(pid 23404): 192.168.8.103:65295(eth0) - - "Resolve urn:uuid:de1f91d1-fdd4-4cf2-81bf-e84ca7f12eeb UDP" - -
2019-06-10 03:21:02,425:wsdd INFO(pid 23404): 192.168.8.103:65295(eth0) - - "Resolve urn:uuid:b7d08dea-1d27-4afe-8859-d64dd5db098e UDP" - -
(refresh again)
2019-06-10 03:21:34,300:wsdd INFO(pid 23404): 192.168.8.103:53385(eth0) - - "Probe urn:uuid:5c84c3cf-f5c7-4107-85bf-6dfef899f863 UDP" - -
2019-06-10 03:21:35,550:wsdd INFO(pid 23404): 192.168.8.103:65295(eth0) - - "Resolve urn:uuid:54085f36-1865-4fbe-938b-290708e26833 UDP" - -

log 3

-i eth0

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -i eth0 -v
2019-06-10 04:33:58,274:wsdd INFO(pid 1197): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 04:33:58,291:wsdd INFO(pid 1197): joined multicast group ('239.255.255.250', 3702) on 10.0.5.239%eth0
2019-06-10 04:33:58,334:wsdd INFO(pid 1197): joined multicast group ('ff02::c', 3702, 22364, 160) on fe80::83e:e1e9:d627:a983%eth0

-i eth0 and -6

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -i eth0 -6 -v
2019-06-10 04:15:32,981:wsdd INFO(pid 31584): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 04:15:32,995:wsdd INFO(pid 31584): joined multicast group ('ff02::c', 3702, 22364, 160) on fe80::83e:e1e9:d627:a983%eth0

-i eth0 and -4

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -i eth0 -4 -v
2019-06-10 04:18:33,437:wsdd INFO(pid 31889): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 04:18:33,449:wsdd INFO(pid 31889): joined multicast group ('239.255.255.250', 3702) on 10.0.5.239%eth0

log 4

-i eth1 and -4

admin@ubuntu_1804:/etc/systemd$ sudo /usr/bin/wsdd -i eth1 -n huhu -4 -v -w WORKGROUP
2019-06-10 01:57:40,986:wsdd INFO(pid 15403): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 01:57:41,000:wsdd INFO(pid 15403): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 01:57:48,480:wsdd INFO(pid 15403): 192.168.8.103:53385(eth1) - - "Probe urn:uuid:6205e1b7-19d6-4533-852d-7b6c733437a8 UDP" - -
2019-06-10 01:57:48,537:wsdd INFO(pid 15403): 192.168.8.103:65295(eth1) - - "Resolve urn:uuid:da022ce2-c84d-4757-be97-af892d4eb7f0 UDP" - -
2019-06-10 01:57:48,552:wsdd INFO(pid 15403): 192.168.8.103 - - "POST /2cb964ad-e5d4-558a-a30d-f4952aef207e HTTP/1.1" 200 -

admin@ubuntu_1804:/etc/systemd$ sudo /usr/bin/wsdd -i eth1 -n Huhu -4 -v -w WORKGROUP
2019-06-10 02:14:13,113:wsdd INFO(pid 16997): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 02:14:13,125:wsdd INFO(pid 16997): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 02:14:17,873:wsdd INFO(pid 16997): 192.168.8.103:53385(eth1) - - "Probe urn:uuid:b68421f9-1076-40d2-816f-213ff0bcd04a UDP" - -
2019-06-10 02:14:19,031:wsdd INFO(pid 16997): 192.168.8.103:65295(eth1) - - "Resolve urn:uuid:2f006081-8a1f-433b-9436-f846e58358a1 UDP" - -
2019-06-10 02:14:19,063:wsdd INFO(pid 16997): 192.168.8.103 - - "POST /2cb964ad-e5d4-558a-a30d-f4952aef207e HTTP/1.1" 200 -

admin@ubuntu_1804:/etc/systemd$ sudo /usr/bin/wsdd -i eth1 -4 -v -w WORKGROUP
2019-06-10 02:15:39,727:wsdd INFO(pid 17156): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 02:15:39,739:wsdd INFO(pid 17156): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 02:15:46,790:wsdd INFO(pid 17156): 192.168.8.103:53385(eth1) - - "Probe urn:uuid:bc09f2bf-ddf6-4050-808e-cb988f4e03bc UDP" - -
2019-06-10 02:15:49,393:wsdd INFO(pid 17156): 192.168.8.103:65295(eth1) - - "Resolve urn:uuid:f3e40ada-c393-446b-89c3-a780f177c244 UDP" - -
2019-06-10 02:15:49,404:wsdd INFO(pid 17156): 192.168.8.103 - - "POST /2cb964ad-e5d4-558a-a30d-f4952aef207e HTTP/1.1" 200 -

admin@ubuntu_1804:/etc/systemd$ sudo /usr/bin/wsdd -i eth1 -4 -v
2019-06-10 02:16:25,350:wsdd INFO(pid 17218): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 02:16:25,363:wsdd INFO(pid 17218): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 02:16:29,536:wsdd INFO(pid 17218): 192.168.8.103:53385(eth1) - - "Probe urn:uuid:d5d44030-2f82-439f-9212-565f3bca47ec UDP" - -
2019-06-10 02:16:31,914:wsdd INFO(pid 17218): 192.168.8.103:65295(eth1) - - "Resolve urn:uuid:26b936da-dde0-4bf5-a6eb-b2b51bca45f0 UDP" - -
2019-06-10 02:16:31,925:wsdd INFO(pid 17218): 192.168.8.103 - - "POST /2cb964ad-e5d4-558a-a30d-f4952aef207e HTTP/1.1" 200 -

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -i eth1 -4 -v
2019-06-10 02:19:21,575:wsdd INFO(pid 17528): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 02:19:21,589:wsdd INFO(pid 17528): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 02:19:27,198:wsdd INFO(pid 17528): 192.168.8.103:53385(eth1) - - "Probe urn:uuid:005a76cd-dd0c-455c-a82b-9ef7fcc0b001 UDP" - -
2019-06-10 02:19:27,876:wsdd INFO(pid 17528): 192.168.8.103:65295(eth1) - - "Resolve urn:uuid:78e9e7ea-4462-461f-addf-bcb927a55716 UDP" - -
2019-06-10 02:19:27,887:wsdd INFO(pid 17528): 192.168.8.103 - - "POST /2cb964ad-e5d4-558a-a30d-f4952aef207e HTTP/1.1" 200 -

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -i eth1 -4 -v
2019-06-10 03:16:43,448:wsdd INFO(pid 23025): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 03:16:43,461:wsdd INFO(pid 23025): joined multicast group ('239.255.255.250', 3702) on 192.168.8.104%eth1
2019-06-10 03:16:47,154:wsdd INFO(pid 23025): 192.168.8.103:53385(eth1) - - "Probe urn:uuid:a88cf1b9-0bd2-483b-8b9b-634020d3ddfc UDP" - -
2019-06-10 03:16:47,534:wsdd INFO(pid 23025): 192.168.8.103:65295(eth1) - - "Resolve urn:uuid:871db107-b238-474d-8e54-e4891b0f628b UDP" - -
2019-06-10 03:16:47,546:wsdd INFO(pid 23025): 192.168.8.103 - - "POST /2cb964ad-e5d4-558a-a30d-f4952aef207e HTTP/1.1" 200 -

more

-i eth1 and -6

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -i eth1 -6 -v
2019-06-10 02:25:15,890:wsdd INFO(pid 18109): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 02:25:15,902:wsdd INFO(pid 18109): joined multicast group ('ff02::c', 3702, 22364, 158) on fe80::7b6b:82a0:1475:6160%eth1
2019-06-10 02:25:26,555:wsdd INFO(pid 18109): fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:145fa8cf-d50e-46b7-a5b4-2a27a9dab3b6 UDP" - -

-6

admin@ubuntu_1804:/etc/systemd$ /usr/bin/wsdd -6 -v
2019-06-10 03:08:08,818:wsdd WARNING(pid 22204): no interface given, using all interfaces
2019-06-10 03:08:08,830:wsdd INFO(pid 22204): using pre-defined UUID 2cb964ad-e5d4-558a-a30d-f4952aef207e
2019-06-10 03:08:08,866:wsdd INFO(pid 22204): joined multicast group ('ff02::c', 3702, 22364, 158) on fe80::7b6b:82a0:1475:6160%eth1
2019-06-10 03:08:08,895:wsdd INFO(pid 22204): joined multicast group ('ff02::c', 3702, 22364, 160) on fe80::83e:e1e9:d627:a983%eth0
2019-06-10 03:08:26,442:wsdd INFO(pid 22204): fe80::5d27:ee50:5c54:3db%eth1:53386(eth1) - - "Probe urn:uuid:ded1c713-3fae-4818-93f5-a401937a4571 UDP" - -

Not an issue per say. Just wanted to ask if anyone managed to run this on macOS as service.
Always when run in plist, app get terminated with code error 2. Running manually, as bash script works.

There is no way to specify which IP address to use on interfaces with multiple IP addresses. Ubuntu uses Netplan for network config. Unfortunately, there is no way to implement subinterfaces like before and so all extra IP addresses use the same interface. It would be nice to just specify the IP address and not the interface alone.

Hello,
When running the script on Linux Mint 19.3 Cinnamon 5.6.4-050604-lowlatency I'm getting the error in the title no matter where I run the script and regardless of any options used.
administrator@Server-01:~$ ~/wsdd.py 2020-06-11 10:59:48,038:wsdd WARNING(pid 49307): no interface given, using all interfaces 2020-06-11 10:59:48,454:wsdd ERROR(pid 49307): error in main loop Traceback (most recent call last): File "/home/administrator/wsdd.py", line 1626, in main key.data.handle_request() File "/home/administrator/wsdd.py", line 1195, in handle_request iface = self.interfaces[ifa_idx] KeyError: 15

Hi,

I'm not sure if this is an issue. I'm using Ubuntu 20.04, Samba 4.11.6.

I have "installed" wsdd as a service but I also tried it manually. The NAS is showing up directly in Windows 10 after starting wsdd but when click on it I will get. "Error 0x80070035 Network path not found". Which means it is not possible to view the SMB folders. There are folders for named users and also for nobody / nogroup.

A direct connection with the IP is working without problems. I have several network interfaces in the NAS. I manually started wsdd with "wsdd --interface enp2s0 -4" but the result is still the same. Min proto in Samba is V3. The mentioned ports in the firewall are open on the NAS.

NAS Address: 192.168.179.9
Windows 10: 192.168.179.3

So basically this is looking like it is working, isn't it?

Jul 28 21:01:33 od wsdd[1712205]: INFO: using pre-defined UUID b338304b-5023-5185-bfcc-997c88a99130 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: netlink message with 428 bytes Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 1 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 2 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 7 3 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 8 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 6 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: new address 127.0.0.1 on lo Jul 28 21:01:33 od wsdd[1712205]: DEBUG: ignoring that address on lo Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 1 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 2 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 4 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 11 3 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 8 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 6 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: new address 192.168.179.9 on enp2s0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: handling traffic for 192.168.179.9 on enp2s0 Jul 28 21:01:33 od wsdd[1712205]: INFO: joined multicast group ('239.255.255.250', 3702) on 192.168.179.9%enp2s0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: transport address on enp2s0 is 192.168.179.9 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: will listen for HTTP traffic on address ('192.168.179.9', 5357) Jul 28 21:01:33 od wsdd[1712205]: DEBUG: constructed xml for WSD message: b'<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof" xmlns:pnpx="http://schemas.microsoft.com/windows/pnpx/2005/10" xmlns:pub="http://schemas.microsoft.com/windows/pub/2005/07"><soap:Header><wsa:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Hello</wsa:Action><wsa:MessageID>urn:uuid:c0cf5d28-d104-11ea-886f-2dbf4c0140e3</wsa:MessageID><wsd:AppSequence InstanceId="1595962893" SequenceId="urn:uuid:c0cf5d29-d104-11ea-886f-2dbf4c0140e3" MessageNumber="0" /></soap:Header><soap:Body><wsd:Hello><wsa:EndpointReference><wsa:Address>urn:uuid:b338304b-5023-5185-bfcc-997c88a99130</wsa:Address></wsa:EndpointReference><wsd:XAddrs>http://192.168.179.9:5357/b338304b-5023-5185-bfcc-997c88a99130</wsd:XAddrs><wsd:MetadataVersion>1</wsd:MetadataVersion></wsd:Hello></soap:Body></soap:Envelope>' Jul 28 21:01:33 od wsdd[1712205]: DEBUG: scheduling Hello message via enp2s0 to ('239.255.255.250', 3702) Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 1 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 2 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 4 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 11 3 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 8 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 6 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: new address 192.168.181.102 on enp3s0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: ignoring that address on enp3s0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 1 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 2 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 4 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 3 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 8 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 6 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: new address 192.168.178.46 on enx000ec6633dec Jul 28 21:01:33 od wsdd[1712205]: DEBUG: ignoring that address on enx000ec6633dec Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 1 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 2 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 9 3 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: new address 10.8.0.1 on tun0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: ignoring that address on tun0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: netlink message with 432 bytes Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 1 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 6 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 8 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: new address ::1 on lo Jul 28 21:01:33 od wsdd[1712205]: DEBUG: ignoring that address on lo Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 1 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 6 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 8 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: new address fe80::21e:6ff:fe45:308a on enp2s0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: ignoring that address on enp2s0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 1 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 6 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 8 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: new address 2003:f0:3f3c:f353:21e:6ff:fe45:308b on enp3s0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: ignoring that address on enp3s0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 1 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 6 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 8 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: new address fe80::21e:6ff:fe45:308b on enp3s0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: ignoring that address on enp3s0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 1 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 6 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 8 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: new address fe80::20e:c6ff:fe63:3dec on enx000ec6633dec Jul 28 21:01:33 od wsdd[1712205]: DEBUG: ignoring that address on enx000ec6633dec Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 1 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 20 6 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: rt_attr 8 8 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: new address fe80::667a:72bb:6988:e54e on tun0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: ignoring that address on tun0 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: netlink message with 20 bytes Jul 28 21:01:33 od wsdd[1712205]: DEBUG: invalid rtm_message type 3 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: invalid rtm_message type 1 Jul 28 21:01:33 od wsdd[1712205]: DEBUG: processing WSD Get message (urn:uuid:af3bf07a-2b88-488f-af4d-ed68315d2041) Jul 28 21:01:33 od wsdd[1712205]: DEBUG: incoming message content is b'<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"><soap:Header><wsa:To>urn:uuid:b338304b-5023-5185-bfcc-997c88a99130</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</wsa:Action><wsa:MessageID>urn:uuid:af3bf07a-2b88-488f-af4d-ed68315d2041</wsa:MessageID><wsa:ReplyTo><wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address></wsa:ReplyTo><wsa:From><wsa:Address>urn:uuid:10ca9acf-d4d3-4ca5-af28-e197a67beb7a</wsa:Address></wsa:From></soap:Header><soap:Body/></soap:Envelope>' Jul 28 21:01:33 od wsdd[1712205]: DEBUG: constructed xml for WSD message: b'<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof" xmlns:pnpx="http://schemas.microsoft.com/windows/pnpx/2005/10" xmlns:pub="http://schemas.microsoft.com/windows/pub/2005/07"><soap:Header><wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse</wsa:Action><wsa:MessageID>urn:uuid:c0cf5d2a-d104-11ea-886f-2dbf4c0140e3</wsa:MessageID><wsa:RelatesTo>urn:uuid:af3bf07a-2b88-488f-af4d-ed68315d2041</wsa:RelatesTo></soap:Header><soap:Body><wsx:Metadata><wsx:MetadataSection Dialect="http://schemas.xmlsoap.org/ws/2006/02/devprof/ThisDevice"><wsdp:ThisDevice><wsdp:FriendlyName>WSD Device od</wsdp:FriendlyName><wsdp:FirmwareVersion>1.0</wsdp:FirmwareVersion><wsdp:SerialNumber>1</wsdp:SerialNumber></wsdp:ThisDevice></wsx:MetadataSection><wsx:MetadataSection Dialect="http://schemas.xmlsoap.org/ws/2006/02/devprof/ThisModel"><wsdp:ThisModel><wsdp:Manufacturer>wsdd</wsdp:Manufacturer><wsdp:ModelName>wsdd</wsdp:ModelName><pnpx:DeviceCategory>Computers</pnpx:DeviceCategory></wsdp:ThisModel></wsx:MetadataSection><wsx:MetadataSection Dialect="http://schemas.xmlsoap.org/ws/2006/02/devprof/Relationship"><wsdp:Relationship Type="http://schemas.xmlsoap.org/ws/2006/02/devprof/host"><wsdp:Host><wsa:EndpointReference><wsa:Address>urn:uuid:b338304b-5023-5185-bfcc-997c88a99130</wsa:Address></wsa:EndpointReference><wsdp:Types>pub:Computer</wsdp:Types><wsdp:ServiceId>urn:uuid:b338304b-5023-5185-bfcc-997c88a99130</wsdp:ServiceId><pub:Computer>OD/Workgroup:WORKGROUP</pub:Computer></wsdp:Host></wsdp:Relationship></wsx:MetadataSection></wsx:Metadata></soap:Body></soap:Envelope>' Jul 28 21:01:33 od wsdd[1712205]: INFO: 192.168.179.3 - - "POST /b338304b-5023-5185-bfcc-997c88a99130 HTTP/1.1" 200 - Jul 28 21:01:33 od wsdd[1712205]: DEBUG: processing WSD Get message (urn:uuid:b766b874-ed44-497f-a33c-0a607810c580) Jul 28 21:01:33 od wsdd[1712205]: DEBUG: incoming message content is b'<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"><soap:Header><wsa:To>urn:uuid:b338304b-5023-5185-bfcc-997c88a99130</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</wsa:Action><wsa:MessageID>urn:uuid:b766b874-ed44-497f-a33c-0a607810c580</wsa:MessageID><wsa:ReplyTo><wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address></wsa:ReplyTo><wsa:From><wsa:Address>urn:uuid:80a65d05-140e-47e8-9997-799db5a668eb</wsa:Address></wsa:From></soap:Header><soap:Body/></soap:Envelope>' Jul 28 21:01:33 od wsdd[1712205]: DEBUG: constructed xml for WSD message: b'<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof" xmlns:pnpx="http://schemas.microsoft.com/windows/pnpx/2005/10" xmlns:pub="http://schemas.microsoft.com/windows/pub/2005/07"><soap:Header><wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse</wsa:Action><wsa:MessageID>urn:uuid:c0cf5d2b-d104-11ea-886f-2dbf4c0140e3</wsa:MessageID><wsa:RelatesTo>urn:uuid:b766b874-ed44-497f-a33c-0a607810c580</wsa:RelatesTo></soap:Header><soap:Body><wsx:Metadata><wsx:MetadataSection Dialect="http://schemas.xmlsoap.org/ws/2006/02/devprof/ThisDevice"><wsdp:ThisDevice><wsdp:FriendlyName>WSD Device od</wsdp:FriendlyName><wsdp:FirmwareVersion>1.0</wsdp:FirmwareVersion><wsdp:SerialNumber>1</wsdp:SerialNumber></wsdp:ThisDevice></wsx:MetadataSection><wsx:MetadataSection Dialect="http://schemas.xmlsoap.org/ws/2006/02/devprof/ThisModel"><wsdp:ThisModel><wsdp:Manufacturer>wsdd</wsdp:Manufacturer><wsdp:ModelName>wsdd</wsdp:ModelName><pnpx:DeviceCategory>Computers</pnpx:DeviceCategory></wsdp:ThisModel></wsx:MetadataSection><wsx:MetadataSection Dialect="http://schemas.xmlsoap.org/ws/2006/02/devprof/Relationship"><wsdp:Relationship Type="http://schemas.xmlsoap.org/ws/2006/02/devprof/host"><wsdp:Host><wsa:EndpointReference><wsa:Address>urn:uuid:b338304b-5023-5185-bfcc-997c88a99130</wsa:Address></wsa:EndpointReference><wsdp:Types>pub:Computer</wsdp:Types><wsdp:ServiceId>urn:uuid:b338304b-5023-5185-bfcc-997c88a99130</wsdp:ServiceId><pub:Computer>OD/Workgroup:WORKGROUP</pub:Computer></wsdp:Host></wsdp:Relationship></wsx:MetadataSection></wsx:Metadata></soap:Body></soap:Envelope>' Jul 28 21:01:33 od wsdd[1712205]: INFO: 192.168.179.3 - - "POST /b338304b-5023-5185-bfcc-997c88a99130 HTTP/1.1" 200 -

As you can see a direct connect to the ip is showing several folders:
Screenshot

Basically OD should work the same because it is the same IP.

Apr 11 20:13:11 wsdd.py[51507]: ERROR: error in main loop
Apr 11 20:13:11 wsdd.py[51507]: Traceback (most recent call last):
Apr 11 20:13:11 wsdd.py[51507]: File "/usr/sbin/wsdd.py", line 706, in serve_wsd_requests
Apr 11 20:13:11 wsdd.py[51507]: key.data.handle_request()
Apr 11 20:13:11 wsdd.py[51507]: File "/usr/sbin/wsdd.py", line 427, in handle_request
Apr 11 20:13:11 wsdd.py[51507]: msg = wsd_handle_message(msg, self.interface)
Apr 11 20:13:11 wsdd.py[51507]: File "/usr/sbin/wsdd.py", line 401, in wsd_handle_message
Apr 11 20:13:11 wsdd.py[51507]: response = wsd_handle_probe(probe)
Apr 11 20:13:11 wsdd.py[51507]: File "/usr/sbin/wsdd.py", line 281, in wsd_handle_probe
Apr 11 20:13:11 wsdd.py[51507]: types = probe.find('./wsd:Types', namespaces).text
Apr 11 20:13:11 wsdd.py[51507]: AttributeError: 'NoneType' object has no attribute 'text'

See https://forum.openmediavault.org/index.php/Thread/26846-wsdd-0-3-2-OMV-4-1-21-1-ERROR-error-in-main-loop/

Hi, thank you for providing useful software.
I get this message on starting daemon:

WARNING: cannot unset all_multicast: [Errno 92] Protocol not available

What should i do?

--
CentOS8 4.18.0-193.14.2.el8_2.x86_64
wsdd 1ca9ae0
OPTIONS="-s -w MYWGNAME -i enp5s0"

Hello, and first of all thanks a lot for wsdd!

I was trying to install wsdd (feat/discovery branch) on a fresh Kubuntu 20.04 desktop according to the steps described at https://devanswers.co/discover-ubuntu-machines-samba-shares-windows-10-network/
and experienced the same behavior as a few people: Samba server not visible and 100% load on one CPU core.

The 100% load seems to be created by a never ending loop in def handle_request(self).
Adding a logger.warning line at line 1182 of wsdd.py as follows:

            addr = None
            i = offset + IFA_MSG_LEN
            while i - offset < msg_len:
                attr_len, attr_type = struct.unpack_from('HH', buf, i)
                if attr_type == IFA_LABEL:
                    name, = struct.unpack_from(str(attr_len - 4 - 1) + 's',
                                               buf, i + 4)
                    self.add_interface(name.decode(), ifa_idx, ifa_scope)
                elif attr_type == IFA_LOCAL and ifa_family == socket.AF_INET:
                    addr = buf[i + 4:i + 4 + 4]
                elif (attr_type == IFA_ADDRESS and
                        ifa_family == socket.AF_INET6):
                    addr = buf[i + 4:i + 4 + 16]
                elif attr_type == IFA_FLAGS:
                    _, ifa_flags = struct.unpack_from('HI', buf, i)
                logger.warning(' i= {} offset= {} msg_len= {} addr= {}'.format(i, offset, msg_len, addr)) <<<<<< this
                i += ((attr_len + 1) // RTA_ALIGNTO) * RTA_ALIGNTO
                logger.debug('rt_attr {} {}'.format(attr_len, attr_type))

I could get this output:

>>> %FastDebug wsdd.py
2020-06-07 23:26:13,519:wsdd WARNING(pid 1757329): no interface given, using all interfaces
2020-06-07 23:26:13,520:wsdd WARNING(pid 1757329):  i= 24 offset= 16 msg_len= 60 addr= None
2020-06-07 23:26:19,040:wsdd WARNING(pid 1757329):  i= 32 offset= 16 msg_len= 60 addr= b'\x7f\x00\x00\x01'
2020-06-07 23:26:23,604:wsdd WARNING(pid 1757329):  i= 40 offset= 16 msg_len= 60 addr= b'\x7f\x00\x00\x01'
2020-06-07 23:26:25,432:wsdd WARNING(pid 1757329):  i= 48 offset= 16 msg_len= 60 addr= b'\x7f\x00\x00\x01'
2020-06-07 23:26:27,278:wsdd WARNING(pid 1757329):  i= 56 offset= 16 msg_len= 60 addr= b'\x7f\x00\x00\x01'
/tmp/wsdd-feat-discovery/src/wsdd.py:989: DeprecationWarning: The 'warn' method is deprecated, use 'warning' instead
  logger.warn('new address {} on {}'.format(addr, interface.name))
2020-06-07 23:26:28,722:wsdd WARNING(pid 1757329): new address 127.0.0.1 on lo
/tmp/wsdd-feat-discovery/src/wsdd.py:992: DeprecationWarning: The 'warn' method is deprecated, use 'warning' instead
  logger.warn('ignoring address on {}'.format(interface.name))
2020-06-07 23:26:28,723:wsdd WARNING(pid 1757329): ignoring address on lo
2020-06-07 23:26:28,724:wsdd WARNING(pid 1757329):  i= 100 offset= 92 msg_len= 72 addr= None
2020-06-07 23:26:30,458:wsdd WARNING(pid 1757329):  i= 108 offset= 92 msg_len= 72 addr= b'\xc0\xa8\x00\x04'
2020-06-07 23:26:32,130:wsdd WARNING(pid 1757329):  i= 116 offset= 92 msg_len= 72 addr= b'\xc0\xa8\x00\x04'
2020-06-07 23:26:35,914:wsdd WARNING(pid 1757329):  i= 124 offset= 92 msg_len= 72 addr= b'\xc0\xa8\x00\x04'
2020-06-07 23:26:39,878:wsdd WARNING(pid 1757329):  i= 132 offset= 92 msg_len= 72 addr= b'\xc0\xa8\x00\x04'
2020-06-07 23:26:42,256:wsdd WARNING(pid 1757329):  i= 132 offset= 92 msg_len= 72 addr= b'\xc0\xa8\x00\x04'
2020-06-07 23:26:49,370:wsdd WARNING(pid 1757329):  i= 132 offset= 92 msg_len= 72 addr= b'\xc0\xa8\x00\x04'

i - offset is now stuck at 40 (<72) for ever

I could workaround the issue (stopping the loop as soon as one address is added) by adding a break statement as line 1175 as follows:

addr = None
            i = offset + IFA_MSG_LEN
            while i - offset < msg_len:
                attr_len, attr_type = struct.unpack_from('HH', buf, i)
                if attr_type == IFA_LABEL:
                    name, = struct.unpack_from(str(attr_len - 4 - 1) + 's',
                                               buf, i + 4)
                    self.add_interface(name.decode(), ifa_idx, ifa_scope)
                    break                <<<<<< this
                elif attr_type == IFA_LOCAL and ifa_family == socket.AF_INET:
                    addr = buf[i + 4:i + 4 + 4]
                elif (attr_type == IFA_ADDRESS and
                        ifa_family == socket.AF_INET6):
                    addr = buf[i + 4:i + 4 + 16]
                elif attr_type == IFA_FLAGS:
                    _, ifa_flags = struct.unpack_from('HI', buf, i)
                i += ((attr_len + 1) // RTA_ALIGNTO) * RTA_ALIGNTO
                logger.debug('rt_attr {} {}'.format(attr_len, attr_type))

After that no more 100% load and my samba server is visible from a Win10 box.

This also got rid of the "no interface given, using all interfaces" message, and gave me "decent" messages:

$ sudo systemctl status wsdd
● wsdd.service - Web Services Dynamic Discovery host daemon
     Loaded: loaded (/etc/systemd/system/wsdd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2020-06-07 23:38:15 CEST; 4s ago
   Main PID: 1797817 (python3)
      Tasks: 1 (limit: 9355)
     Memory: 10.9M
     CGroup: /system.slice/wsdd.service
             └─1797817 python3 /usr/bin/wsdd --shortlog

jun 07 23:38:15 myuxbox systemd[1]: Started Web Services Dynamic Discovery host daemon.
jun 07 23:38:15 myuxbox wsdd[1797817]: WARNING: no interface given, using all interfaces
jun 07 23:38:15 myuxbox wsdd[1797817]: WARNING: new address 127.0.0.1 on lo
jun 07 23:38:15 myuxbox wsdd[1797817]: WARNING: ignoring address on lo
jun 07 23:38:15 myuxbox wsdd[1797817]: WARNING: new address 192.168.0.4 on eno1
jun 07 23:38:15 myuxbox wsdd[1797817]: WARNING: handling traffic for 192.168.0.4 on eno1 now
jun 07 23:38:15 myuxbox wsdd[1797817]: WARNING: new address ::1 on lo
jun 07 23:38:15 myuxbox wsdd[1797817]: WARNING: ignoring address on lo
jun 07 23:38:15 myuxbox wsdd[1797817]: WARNING: new address fe80::xxxx:xxxx:xxxx:xxxx on eno1
jun 07 23:38:15 myuxbox wsdd[1797817]: WARNING: handling traffic for fe80::xxxx:xxxx:xxxx:xxxx on eno1 now

However I also have additional messages in syslog about wsdd:

Jun  7 20:38:48 myuxbox wsdd[1492]: WARNING: invalid resolve request: address (urn:uuid:abcd8d00-272d-f6ef-1ce3-a1b8421bd755) does not match own one (urn:uuid:cd5e7863-f996-5ea9-b64b-b50604ccbb75)
Jun  7 20:38:58 myuxbox wsdd[1492]: WARNING: invalid resolve request: address (urn:uuid:e3248000-80ce-11db-8000-001ba9350222) does not match own one (urn:uuid:cd5e7863-f996-5ea9-b64b-b50604ccbb75)
Jun  7 20:49:08 myuxbox wsdd[1492]: WARNING: invalid resolve request: address (urn:uuid:abcd8d00-272d-f6ef-1ce3-a1b8421bd755) does not match own one (urn:uuid:cd5e7863-f996-5ea9-b64b-b50604ccbb75)
Jun  7 20:49:18 myuxbox wsdd[1492]: WARNING: invalid resolve request: address (urn:uuid:e3248000-80ce-11db-8000-001ba9350222) does not match own one (urn:uuid:cd5e7863-f996-5ea9-b64b-b50604ccbb75)

I have no idea what they mean, but so far that seems harmless...

No need to tell you that I have no idea what I am talking about and that my workaround may have broken a lot of other things... (or be very specific to my configuration)

Here are some basic details about my config, if you need more please let me know.
$ uname -a
Linux myuxbox 5.4.0-33-generic #37-Ubuntu SMP Thu May 21 12:53:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ python3 -V
Python 3.8.2

Hopefully this might help you properly fix the issue.
Thanks again.
BR
Patrick

While at it I replaced 6 occurrences of logger.warn() with logger.warning() to get rid of related messages (this is clearly related to Python version, as might be the main issue ?)

Samba uses the avahi-client/D-Bus to announce to avahi that a the server is available. WSDD currently relies on the rc system to ensure samba is started before wsdd.

wsdd could subscribe to the same messages that avahi listens for and then publish the service. This would allow wsdd to start before smbd and then when smbd is ready, it could announce the share. This would also have the advantage that if smbd dies, wsdd could remove the service.

My eth0 has no address so your enumerate_host_interfaces errored out because it dereferenced a null pointer.

The hack I used to fix this was:

         deref = ptr[0]
+        if deref.addr:
           family = deref.addr[0].family

On a linux RH/centos 7 based system when wsdd is started the server name/resource/share will appear in windows explorer and can be browsed to add a shared folder on that server or using Add Network Drive a share can be added using the ip.

When you close the explorer instance and reopen it again later the server/share name is not always visible under the Network heading, it does not show in browse, connecting of network drives by ip is still active. The service is still up and running fine, do a restart of wsdd and it will once again appear under Network in windows explorer.

Its a matter of the server name persisting, its about the broadcast when it starts and then windows explorer retaining the connection when it closes and reopens..

Not sure if this is a bug as such or just normal operation

Hi,

Firstly, great work on wsdd. It works flawlessly until reboot when the service fails to start. Reading some of the other posts here, you mentioned trying the branch feat_discovery. So I did that following these steps:

wget -qO - https://pkg.ltec.ch/public/conf/ltec-ag.gpg.key | sudo apt-key add -

echo "deb https://pkg.ltec.ch/public/ bionic main" | sudo tee -a /etc/apt/sources.list.d/ltec.list

sudo apt update

sudo apt install wsdd

It works, but I am facing the same problem on reboot where the service fails to start.

● wsdd.service - Web Services Dynamic Discovery host daemon
     Loaded: loaded (/lib/systemd/system/wsdd.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Fri 2020-05-08 20:13:51 CEST; 32s ago
    Process: 1383 ExecStart=/usr/bin/wsdd $WSDD_PARAMS (code=exited, status=1/FAILURE)
   Main PID: 1383 (code=exited, status=1/FAILURE)

may 08 20:13:51 ubuntu2004 wsdd[1383]:     self.server_bind()
may 08 20:13:51 ubuntu2004 wsdd[1383]:   File "/usr/bin/wsdd", line 64, in server_bind
may 08 20:13:51 ubuntu2004 wsdd[1383]:     super().server_bind()
may 08 20:13:51 ubuntu2004 wsdd[1383]:   File "/usr/lib/python3.8/http/server.py", line 138, in server_bind
may 08 20:13:51 ubuntu2004 wsdd[1383]:     socketserver.TCPServer.server_bind(self)
may 08 20:13:51 ubuntu2004 wsdd[1383]:   File "/usr/lib/python3.8/socketserver.py", line 466, in server_bind
may 08 20:13:51 ubuntu2004 wsdd[1383]:     self.socket.bind(self.server_address)
may 08 20:13:51 ubuntu2004 wsdd[1383]: OSError: [Errno 99] Cannot assign requested address
may 08 20:13:51 ubuntu2004 systemd[1]: wsdd.service: Main process exited, code=exited, status=1/FAILURE
may 08 20:13:51 ubuntu2004 systemd[1]: wsdd.service: Failed with result 'exit-code'.

When I force restart, it works ok again.

sudo service wsdd restart

I am using a static IP address:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 70:85:c2:7f:40:4e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::52b9:aa12:7611:b341/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

I'm guessing this is a race issue again? Any ideas?

Is it possible to use this script to anounce a machine that is on another ip?

I have a few Fedora 31 servers running wsdd. On some of them wsdd does not respond.
I know it has something to do with Firewalld (iptables).
As soon as I disable Firewalld it works.

Does anyone know how to allow wsdd through Firewalld?

NOT RESPONDING

/usr/local/bin/wsdd.py -4 --shortlog --preserve-case --workgroup dknet --hostname ns1 -v

INFO: 192.168.0.50:58982(ens1) - - "Probe urn:uuid:cab75101-5b0e-4b28-97b7-42f42efbb2c9 UDP" - -
INFO: 192.168.0.50:58984(ens1) - - "Resolve urn:uuid:ccf2cdc9-7295-4f39-b984-2ecec1a87305 UDP" - -
INFO: 192.168.0.50:58984(ens1) - - "Resolve urn:uuid:88f5a768-48e8-42b5-9434-c5f292a23614 UDP" - -
INFO: 192.168.0.50:58984(ens1) - - "Resolve urn:uuid:2bf15957-7b39-4698-a26c-562da93833d5 UDP" - -
INFO: 192.168.0.50:58984(ens1) - - "Resolve urn:uuid:23dafe0c-dca6-412d-81f9-2f874a95266a UDP" - -
INFO: 192.168.0.50:58984(ens1) - - "Resolve urn:uuid:704a3dd7-6fd9-4ad6-9574-f828ff53e9d3 UDP" - -

RESPONDING

/usr/local/bin/wsdd.py -4 --shortlog --preserve-case --workgroup dknet --hostname mail -v

INFO: 192.168.0.50:58982(ens1) - - "Probe urn:uuid:cab75101-5b0e-4b28-97b7-42f42efbb2c9 UDP" - -
INFO: 192.168.0.50:58984(ens1) - - "Resolve urn:uuid:ccf2cdc9-7295-4f39-b984-2ecec1a87305 UDP" - -
INFO: 192.168.0.50:58984(ens1) - - "Resolve urn:uuid:88f5a768-48e8-42b5-9434-c5f292a23614 UDP" - -
INFO: 192.168.0.50:58984(ens1) - - "Resolve urn:uuid:2bf15957-7b39-4698-a26c-562da93833d5 UDP" - -
INFO: 192.168.0.50:58984(ens1) - - "Resolve urn:uuid:23dafe0c-dca6-412d-81f9-2f874a95266a UDP" - -
INFO: 192.168.0.50 - - "POST /6a990cbc-8f22-5778-a996-875aabffbb47 HTTP/1.1" 200 -
INFO: 192.168.0.50:58984(ens1) - - "Resolve urn:uuid:704a3dd7-6fd9-4ad6-9574-f828ff53e9d3 UDP" - -

I added this file to Firewalld and enabled it but still no luck.

[root@machine:~]# cat /usr/lib/firewalld/services/wsdd.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>WS-Discovery</short>
  <description>WS-Discovery is a network protocol based on the Internet protocol suite for advertisement and discovery of network services and presence information.</description>
  <port protocol="udp" port="3702"/>
  <destination ipv4="239.255.255.250" ipv6="FF02::C"/>
</service>
[root@machine:~]#

[root@machine:~]# firewall-cmd --list-all
public
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: dhcpv6-client dns mdns mountd nfs nrpe rpc-bind samba snmp ssh wsdd
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

[root@machine:~]#

In a downstream forum the question arose if workgroups are still required. Maybe this can be optional.

Although wsdd works on my FREEBSD 12.1 server, when I power up some of my Win 10 PCs on the network, I get various log entries on the server (edited for brevity):

when PC1 starts:
WARNING: invalid resolve request: address (uuid:e3248000-80ce-11db-8000-001ba928aac9) does not match own one (urn:uuid:6aec5bb6-e93b-547a-a10a-bb95193cb0a5)

when PC2 starts:
WARNING: invalid resolve request: address (urn:uuid:00000000-0000-1000-8000-d8492f666d3a) does not match own one (urn:uuid:6aec5bb6-e93b-547a-a10a-bb95193cb0a5)

The first uuid differs depending on the PC I power up, but the second uuid (6aec5bb6....) is always the same.

I do not know what this means, or how I can get rid of these messages.