Hi, On Fri, Apr 3, 2020 at 5:06 PM Nathan Stratton Treadway <natha...@ontko.com> wrote:
> > As I mentioned in the previous email, the > emvista.inf_amd64_6d4bec28a2ef0cdf has a timestamp which coincides with > the moment that the OpenVPN installer was being run. > > However, I noticed that the oem43.inf file does have an earlier > timestamp: > > ===== > Directory of c:\windows\inf > 03/26/2020 04:03 PM 7,537 oem43.inf > 03/27/2020 11:09 AM 8,828 oem43.PNF > ===== > > ... though weirdly Windows on that box was reinstalled in the _morning_ of > 3/26, and 16:03 doesn't correspond to any entries at all in the > setupapi.dev.log file (which jumps from 2020/03/26 12:30:18 in one entry > to 2020/03/27 07:50:45 in the next). So it doesn't quite seem like > oem43.inf would have been created during the initial reinstall of > Windows, but I also don't know what would have created it later that > day... > > The c:\windows\inf\oem43.inf file is identical to the one in C:\Program > Files\TAP-Windows\driver: > > ===== > $ sha1sum failed_windows-inf_oem43.inf failed_program-files_OemVista.inf > d85f4e65fe10f13ded1780ddbd074edfc75f2d25 failed_windows-inf_oem43.inf > d85f4e65fe10f13ded1780ddbd074edfc75f2d25 failed_program-files_OemVista.inf > ===== > > ... but I suppose that might just indicate that the Win7 and Win10 > versions of that file are identical (if in fact the \windows\inf\ copy > came from the Win7 drivers somehow). > I can confirm that a previously installed cross-signed version of tap0901.sys does cause the behaviour reported here. I did the following: On a Win10 machine with openvpn 2.4.8 installed and working (i) Install the 2.4.8 Windows 7 release --> installation success, OpenVPN continues to work The tap driver properties show the attestation signed driver is still in use although that's not what is in the C:\Program Files\Tap-Windows\driver at this point. (ii) Delete all adapters, cleanup using samuli's powershell script (this is important) and run addtap.bat The run succeeds, but no new adapter is visible, device manager shows the dreaded code52 (signature) error. At this point the driver has changed to the cross-signed (win7) one. And here is the rub: (iii) Install the 2.4.8 Window 10 release on top: this does not fix the problem. setupapi log shows windows is picking the already installed tap0901.sys, not the new one. I don't think just uninstalling the old version first would have helped. At this point, deletalltap.bat, followed by cleanup and addtap.bat fixes the problem. So, it looks clear that, somehow, a cross-signed tap driver with inf file matching what we have in 2.4.8 was present in the system as Nathan has already concluded. As mistakenly installing Windows 7 version and trying to correct it without a thorough cleanup could easily happen, we need to do something to avoid such errors in the next release. Some possibilities (all untested) (i) In the inf file we have [Source Disk Files] tap0901.sys = 1 That line could include the file size as tap0901.sys = 1,,size-of-file Not very robust as it depends on just the size of the .sys file (assuming its different). (ii) Add an identifier to the inf file to make the two versions (win7/win10) different. (iii) Have the installer delete all tap adapters and do a cleanup before starting installation. This is very invasive and adversely affects those who have multiple adapters, removes customized adapter names etc. By the way, while the Remove-tapwindows.ps1 script is very handy, it works only if all adapters are first removed using deltapall.bat or something equivalent. Adding that functionality to the script would be very useful. Regards, Selva
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
