Hi, >> I think this logic is needed to prevent duplicate adapter creation >> if adapter was renamed and then new version is installed. > > Is the driver still always updated (i.e., when update required) even if the > adapter is not created because of existing ones found?
At the moment yes. Moreover, the installer will always install the driver whether better drivers already exist. https://github.com/OpenVPN/ovpn-dco-win/blob/master/msm/msi.c#L186 Probably we should remove that flag and hope that UpdateDriverForPlugAndPlayDevices will do the right thing. > Can we add an adapter creation to iservice so that openvp.exe can create > adapters on the fly? An alternative is for the GUI to catch the "no adapters" > error and offer to create one. But that would work only for users who can > elevate and is less opaque to the user. > As we support multiple connections and default to DCO, auto-creating at least > DCO adapters will be an improvement. Yes, iservice can probably just run tapctl.exe --hwid ovpn-dco. Let's do it for 2.6.1 > Can the "Connect team" be convinced to use a different hwid for the adapter? > Using a name to distinguish between adapters installed by different packages > doesn't look very robust. That's what they were planning to do before I asked them not to - I don't think that is a good idea because - it increases maintenance cost - we would need to build/sign two versions of the driver - we are thinking about pushing driver to Windows Update, which requires passing HLK tests, which we do >From adapter usage perspective, adapter name doesn't matter - it could happen so that when both Connect and OpenVPN-GUI are installed, Connect will use GUI adapter and vice versa. If we move adapter creation to MSM, we could have one adapter which is created once and removed when there are no clients. Also creating adapter on demand (we would need to implement that in openvpn3 too) would make this name dependency obsolete. >> + msg(M_WARN, "%s: skip OpenVPN Connect adapter '%ls'", >> __FUNCTION__, pAdapter->szName); > M_INFO may be enough here? In openvpnmsica we use error.h from ..\tapctl, which doesn't have M_INFO. I could probably add it in V2 if you think we need it. > Acked-by Selva Nair <selva.n...@gmail.com> Or in some follow-up patch :) -- -Lev _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel