[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] Re: All NICs are unusable after install of OpenVPN

  • Subject: Re: [Openvpn-users] Re: All NICs are unusable after install of OpenVPN
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Sun, 9 Oct 2005 02:48:47 -0600 (MDT)

On Sat, 8 Oct 2005, James Yonan wrote:

> On Fri, 7 Oct 2005, [ISO-8859-1] Roger Håkansson wrote:
> > > Also, he didn't have that kind of utility/the utility didn't disable NICs.
> > > But in his search of a solution to this problem he updated all drivers
> > > and utilities and now he says that the wired-NIC gets disabled when he
> > > unplugs the cable and the WiFi-NIC gets disabled when he plugs in a
> > > TP-cable.
> > > In his words "this didn't happen before I installed OpenVPN", but my
> > > guess is that an update of this utility is responsible for that.
> > 
> > Some more info on this.
> > According to him, before he installed OpenVPN, when he unplugged the
> > TP-cable the NIC got "Network cable unplugged" (as usual), but after
> > install+uninstall of OpenVPN, the NIC now disappears both from
> > ControlPanel->NetworkConnections and from DriverManager when he unplugs
> > the TP-cable. And it reappears when he plugs it back in.
> > And this was before he ran Windows Update and updated the WiFi-driver.
> > And he doesn't have any utility that handles profiles (and
> > disables/enables NICs depending on profile and link-speed, like IBMs
> > Access Connections like I have on my laptop).
> Try moving the TAP adapter to the bottom on the binding list, as is 
> described in the FAQ and see if that fixes the problem.
> The process by which a new network adapter gets bound into the network 
> stack is a fairly complex process, and Windows does this all on it own -- 
> it gives the driver itself very little control of this process.
> ***************
> >From FAQ:
> I installed OpenVPN on Windows, and now the TAP-Win32 adapter seems to 
> have become the default adapter for certain functions. How can I make my 
> Ethernet adapter the default again?
> When a new network adapter is added, Windows tends to put it at the top of 
> its internal adapter list, making it the default for certain functions.
> In many cases this is undesired -- unfortunately I'm not aware of any way 
> that the TAP-Win32 driver installer can programmatically override this 
> default.
> Luckily, this can be fixed manually by going to Control Panel / Network 
> Connections / Advanced / Advanced Settings. In the top subwindow of the 
> dialog box, move the TAP-Win32 adapter down from the top position.

While it's just conjecture on my part, it's possible that the registry
entries which describe the network bindings are corrupted on this
particular machine and the addition of a new adapter causes a binding
loop.  When the system becomes sluggish, it would be instructive to check
the CPU utilization to see which process is using it.

It's not unusual for the registry entries which describe Winsock and the 
network binding configuration to become corrupted.  It's a common 
enough problem that someone has written a utility to fix it:

http://openvpn.net/bin/WinsockFix.zip (this is just a mirror site -- 
you might want to search the web to see if there's a newer version)

Well, you might wonder, why would the registry become corrupted in the 
first place.  Could a buggy driver corrupt the Winsock registry?

This is why I believe this is highly unlikely: Windows drivers almost
never need to touch the registry.  The TAP-Win32 driver never writes to
the registry, it only reads a few configuration values which represent
settings from the advanced properties panel.

Now that's not to say that a driver can be installed without changing a
lot of registry entries.  In fact when you install a new network driver on
Windows the entire network binding graph, as represented in the registry,
is rebuilt.  The key point is that this installation process is entirely
driven by internal Windows code (tapinstall.exe is just a renamed version
of devcon.exe which is an MS-provided tool for driver installation).  The
only way that a driver can influence the way it is installed by Windows is
through the .inf configuration file (see the OemWin2k.inf in the source

This gets down to what in my view is one of the major shortcomings of the
Windows kernel design.  Windows stores its configuration in the registry,
which is essentially a kind of primitive database.  The registry suffers
from the same reliability problems of any database, in that if a
multi-variable commit transaction is interrupted in the middle of its
operation, it can leave the database in an inconsistent (i.e.  corrupted)
state.  Of course, rebooting will not solve the problem because the
inconsistency is now part of the registry and will persist across reboots.  
Corruption could also occur because of software bugs in registry-writing
code, or if the hard drive controller was reset before it could write its
cache (of added/modified registry entries) to iron oxide.

Unix and derivatives, on the other hand, are driven by configuration files
rather than a configuration DB like the registry.  The Unix kernel never
writes to the configuration files, which means that in a worst case
scenario, if internal kernel data structures are corrupted, a reboot takes
you back to a known good state.

Unix and derivatives made a great design choice.  The best way to avoid 
registry corruption is not to have one in the first place.


Openvpn-users mailing list