Add support for WS-Discovery protocol

[WolfWings]

Component

systemd-resolved

Is your feature request related to a problem? Please describe

Windows has shut down NetBIOS and announced about two years ago they'd be deprecating LLMNR as well, leaving WS-Discovery as the current protocol to make systems visible in that ecosystem for areas such as 'network browser' and similar.

Right now enabling this requires setting up a network-facing python script WSDD, or the separately developed WSDD2 package from Netgear that makes numerous assumptions about being on embedded systems with particular configurations and tools from the Samba project.

Describe the solution you'd like

A resolved.conf configuration setting similar to the existing mDNS and LLMNR settings. In this case an option of "announce" or similar with roughly the opposite meaning to the "resolve" LLMNR/mDNS settings could also be appropriate, and perhaps a first step before enabling full resolve support.

Describe alternatives you've considered

WSDD2 works, but makes numerous assumptions w.r.t. the platform it's installed on and expects a large set of other packages that aren't otherwise needed and can conflict with their alternatives (samba vs ksmbd for example). The code is GPLv3 licensed so it's not useful to reference for an implementation.

WSDD also works, but requires python, having a multicast-network-facing python script is less than ideal but does indeed work. The code is MIT licensed.

The systemd version you checked that didn't have the feature you are asking for

255

[WolfWings]

I'm happy to help work on this if it would be accepted, but as it's adding a new and somewhat complex protocol (XML, SOAP, another multicast port for resolved to have open, etc) I felt it best to ask if it would even be accepted first.

[Nardol]

As an alternative, there is WSDD-Native which also implements WSDD.
WSDD requires both LLMNR and HTTP as you stated just before, which maybe leave a resolver and responder scope?

[WolfWings]

WSDD doesn't actually use LLMNR at all, entirely unrelated ports and protocols. They overlap in purpose and both are checked (currently) on the Windows side, but yes it does use the HTTP wire format for queries/responses which was one reason I wasn't sure it was appropriate to include or not.

This third option for an existing natively packaged solution fits quite well though and yes integrates quite well with SystemD, I hadn't found it mentioned in previous web searches, closing RFE as resolved, thank you!