wintun/api, branch 0.10.2

api: upgrade logging

2021-02-16T03:19:21Z

Log runtime information to quickly check whether the values are sane when analyzing error logs sent in by users. Signed-off-by: Simon Rozman

api: tighten function parameter code analysis annotations

2021-02-04T18:00:17Z

Signed-off-by: Simon Rozman

api: truncate long log lines with …

2021-02-04T17:39:10Z

Signed-off-by: Simon Rozman

api: unify NetCfgInstanceId registry retrieval

2021-02-04T17:39:10Z

Signed-off-by: Simon Rozman

api: ensure that device object exists before returning from open/create

2021-02-03T21:36:41Z

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 Signed-off-by: Jason A. Donenfeld

global: bump copyright

2021-01-30T15:45:26Z

Signed-off-by: Jason A. Donenfeld

api: use custom devpkey for pool

2021-01-30T15:41:16Z

It seems like the friendly name is still getting reset sometimes. Rather than swimming upstream, it turns out we can just use a custom devpkey that, according to msdn, is respected. https://docs.microsoft.com/en-us/windows-hardware/drivers/install/creating-custom-device-properties Signed-off-by: Jason A. Donenfeld

api: close private namespace when unloading DLL

2020-12-17T18:00:25Z

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 Signed-off-by: Jason A. Donenfeld

api: delay load remaining dlls to work around forwarder gotchas

2020-11-27T13:52:03Z

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

api: skip notifying driver when there are no receive packets yet

2020-11-27T13:52:03Z

Signed-off-by: Simon Rozman