Unexpected error re-initializing Wintun 0.9.2

Unexpected error re-initializing Wintun 0.9.2

[Brad Spencer]

Using Wintun 0.9.2 on Windows 10 Enterprise 1909 x86_64, creating an 
adapter (and then deleting it) works fine.  And, using the API to move 
packets in and out also works fine.  But, if we create an adapter, then 
delete it, and _then_ try to either open or create again in the same 
process, we get an unexpected error.  For example:

 From `WintunOpenAdapter()`:

```
wintun: NamespaceRuntimeInit: Failed to open private namespace: You were 
not connected because a duplicate name exists on the network. If joining 
a domain, go to System in Control Panel to change the computer name and 
try again. If joining a workgroup, choose another workgroup name. (Code 
0x00000034)
wintun: WintunOpenAdapter: Failed to take pool mutex
```

Alternatively, from `WintunCreateAdapter()`:

```
wintun: CreateAdapter: Creating adapter
wintun: NamespaceRuntimeInit: Failed to open private namespace: You were 
not connected because a duplicate name exists on the network. If joining 
a domain, go to System in Control Panel to change the computer name and 
try again. If joining a workgroup, choose another workgroup name. (Code 
0x00000034)
wintun: SelectDriver: Failed to take driver installation mutex
```

If we create and destroy, and then start a new process, we can create 
and destroy again in that process, but only once.  It does not seem to 
matter if we create a session on the first adapter before destroying it 
or if we actually use it or not to move packets.

We have tried sleeping for 10 seconds (and much longer!) between 
iterations and it seems to make no difference.

Are we misusing or misunderstanding the API?  Is this a bug?

We have created a small stand-alone program that demonstrates the bug on 
a freshly installed Windows 10 Enterprise 1909: 
https://github.com/b-spencer/wintun-adapter-error

-- 
Brad Spencer

Re: Unexpected error re-initializing Wintun 0.9.2

[Jason A. Donenfeld]

Hi Brad,

Thanks for the clear bug report and reproducer. I've never actually
seen anybody use the iso646.h operators before in real code... First
time for everything I guess!

It looks like the issue is that on each iteration of that loop, you're
calling LoadLibrary and FreeLibrary. Instead, only call LoadLibrary
once per process. Then you won't face this issue.

I've written a patch, however, to support the pathological library
reloading pattern in that example, though:
https://git.zx2c4.com/wintun/commit/?id=7710ff187b5079d9f2573608b6cb33b15262b2b8
This will be part of 0.10.1 or 0.11, whichever comes first. But, I'd
really recommend only calling LoadLibrary once per process, regardless
of that fix.

Thanks again for the report.

Jason

Re: Unexpected error re-initializing Wintun 0.9.2

[Brad Spencer]

Thanks!  That makes sense.  I didn't pick up on the fact that we were 
loading and unloading the library, or its significance.  I agree that 
there is no reason to do so.  I think we just ended up with that pattern 
as a natural step in our migration from the pre-0.9 API.

BTW, I know it's unusual, but we find that the word "not" stands out 
more clearly than a lone "!" character.  I guess a few slipped in to the 
test program. :)

-- 
Brad Spencer