From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Oliver Freyermuth <firstname.lastname@example.org>,
Joshua Sjoding <email@example.com>,
Arlo Clauser <Arlo@starcubedesign.com>,
John-Paul Andreini <firstname.lastname@example.org>
Cc: WireGuard mailing list <email@example.com>
Subject: Re: Windows stuck in boot after WireGuard update (switch to WireGuardNT?)
Date: Wed, 13 Oct 2021 23:56:56 -0600 [thread overview]
Message-ID: <CAHmME9qSUqo4Wj8U4G3oznxnGB5_7oJkMULwSg4oVVgoRgQ05w@mail.gmail.com> (raw)
I assume that after >3 weeks of silence, the problem is fixed. That's good.
The root cause was that wgnt's initialization waited for winsock to
become available, but winsock was waiting for network interfaces like
wgnt to become available first, so they deadlocked for a half hour.
The solution, deployed over three weeks ago, was to defer wgnt's usage
of winsock until userspace requested it, which is necessarily after
everything else. This apparently works and is the correct fix.
But for whatever reason, the impact of this bug has really haunted me,
and so I didn't stop working on it or thinking about it even after it
was fixed correctly. The larger question is: why is a wgnt adapter
coming up at boot time at all? It's clearly not needed, as it is
something that anyway is controlled by a service. And indeed wgnt
adapters are supposed to be cleaned up when the service exits, but
this cleanup might not be committed if it happens during shutdown.
This is why sometimes the bug happened and sometimes it didn't.
So how can we solve the larger issue of never having wgnt adapters
exist at boot time, and always have them tied to the service lifetime?
It turns out Win8+ has an API for this called SwDevice, which
"unplugs" adapters when their owning process exits (or corresponding
handles close). This is used by various internal Windows components
like rasmans.dll and seems quite robust. It's also very different and
comes with its own gotchas, compared to what we were doing before, and
using it is no small undertaking. So over the last 3 weeks or so, I've
rewritten the entire userspace API portion of wgnt (and wintun) in
order to use this API where available (with ugly fallbacks for Win7).
The result is that the entire class of bugs, of which this bug here
was one, should be eliminated all together. And in the process, I've
made a lot of other things about adapter installation more reliable
and quicker too.
This work shipped with wgnt 0.10 and wintun 0.14, and is part of
wireguard for windows 0.4.11.
prev parent reply other threads:[~2021-10-14 5:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-22 10:09 Oliver Freyermuth
[not found] ` <CAHmME9pgz6PiXdFqcRw90EafHK-Jq9RfcgLUZaJ1ARrtdnjG0w@mail.gmail.com>
2021-09-22 14:02 ` Oliver Freyermuth
2021-09-22 18:57 ` Jason A. Donenfeld
2021-09-22 19:36 ` Joshua Sjoding
2021-09-24 0:21 ` Jason A. Donenfeld
2021-09-24 7:24 ` Oliver Freyermuth
2021-09-24 6:14 ` Jason A. Donenfeld
2021-09-24 17:48 ` Jason A. Donenfeld
2021-09-24 17:53 ` Joshua Sjoding
2021-09-24 17:57 ` Oliver Freyermuth
2021-09-24 19:59 ` Jason A. Donenfeld
2021-09-24 20:15 ` Arlo Clauser
2021-09-24 20:17 ` John-Paul Andreini
2021-10-14 5:56 ` Jason A. Donenfeld [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: Windows stuck in boot after WireGuard update (switch to WireGuardNT?)' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).