ROOT/NET/000X could have been claimed by a different driver, so we want
to double check.
Link: https://lists.zx2c4.com/pipermail/wireguard/2021-May/006716.html
Reported-by: Piotr Sobczak <piotrs@glosol.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Recent versions of Windows fail to tidy up, causing issues when reusing
GUIDs. Check to see if a GUID might be orphaned, and forcibly clear out
the registry state if so.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Otherwise we fail to remove the zombie adapter, and then the problem
repeats itself. Note that this is part of a larger issue of clearing out
bad GUIDs in NetSetup2 on recent Windows builds
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The WintunEnumAdapters() requires namespace mutex. However,
NamespaceTakePoolMutex() works as SYSTEM user only.
WireGuard is using the WintunEnumAdapters() in its manager service to
cleanup stale adapters. As the WireGuard manager service is running as
SYSTEM, this requirement was not apparent before.
This commit also extends the example project to list its existing
adapters at start.
Signed-off-by: Simon Rozman <simon@rozman.si>
Log runtime information to quickly check whether the values are sane
when analyzing error logs sent in by users.
Signed-off-by: Simon Rozman <simon@rozman.si>
Some users are seeing errors like this after rebooting from Windows
Update:
2021-01-28 18:39:45.220197: [TUN] Creating Wintun interface
2021-01-28 18:39:49.420116: [TUN] [Wintun] CreateAdapter: Creating adapter
2021-01-28 18:39:53.704007: [TUN] [Wintun] OpenDeviceObject: Failed to connect to adapter: The system cannot find the path specified. (Code 0x00000003)
2021-01-28 18:39:53.704007: [TUN] [Wintun] WintunStartSession: Failed to open adapter device object
2021-01-28 18:39:54.097037: [TUN] Unable to create Wintun interface: Error starting session: The system cannot find the path specified.
It appears that creation of the device object file might happen
asynchronously, so this commit polls for it.
Reported-by: Artem Kuroptev <artem@kuroptev.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
There seems to be a race in the TCP/IP adapter registry key. Sometimes,
the adapter TCP/IP key is created, but setting the value
EnableDeadGWDetect fails with ERROR_TRANSACTION_NOT_ACTIVE.
Signed-off-by: Simon Rozman <simon@rozman.si>
This seems to reset a number of device properties, and our update flow
seems to update old adapters without needing to call this.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This prevents us from racing with driver deletion. Mutexes are
recursive, so we shouldn't deadlock if called from Enum.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This makes our intentions a lot more clear, and in case we ever add
other version functions, makes the forward path simpler.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This requires us to make some insane conversions between INF date,
JavaScript time, and finally Windows file time. The point is to mimic
SystemTimeToFileTime, which is what SpInf.dll's pSetupStringToDriverDate
does on the YYYY-MM-DD from the INF.
The result is that we no longer have to parse an ancient text format in
C at runtime.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The iphlpapi takes both LUIDs and GUIDs but prefers LUIDs, so exposing
the NET_LUID makes sense. However, we were previously exposing the
configuration GUID, rather than the net GUID, which is confusing, so
just make it all go away.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
It'd be nicer to do this via
if (is_defined(HAVE_WHATEVER))
But MSVC won't work with the linux kernel macros for this. Ongoing
research.
Nevertheless, this makes most of the program always pass through the
compiler's type checker, only to have dead code removed later.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
I don't like this solution, but I don't see much other choice. It's not
in uuid.lib or anywhere like that.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
