0.6.4 Breaks on Raspian 64bit

[BlowflyOZ]

Thanks for your software, Just letting you know that exactly as per #82 bug, 0.6.4 is again broken for raspi.

[christgau]

This is strange for two reasons:

1. For v0.6.4 the only thing that changed concerning the networking was actually the fix for #80 and #82. Nothing else was changed on the networking part and it has been confirmed that the commit from the issue branch, which was 'merged' into master, worked for both issues.
2. I gathered a Raspberry Pi with a clean Raspbian GNU/Linux 10 (buster) on it. I downloaded the source as tar.gz extracted the software and ran it. It worked out of the box. The Pi immediately appeared in the Network View when wsdd was started and it stayed there after a refresh. I also restricted the network family to both IPv4 and IPv6 respectively and it worked for both cases.

Please make sure that you are actually using v0.6.4. That release introduced the -V/--version command line option to... show the version. Please also ensure that your firewall is setup correctly. Things changed a little with the latest release concerning the correct firewall setup. Refer to the readme for details. In my case the firewall was disabled. So technically, wsdd is working correctly from my point of view. For further diagnosis you should provide a log that was generated with at least -v as command line argument.

[fxrb]

As I was getting unsure if this could be related to the last Debian package (0.6.4) I created, I checked it once more: the package is correct and contains wsdd v0.6.4.

[BlowflyOZ]

Thanks for the info. It is definitely 0.6.4 I'm using.

I've been diving in to this issue a bit more today and it's odd. I'm not sure if WSDD is the issue here, or perhaps some combining of many factors with raspi64.

I was able to replicate this issue twice from two totally fresh and separate installs of Buster lite x64 on raspi4b with all updates.

The WSDD software does work initially, but fails to show in the browse list after a longer period of lower activity. Also strangely if reapplying an SD card image from a backup, the WSDD demon won't load until it's manually restarted after an image restore. On one restore test I couldn't get it to start at all. This same thing occurs whether the backup is taken with win32disk imager or Linux, and whether I shrink the images down or leave them raw. Weird !

Everything is vanilla fresh install, raspi x64 with samba other software is all is running and a really standard smb.conf

[christgau]

Interesting observation. If wsdd is running but not showing up in Windows after is has been running for a while you may have a look a the processor usage that wsdd is producing. In case wsdd consumes 100% of a single processor core I may have an idea for the reason here. Nevertheless, it would be great to have a log but based on your description an increased verbosity appears to be required. So you should start wsdd with -vv.

[BlowflyOZ]

I'v left it running 60hrs now... it failed to be visible to windows sometime within the last 4 hrs. top -p shows wsdd idling along as below 528 daemon 20 0 25708 17876 7652 S 0.0 0.2 0:00.60 python3

systemctl status shows it running ok. I've waited till is crashed again till I restart with -vv. I've just restarted it and it all came back. I'll get back to you when it fails again

update: to produce a log that is more sane (i'm running rclone vfs which is noisey) - is there a way to direct wsdd log output anywhere else but syslog???

[christgau]

to produce a log that is more sane (i'm running rclone vfs which is noisey) - is there a way to direct wsdd log output anywhere else but syslog???

I am not familiar with rclone, so I cannot say how this interferes with wsdd's log messages. Nevertheless, I suppose systemd is responsible for running wsdd on your Raspi. It then should be possible to extract the log for wsdd with journalctl -u wsdd. Otherwise you may either change the unit file and redirect the stderr output to a file or you stop wsdd and run it manually.

If the resulting log is really large you may consider compressing it as tar.gz and upload it here instead of pasting hundreds of lines into a comment.

[fxrb]

If you are using rsyslog you could redirect messages generated by wsdd to some dedicated log file by creating a file /etc/rsyslog.d/wsdd.conf with the following content:

# send wsdd log messages to dedicated log file

:programname, isequal, "wsdd" {
  /var/log/wsdd.log
  stop
}

After restarting rsyslog all messages from wsdd should appear in /var/log/wsdd.log instead of syslog.

[joowdx]

The WSDD software does work initially, but fails to show in the browse list after a longer period of lower activity.

I encountered this and just noticed a while ago and it made me a bit curious why it always disappear after some time. Allowing these ports 137, 138, 139, 445 used by the smbd and nmbd in the firewall solved the problem for me.

[christgau]

No more debug information arrived in about three years. Closing this issue.