wsdd 0.6.3 no longer functional on FreeBSD
See original GitHub issueFreeBSD port maintainers recently upgraded from 0.6.2 to 0.6.3 and PR 252742 and now the daemon no longer functions (meaning: Network Neighbourhood no longer shows the machine where wsdd is running).
It will take me some time to figure out why (I’ll end up using git bisect
to figure out what commit broke things), and I probably won’t have time to do the analysis until this weekend.
I at least wanted to report it first.
Issue Analytics
- State:
- Created 3 years ago
- Comments:18 (8 by maintainers)
Top Results From Across the Web
247626 – net/py-wsdd: Update to 0.6.1 - FreeBSD Bugzilla
So, I think wsdd_suppflags is fine. The other variables look very reasonable -- zero complaints! 2. I would suggest adding NETWORKING and ...
Read more >FreeBSD - DistroWatch.com
More FreeBSD headlines. ... The function determining beta versions is not 100% reliable due to a wide variety of versioning schemes. ... docopt.cpp...
Read more >FreeBSD 12 - FreeBSD amd64 - Page 25
Packages from FreeBSD amd64 repository of FreeBSD 12 distribution. Page 25.
Read more >Untitled
Device interface - o/hookstate: return bool flag from Error function of hook handler to ... ol7_x86_64_developer_EPEL no-more-secrets-1.0.1-1.el7.src.rpm ...
Read more >nmap-7.91-setup.exe, pid - Joe Sandbox
http://1.2.3.116:50000, broadcast-wsdd-discover.nse.12.dr, false ... For more information on this license, see https://nmap.org/npsl/..0. Preamble.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@christgau resolved this error with timeout of 5.0 seconds. Thanks.
@Izorkin based on the log, you are using wsdd now in the discovery mode (client) while the original error was related to the normal (host) operation mode. So this is completely unrelated. In addition, the timeout is not really a fault of wsdd and it is not an error per se. Two possibilities:
For the first point, you might check if the default timeout of 2.0 seconds could be increased and a higher values resolves the issue: https://github.com/christgau/wsdd/blob/ee8783ce71a408a3d9923b5d67659f7ce2712166/src/wsdd.py#L672
If this really turns out to be a problem, please open a new issue or a PR, if you have a patch.
For the second point, please check your firewall rules, but a discussion of the ruleset might be out of scope… at least for this issue.