There's only one handle that's likely to be open in a long lived way:
the tun registration handle. So we can force that closed automatically
when the device is about to close, if it's been improperly left open.
Other handles will indeed hold up closing, but if those exist, they're a
sign of a larger bug elsewhere that should be addressed. On the other
hand, tun registration handles might legitimately be open during driver
upgrades. This also saves us the trouble of dereferencing a freed
FileObject as in the general case.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
When we install the Wintun driver to the store, we get exact oem<nn>.inf
filename of the driver in the store we just installed. Since the
installation should be only temporarily, we should uninstall only the
driver we installed.
This also eliminates the need for iterating driver store speeding up
things.
The code we removed was inherited from the installer.dll, where it made
perfect sense to remove all installed Wintun drivers in the update
process.
Suggested-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Simon Rozman <simon@rozman.si>
With all the platforms (including ARM) having at least one driver now,
the dead-code removal #ifdef-s are no longer required.
Suggested-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Simon Rozman <simon@rozman.si>
We must not use the process heap, as it is changeable. Client may change
it causing our HeapFree() to use wrong heap.
Signed-off-by: Simon Rozman <simon@rozman.si>
1. Add driver to the store: SetupCopyOEMInfW()
2. Create the adapter using explicit path to .inf file: DI_ENUMSINGLEINF
3. Delete all Wintun drivers from the store.
This is a subject of further research:
- It appears those adapters survive a reboot. So, Windows must store the
driver somewhere on the disk and the driver removal is not completed.
If the driver removal is not completed until there are existing
adapters, this is excellent, as it will provide a self-cleanup.
- Test multiple adapters with different driver versions. Which driver
wins?
- Are other Wintun adapters interrupted when adding a new one?
- Test Windows 7 behaviour.
Signed-off-by: Simon Rozman <simon@rozman.si>
When debugger is attached, CreateDirectory() with SYSTEM-only SID fails
with "This security ID may not be assigned as the owner of this object.
(Code 0x0000051B)".
Signed-off-by: Simon Rozman <simon@rozman.si>
While Doxygen correctly locates the function documentation when it is
written directly preceding the function body, Microsoft Visual Studio
IDE does not. The former requires the documentation to precede the
function declaration.
Signed-off-by: Simon Rozman <simon@rozman.si>
When an internal function logs an error and its cause, it bloats the log
when the caller logs the cause again.
Signed-off-by: Simon Rozman <simon@rozman.si>
Gather adapter management in adapter.h/.c (formerly devmgmt.h/.c) and
unify HwID tests.
Use "Namespace" namespace in all functions from namespace.h/.c.
Fix char strings in LOG_...
Signed-off-by: Simon Rozman <simon@rozman.si>
WINTUN_LOGGER_... => LOGGER_... => LOG_...
Those macros are internal, so they don/t need to start with WINTUN_...
Replacing the noun LOGGER_... with the verb LOG_... makes the code more
natural to read now.
Signed-off-by: Simon Rozman <simon@rozman.si>
With installer.dll the installer did the decision whether to install or
upgrade the driver according to installer.dll version and hash stored in
registry by MSM.
With wintun.dll we need to know, which version of Wintun driver we are
packing in the resources to decide about driver upgrade. The most
accurate source of the driver version is the DriverVer directive in
[Version] section of the driver's .inf file.
Signed-off-by: Simon Rozman <simon@rozman.si>
