Changes

{{Languages}}

{{Languages}}

===Maintainer===

===Maintainer===

[mailto:jcrisp@safeandsoundit.co.uk [[User:ReetP|Jonn C.]]] from [ https://www.reetspetit.com/  

[mailto:jcrisp@safeandsoundit.co.uk][[User:ReetP|John C.]] from [https://www.reetspetit.com/]

=== Version ===

===Version===

{{#smeversion: smeserver-wsdd }}

{{#smeversion: smeserver-wsdd }}

=== Description ===

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

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.

===Installation===

===Installation===

  yum install smeserver-wsdd --enablerepo=smecontribs

  /sbin/e-smith/db yum_repositories set epel repository \

Name 'Epel - EL7' \

MirrorList 'http://mirrors.fedoraproject.org/mirrorlist?repo=epel-7&arch=$basearch' \

  signal-event yum-modify

  signal-event post-upgrade; signal-event reboot

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

The rpm now does a # systemctl enable wsdd  

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

 

    Active: active (running) since Sat 2020-11-28 23:53:59 AEDT; 8min ago

          └─2597 python3 /usr/bin/wsdd -4 -i eth0 -w sme-server -s

 

====Usage====

====Usage====

[root@sme10 ~]# config show wsdd

config show wsdd

 

  wsdd=service

  wsdd=service

     TCPPorts=3702,5357

     TCPPorts=3702,5357

     status=enabled

     status=enabled

# systemctl status wsdd

config setprop wsdd status enabled/disabled

 

/usr/lib/systemd/system/wsdd.service

Stop/Start/Restart/Disable

ExecStart=/usr/bin/wsdd 4 -i eth0 -w TF_SL --shortlog

systemctl start wsdd

systemctl restart wsdd

# User=wsdd

systemctl disable wsdd

# Group=wsdd

[[Category:Contrib]]  

[[Category:Howto]]  

 

[Unit]

[Service]

====Example Usage====

====Example Usage====

===Known Issues===

===Known Issues===

====Security====

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

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.

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

====Using only IPv6====

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.

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.

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.

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.