christgau / wsdd

A Web Service Discovery host daemon.
MIT License
808 stars 97 forks source link
python3 samba wsd

wsdd

wsdd implements a Web Service Discovery host daemon. This enables (Samba) hosts, like your local NAS 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.

Requirements

wsdd requires Python 3.7 and later only. It runs on Linux, FreeBSD, OpenBSD and MacOS. Other Unixes, such as NetBSD, might work as well but were not tested.

Although Samba is not strictly required by wsdd itself, it makes sense to run wsdd only on hosts with a running Samba daemon. Note that the OpenRC/Gentoo init script depends on the Samba service.

Installation

Operating System and Distribution-Depending Instructions

This section provides instructions how to install wsdd on different OS distributions. Sufficient privileges are assumed to be in effect, e.g. by being root or using sudo.

Arch Linux

Install wsdd from the AUR package.

CentOS, Fedora, RHEL

wsdd is included in RedHat/CentOS' EPEL repository. After setting that up, you can install wsdd like on Fedora where it is sufficient to issue

dnf install wsdd

Debian-based Distributions (Debian, Ubuntu, Mint, ...)

Wsdd is included in the official package repositories of Debian and Ubuntu (universe) since versions 12 (Bookworm) and 22.04 LTS (Jammy Jellyfish), respectively. This also applies to Linux Mint, starting from version 21 (Vanessa). Thus, it is sufficient to install it via

apt install wsdd

FreeBSD

The wsdd port can be installed via

pkg install py39-wsdd

Gentoo

You can choose between two overlays: the GURU project and an author-maintained dedicated overlay which can be selected as follows

emerge eselect-repository
eselect repository enable guru
emerge --sync

After setting up one of them you can install wsdd with

emerge wsdd

Generic Installation Instructions

No installation steps are required. Just place the wsdd.py file anywhere you want to, rename it to wsdd, and run it from there. The init scripts/unit files assume that wsdd is installed under /usr/bin/wsdd or /usr/local/bin/wsdd in case of FreeBSD. There are no configuration files. No special privileges are required to run wsdd, so it is advisable to run the service as an unprivileged, possibly dedicated, user for the service.

The etc directory of the repo contains sample configuration files for different init(1) systems, e.g. FreeBSD's rc.d, Gentoo's openrc, and systemd which is used in most contemporary Linux distros. Those files may be used as templates. They are likely to require adjustments to the actual distribution/installation where they are to be used.

Usage

Firewall Setup

Traffic for the following ports, directions and addresses must be allowed.

You should further restrict the traffic to the (link-)local subnet, e.g. by using the fe80::/10 address space for IPv6. Please note that IGMP traffic must be enabled in order to get IPv4 multicast traffic working.

For UFW and firewald, application/service profiles can be found in the respective directories. Note that UFW profiles only allow to grant the traffic on specific UDP and TCP ports, but a restriction on the IP range (like link local for IPv6) or the multicast traffic is not possible.

Options

By default wsdd runs in host mode and binds to all interfaces with only warnings and error messages enabled. In this configuration the host running wsdd is discovered with its configured hostname and belong to a default workgroup. The discovery mode, which allows to search for other WSD-compatible devices must be enabled explicitly. Both modes can be used simultaneously. See below for details.

General options

Host Operation Mode

In host mode, the device running wsdd can be discovered by Windows.

Client / Discovery Operation Mode

This mode allows to search for other WSD-compatible devices.

Example Usage

Technical Description

(Read the source for more details)

For each specified (or all) network interfaces, except for the loopback, an UDP multicast socket for message reception, two UDP sockets for replying using unicast as well as sending multicast traffic, and a listening TCP socket are created. This is done for both the IPv4 and the IPv6 address family if not configured otherwise by the command line arguments (see above). Upon startup a Hello message is sent. When wsdd terminates due to a SIGTERM signal or keyboard interrupt, a graceful shutdown is performed by sending a Bye message. I/O multiplexing is used to handle network traffic of the different sockets within a single process.

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 host's 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 to drop privileges and chroot.

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

Contributing

Contributions are welcome. Please ensure PEP8 compliance when submitting patches or pull requests. Opposite to PEP8, the maximum number of characters per line is increased to 120.

Licence

The code is licensed under the MIT license.

Acknowledgements

Thanks to Jose M. Prieto and his colleague Tobias Waldvogel who wrote the mentioned patch for Samba to provide WSD and LLMNR support. A look at their patch set made cross-checking the WSD messages easier.

References and Further Reading

Technical Specification

Documentation and Discussion on Windows/WSD

Other stuff