Wsdd

	Incomplete:
	This article or section needs to be expanded. Please help to fill the gaps or discuss the issue on the talk page

	Not reviewed:
	This howto or contrib has not been reviewed and might contain code that could harm your installation. For more information on the review process have a look at the Development Review page.

	Skill level: Developer
	Risk of inconsistencies with Koozali SME Server methodology, upgrades & functionality is high. One must be knowledgeable about how changes impact their Koozali SME Server. Significant risk of irreversible harm.

Languages:

English

Maintainer

Jonn C. from [ https://www.reetspetit.com/

Version

Contrib 10:

0.2-5

smeserver-wsdd

The latest version of smeserver-wsdd is available in the SME repository, click on the version number(s) for more information.

Description

wsdd implements a Web Service Discovery host daemon. This enables (Samba) hosts, like your local server device, to be found by Web Service Discovery Clients like Windows.

It also implements the client side of the discovery protocol which allows to search for Windows machines and other devices implementing WSD. This mode of operation is called discovery mode.

Purpose

Since NetBIOS discovery is not supported by Windows anymore, wsdd makes hosts to appear in Windows again using the Web Service Discovery method. This is beneficial for devices running Samba, like NAS or file sharing servers on your local network. The discovery mode searches for other WSD servers in the local subnet.

Background

With Windows 10 version 1511, support for SMBv1 and thus NetBIOS device discovery was disabled by default. Depending on the actual edition, later versions of Windows starting from version 1709 ("Fall Creators Update") do not allow the installation of the SMBv1 client anymore. This causes hosts running Samba not to be listed in the Explorer's "Network (Neighborhood)" views. While there is no connectivity problem and Samba will still run fine, users might want to have their Samba hosts to be listed by Windows automatically.

You may ask: What about Samba itself, shouldn't this functionality be included in Samba!? Yes, maybe. However, using Samba as file sharing service is still possible even if the host running Samba is not listed in the Network Neighborhood. You can still connect using the host name (given that name resolution works) or IP address. So you can have network drives and use shared folders as well. In addition, there is a patch lurking around in the Samba bug tracker since 2015. So it may happen that this feature gets integrated into Samba at some time in the future.

Installation

Add EPEL repo

/sbin/e-smith/db yum_repositories set epel repository \
Name 'Epel - EL7' \
BaseURL 'http://download.fedoraproject.org/pub/epel/7/$basearch' \
MirrorList 'http://mirrors.fedoraproject.org/mirrorlist?repo=epel-7&arch=$basearch' \
EnableGroups no \
GPGCheck yes \
GPGKey http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL \
Exclude perl-Razor-Agent \
Visible no \
status disabled

signal-event yum-modify

yum install smeserver-wsdd-0.1-2.noarch.rpm --enablerepo = epel,smecontribs

Signal-event reboot - the rpm now does systemctl enable wsdd

Usage

[root@sme10 ~]# config show wsdd

wsdd=service
    TCPPorts=3702,5357
    UDPPort=3702
    access=private
    status=enabled

1. systemctl status wsdd
2. systemctl enable wsdd
3. systemctl start wsdd
4. systemctl restart wsdd
5. systemctl disable wsdd

/usr/lib/systemd/system/wsdd.service [Unit] Description=Web Services Dynamic Discovery host daemon After=network-online.target After=bootstrap-console.service Wants=network-online.target

1. Wants=smb.service

[Service] Type=simple ExecStart=/usr/bin/wsdd 4 -i eth0 -w TF_SL --shortlog ExecStartPre=/bin/sleep 30

1. User=wsdd
2. Group=wsdd

Example Usage

handle traffic on eth0 only, but only with IPv6 addresses

wsdd -i eth0 -6

or

wsdd --interface eth0 --ipv6only

Known Issues

Security

wsdd does not implement any security feature, e.g. by using TLS for the http service. This is because wsdd's intended usage is within private, i.e. home, LANs. The Hello message contains the hosts transport address, i.e. the IP address which speeds up discovery (avoids Resolve message).

In order to increase the security, use the capabilities of the init system or consider the -u and -c options.

Using only IPv6 on FreeBSD

If wsdd is running on FreeBSD using IPv6 only, the host running wsdd may not be reliably discovered. The reason appears to be that Windows is not always able to connect to the HTTP service for unknown reasons. As a workaround, run wsdd with IPv4 only.

Usage with NATs

Do not use wssd on interfaces that are affected by NAT. According to the standard, the ResolveMatch messages emitted by wsdd, contain the IP address ("transport address" in standard parlance) of the interface(s) the application has been bound to into. When such messages are retrieved by a client (Windows hosts, e.g.) they are unlikely to be able to connect to the provided address which has been subject to NAT. To avoid this issue, use the -i/--interface option to bind wsdd to interfaces not affected by NAT.

Tunnel/Bridge Interface

If tunnel/bridge interfaces like those created by OpenVPN or Docker exist, they may interfere with wsdd if executed without providing an interface that it should bind to (so it binds to all). In such cases, the wsdd hosts appears after wsdd has been started but it disappears when an update of the Network view in Windows Explorer is forced, either by refreshing the view or by a reboot of the Windows machine. To solve this issue, the interface that is connected to the network on which the host should be announced needs to be specified with the -i/--interface option. This prevents the usage of the tunnel/bridge interfaces.

Background: Tunnel/bridge interfaces may cause Resolve requests from Windows hosts to be delivered to wsdd multiple times,´i.e. duplicates of such request are created. If wsdd receives such a request first from a tunnel/bridge it uses the transport address (IP address) of that interface and sends the response via unicast. Further duplicates are not processed due to the duplicate message detection which is based on message UUIDs. The Windows host which receives the response appears to detect a mismatch between the transport address in the ResolveMatch message (which is the tunnel/bridge address) and the IP of the sending host/interface (LAN IP, e.g.). Subsequently, the wsdd host is ignored by Windows.