While the Wintun driver is typically released only at <major>.<minor>
milestones, the wintun.dll did see some intermediate releases.
To make MSI logic correctly decide to upgrade local wintun.dll file, the
version inscribed in wintun.dll file resources should increment in those
intermediate releases. MSI ignores file timestamps. One could use
REINSTALLMODE=emus Installer property to force copying wintun.dll when
its version doesn't change. But REINSTALLMODE applies to all files in
the MSI session and would be an additional requirement when authoring
MSI packages with wintun.dll.
Bumping only the final ZIP filename version is not sufficient.
Therefore, a <major>.<minor> or <major>.<minor>.<build> versioning is
introduced. Furthermore, we no longer distinguish between WintunVersion
and WintunVersionStr. All our releases used strictly numeric
<major>.<minor> notation, making WintunVersion and WintunVersionStr
always the same.
When the driver didn't change, just bump the version in wintun.proj and
run `msbuild wintun.proj /t:Zip` to rebuild the wintun.dll and make the
new ZIP file.
Signed-off-by: Simon Rozman <simon@rozman.si>
MinGW supplies all Windows header files using lowercase filenames.
This makes some of the #include lines in wintun.h fail to resolve the
.h files correctly on a case-sensitive filesystem.
Signed-off-by: Simon Rozman <simon@rozman.si>
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>
Prior, people making calls to LoadLibrary/FreeLibrary would experience
a failure to create or open adapters, because the private namespace was
already loaded into the process and not cleaned up on DLL detachment.
While this pattern is probably a misuse of the library, we should still
support cleaning that up. This commit makes the right calls to free the
boundary descriptor and close the private namespace. It does not,
however, destroy the private namespace using the flag on the second
parameter, in case of races with other processes.
Reported-by: Brad Spencer <bspencer@blackberry.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
RtlGenRandom forwards to cryptbase.dll, which is not in KnownDlls.
Therefore it's not a good idea to link to advapi32.dll at link time. How
many other gotchas of unusual forwarded functions are there? I don't
really want to find out. Therefore, delay load everything else.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This doesn't change much, but it does make it mildly more convenient
plop this into mixed-use codebases.
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>
The LastError was overridden by the stdout reader thread exit code
masking the true reason why ExecuteRunDll32() failed and even worse: as
the thread exited gracefully, the true reason was overridden by
ERROR_SUCCESS and returning TRUE (success).
Signed-off-by: Simon Rozman <simon@rozman.si>
This makes the API parallel:
Wintun*Allocate*SendPacket -> WintunSendPacket
WintunReceivePacket -> Wintun*Release*ReceivePacket
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The additional build steps performed are now attached to the build
process using BeforeTargets/AfterTargets.
Signed-off-by: Simon Rozman <simon@rozman.si>
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>
