|
|
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 distribution). 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. James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |