wsdd: can't start after network-online (Fedora 31)

I couldn’t get the wsdd.service unit to work on startup, it would fail with the following:

oct 04 14:10:31 principal python3[849]: detected unhandled Python exception in '/usr/local/bin/wsdd'
oct 04 14:10:31 principal wsdd[849]: Traceback (most recent call last):
oct 04 14:10:31 principal wsdd[849]:   File "/usr/local/bin/wsdd", line 840, in <module>
oct 04 14:10:31 principal wsdd[849]:     sys.exit(main())
oct 04 14:10:31 principal wsdd[849]:   File "/usr/local/bin/wsdd", line 833, in main
oct 04 14:10:31 principal wsdd[849]:     retval = serve_wsd_requests(addresses)
oct 04 14:10:31 principal wsdd[849]:   File "/usr/local/bin/wsdd", line 776, in serve_wsd_requests
oct 04 14:10:31 principal wsdd[849]:     http_srv = klass(interface.listen_address, WSDHttpRequestHandler)
oct 04 14:10:31 principal wsdd[849]:   File "/usr/lib64/python3.7/socketserver.py", line 452, in __init__
oct 04 14:10:31 principal wsdd[849]:     self.server_bind()
oct 04 14:10:31 principal wsdd[849]:   File "/usr/local/bin/wsdd", line 64, in server_bind
oct 04 14:10:31 principal wsdd[849]:     super().server_bind()
oct 04 14:10:31 principal wsdd[849]:   File "/usr/lib64/python3.7/http/server.py", line 137, in server_bind
oct 04 14:10:31 principal wsdd[849]:     socketserver.TCPServer.server_bind(self)
oct 04 14:10:31 principal wsdd[849]:   File "/usr/lib64/python3.7/socketserver.py", line 466, in server_bind
oct 04 14:10:31 principal wsdd[849]:     self.socket.bind(self.server_address)
oct 04 14:10:31 principal wsdd[849]: OSError: [Errno 99] Cannot assign requested address

I went ahead and added a time.sleep(10) right after parse_args() on main() as a stop gap measure, but there’s got to be a proper fix.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 15 (8 by maintainers)

Commits related to this issue

fix(src): ipv6 not ready after boot #18 this is a workarround — committed to palmtop/wsdd by palmtop 4 years ago
feat(src): observe network address changes Instead of determining the network addresses in use at startup and assume them to be static over the whole runtime, addresses and changes to them are now tr... — committed to christgau/wsdd by christgau 4 years ago
feat(src): observe network address changes Instead of determining the network addresses in use at startup and assume them to be static over the whole runtime, addresses and changes to them are now tr... — committed to christgau/wsdd by christgau 4 years ago

Most upvoted comments

Perfect! Thanks a lot for your feedback and your efforts in producing it.

Sorry for the delay in replying. ip addr gives

Please, don’t feel pressured. Answer whenever possible for you.

When I add -4 to the ExecStart I can see my Ubuntu server from my Windows machine. I rebooted three times and it works great each time.

Fine. That’s what I’ve expected.

When I switch it from -4 to -6 it doesn’t work. I can’t see my Ubuntu server from Windows. Even rebooting three times it still doesn’t work.

The logs confirm that this is “only” an IPv6 issue. Some research confirmed that in fact a race condition is causing the problem here. When the kernel automatically assigns an IPv6 address to an interface, the IPv6 implementation checks if there are other hosts on the interface’s network with the same address. This is called duplicate address detection (DAD). As long as the DAD is not completed, one cannot bind to the “preliminary” address. According requests result in error 99 on Linux. https://www.agwa.name/blog/post/beware_the_ipv6_dad_race_condition contains a nice summary of the problem.

The DAD is why you face the issue on reboot only, i.e. when the DAD is performed. Manual restarts of wsdd are much likely to happen after the DAD has completed and will therefore not face the problem.

This also explains why your workaround with a call to sleep before running all the network stuff in wsdd solves the issue. You can also add a line like ExecStartPre=/bin/sleep 2 to the systemd unit file (or similar for other init systems). This may not hurt the overall experience since the host can still be discovered - even some few seconds later. However, a real solution in the code would respect such situations as well as other changes to interfaces (e.g. changes WiFi networks) but this is more a little more difficult to implement in a portable way for FreeBSD and Linux and it is worth a separate issue.

As a temporary workaround, I propose to change the unit file as hinted above. I’ll add an according comment to the template unit file in etc and close that issue afterwards.

christgau on Jan 15, 2020

I’m sorry, I won’t be able to I’ve moved the network to AD keep going with bwaindwain

@mikelpr You’re welcome. Thanks for your input, anyways!

christgau on Jan 6, 2020