http://bugs.winehq.org/show_bug.cgi?id=60251 --- Comment #6 from Kazim <aktaskazimcan0@gmail.com> --- I traced the exact syscall this reproducer blocks on — it's not WMI/ConnectServer's own logic. Wine's OLE/COM init also probes for a local CUPS server on startup, opening both an IPv6 (::1:631) and IPv4 (127.0.0.1:631) connection. The IPv4 probe returns ECONNREFUSED in ~15ms as expected. The IPv6 probe never completes — it hangs until a ~30s connect timeout. I isolated this further, with no Wine involved at all: a plain Python socket.connect(('::1', 631)) under the same VPN/TUN setup times out at 35s (my test ceiling), while ('127.0.0.1', 631) refuses instantly. With the VPN's TUN mode off, both return instantly. So this looks like a bug in the VPN's TUN implementation (it isn't excluding IPv6 loopback from the tunnel, while IPv4 loopback is excluded correctly) rather than anything in Wine. I'll file this upstream with the VPN project. Given that, I think this can likely be closed as not-a-Wine-bug, unless you'd still want Wine's CUPS probe to use a shorter timeout as a defensive measure regardless of the cause. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.