Notes — Differences between TAP-Windows driver and CIPE driver
The TAP-Windows driver distributed with OpenVPN 1.5-beta5 and later is derived from Cipe-Win32 2.0-pre15 with some significant changes:
Stability is much improved, especially with sleep/resume, using Michael Clarke’s patch which upgrades the driver to NDIS5, properly implements sleep/resume OIDs, and fixes a race condition between “AdapterTransmit” and “IRP_MJ_READ”.
Added Christof Meerwald’s “Media Status” patch which shows a given TAP-Win32 adapter as being “unplugged” when it is not currently open by an OpenVPN instance.
Modified the MAC generation code to follow the Linux algorithm for generating MACs, using “0:FF:XX:XX:XX:XX” where “XX:XX:XX:XX” is random.
Added code to lock the TAP device so that only one OpenVPN instance can have it open at a time.
Added an MTU parameter which acts like the ifconfig mtu parameter under Linux. The MTU defaults to “1500” and can be changed through the adapter advanced properties dialog.
Set up the driver to keep track of its Rx/Tx stats rather than depending on userspace to set them.
Ran the driver through the windows driver verifier with all testing modes enabled, including low-resource simulation mode. Based on the resulting bug checks, I was able to fix a number of problems including using “MmGetSystemAddressForMdlSafe” instead of “MmGetSystemAddressForMdl”, fixing several places in the code where the return status of “NdisAllocateMemory” is not checked, and making the flags match between “NdisAllocateMemory” and “NdisFreeMemory” calls.
Renamed the driver so that it shows up as a “TAP-Windows” adapter in the network control panel, and does not conflict with the CIPE driver.
Brought the driver up to SMP standards (beta8), redid the packet queueing subroutines as a circular queue for better efficiency and more straightforward locking semantics under SMP.
Fixed dangling IRP bug that could potentially cause a bug check if driver was unloaded or disabled while still open by a userspace process (beta8).
Fixed bug that rendered an adapter instance unusable if a userspace process tried to read a packet of data but provided a buffer that was too small to completely return the packet (beta8).
Added several new ioctls to return interesting status information back to userspace, such as currently configured MTU value, driver version number, and extended error status information (beta8).
Added “tun” device emulation (beta8).
Adapter media state is now controlled directly from userspace using the “TAP_IOCTL_SET_MEDIA_STATUS” ioctl.
An option has been added to the TAP-Windows driver advanced properties page that allows you to control whether the adapter appears to Windows as “Always Connected” or whether the connection status is dynamically brought up and down by OpenVPN (“Application Controlled”).
To a certain extent, backwards compatibility with NT 4 has been sacrificed in the interest of better usability and stability on Win2K/XP.