tap-windows6
tap-windows6 copied to clipboard
OpenVPN
Manual MAC address no longer works TAP adaptor 9.24.2
While assigning a MAC address via the Windows device manager advance dialogue is still possible, the driver no longer uses that value and always falls back to the value assigned at install. Tested on OpenVPN 2.4.8 Win7 and 10. https://forums.openvpn.net/viewtopic.php?f=1&t=29152
Hi,
On Thu, Nov 07, 2019 at 03:08:21PM -0800, Richard Bonhomme wrote:
While Assigning a MAC address via the Windows device manager advance dialogue is still possible, the driver no longer uses that value and always falls back to the value assigned at install. Tested on Win7 and 10.
Indeed there were changes in regard to MAC address handling (due to it failing WLHK tests related to MAC address changing)... maybe related to
commit f4f6464cace83ecf6241dbcda0bc8bb62e8a7794 Author: Stephen Stair [email protected] Date: Mon Dec 17 21:52:08 2018 -0800
Fix support for changing MAC Address
need to look closer. But not this weekend.
gert
-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]
In the last openvpn-install-2.4.8-I602-Win7 package, the problem persists. The driver is installed with the version 9.24.2.601. Reinstalled several times. Removed the driver from the system.
Hi,
On Mon, Sep 21, 2020 at 07:15:49AM -0700, Yonggang Luo wrote:
how to fixes this issue?
Find someone who understands device driver programming, has an interest in this feature, and can see what broke in the fairly large change set between 2.4.7 and 2.4.8 - which was due to MS testing requirements for driver signing, not because we had fun doing so.
For normal OpenVPN usage, TAP driver MAC address doesn't need to be settable, so it's not of high prio for the OpenVPN developers to fix this.
gert
"If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]
Where are the tags 2.4.7 and 2.4.8? I can not found the tags in git repository
@lygstate you can check what tap-windows6 version OpenVPN 2.4.x releases have used by checking the history of this file: https://github.com/OpenVPN/openvpn-build/blob/master/windows-nsis/build-complete.vars
What's the intension of the following change:
src/OemVista.inf.in | 2 +-
src/constants.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/OemVista.inf.in b/src/OemVista.inf.in
index c7fd653..ea36f0d 100644
--- a/src/OemVista.inf.in
+++ b/src/OemVista.inf.in
@@ -89,7 +89,7 @@
AddReg = @[email protected]
AddReg = @[email protected]
Characteristics = @PRODUCT_TAP_WIN_CHARACTERISTICS@
- *IfType = 53 ; IF_TYPE_PROP_VIRTUAL
+ *IfType = 0x6 ; IF_TYPE_ETHERNET_CSMACD
*MediaType = 0x0 ; NdisMedium802_3
*PhysicalMediaType = 0 ; NdisPhysicalMediumUnspecified
diff --git a/src/constants.h b/src/constants.h
index c862f5b..524d1b7 100644
--- a/src/constants.h
+++ b/src/constants.h
@@ -101,7 +101,7 @@
#define TAP_CONNECTION_TYPE NET_IF_CONNECTION_DEDICATED
// This value must match the *IfType in the driver .inf file
-#define TAP_IFTYPE IF_TYPE_PROP_VIRTUAL
+#define TAP_IFTYPE IF_TYPE_ETHERNET_CSMACD
//
// This is a virtual device, so it can tolerate surprise removal and
Hi, On Mon, Sep 21, 2020 at 07:15:49AM -0700, Yonggang Luo wrote: how to fixes this issue? Find someone who understands device driver programming, has an interest in this feature, and can see what broke in the fairly large change set between 2.4.7 and 2.4.8 - which was due to MS testing requirements for driver signing, not because we had fun doing so. For normal OpenVPN usage, TAP driver MAC address doesn't need to be settable, so it's not of high prio for the OpenVPN developers to fix this.
Unfortunately some commits made that time were incomplete/untested. Looks like the change to the way MAC address is read was incomplete as well.
@lygstate Could you please check whether this one fixes it? https://github.com/OpenVPN/tap-windows6/compare/master...selvanair:custom-mac-address You may have to delete exisitng TAP Windows adapters and recreate (not just update the driver). Note that you must use a MAC starting with 02.
Hi,
On Mon, Sep 21, 2020 at 10:14:54AM -0700, Selva Nair wrote:
Unfortunately some commits made that time were incomplete/untested. Looks like the change to the way MAC address is read was incomplete as well.
Ugh. I assumed that any "we broke it" issues would be caught by the - fairly extensive - Windows driver testing machinery. But it seems it did not cover these, or we did not follow up.
Apologies to everyone :-( - and thanks that you looked into it.
gert
"If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]
Hi, On Mon, Sep 21, 2020 at 07:15:49AM -0700, Yonggang Luo wrote: how to fixes this issue? Find someone who understands device driver programming, has an interest in this feature, and can see what broke in the fairly large change set between 2.4.7 and 2.4.8 - which was due to MS testing requirements for driver signing, not because we had fun doing so. For normal OpenVPN usage, TAP driver MAC address doesn't need to be settable, so it's not of high prio for the OpenVPN developers to fix this.
Unfortunately some commits made that time were incomplete/untested. Looks like the change to the way MAC address is read was incomplete as well.
@lygstate Could you please check whether this one fixes it? master...selvanair:custom-mac-address You may have to delete exisitng TAP Windows adapters and recreate (not just update the driver). Note that you must use a MAC starting with 02.
Direct modify this file not working, cauase the driver can not be installed.
The patch modifies the Inf.in file which is used by the build script to generate the Inf file. And then the driver has to be installed using that Inf.
I know modifying the registry will work, but that doesn't test the patch. If you have a setup to apply the patch, build the driver and install it please test. Such a driver will lack signature --- see README.rst on how to install unsigned drivers.
Otherwise @mattock we'll have to make a test installer.
Hi, On Mon, Sep 21, 2020 at 07:15:49AM -0700, Yonggang Luo wrote: how to fixes this issue? Find someone who understands device driver programming, has an interest in this feature, and can see what broke in the fairly large change set between 2.4.7 and 2.4.8 - which was due to MS testing requirements for driver signing, not because we had fun doing so. For normal OpenVPN usage, TAP driver MAC address doesn't need to be settable, so it's not of high prio for the OpenVPN developers to fix this.
Unfortunately some commits made that time were incomplete/untested. Looks like the change to the way MAC address is read was incomplete as well.
@lygstate Could you please check whether this one fixes it? master...selvanair:custom-mac-address You may have to delete exisitng TAP Windows adapters and recreate (not just update the driver). Note that you must use a MAC starting with 02.
why mac should starting with 02？
~I can only guess for the reason behind 02. One has to restrict the MAC to an acceptable "locally administered MAC address". Checking for 02 instead of just the U/L bit appears to be a choice made when it was coded (not by me). In principle we could have allowed more without colliding with any OUIs.~
Ignore all that any with bit 2 of byte 1 equal to 1 should work -- starting with 02 was the only one I had ever used and was writing from confused memory..
The patch modifies the Inf.in file which is used by the build script to generate the Inf file. And then the driver has to be installed using that Inf.
I know modifying the registry will work, but that doesn't test the patch. If you have a setup to apply the patch, build the driver and install it please test. Such a driver will lack signature --- see README.rst on how to install unsigned drivers.
Otherwise @mattock we'll have to make a test installer.
Can we fix the CI to creating a testing driver automatically
Ignore the comment about starting with 02 -- any valid "locally administered address" should work once the INF is fixed.
We don't have any CI in this repository, though we probably should. Getting evne unsigned drivers as build artifacts for PRs would be very useful.
According to this article it is quite easy to boot Windows 10 temporarily into mode that allows unsigned drivers to be loaded. I can build unsigned drivers and send a link tomorrow.
The official release/signing process for tap-windows6 (MSM + new OpenVPN installer) takes so much time (~4 hours) that I really can't do it except for official releases.
@mattock unsigned driver are enough, so user doesn't need to build it to verify things, construct a build env are not that easy
Although my patch fixes reading the MAC set by user, its not enough. I only tested that the MAC of the adapter changes and we get an IP via dhcp, not that the tunnel really "works"..
Previously we used to overwrite the permanent address by what's set by the user. Now we only set the current address which is good, I suppose. But, ProcessARP() in txpath.c compares the src MAC with the permanent address not the current address. This is not going to work.
Did this pass any of the HLK tests?
In dhcp.c the CurrentAddress is checked which is good.
@mattock: hold off on generating the test driver. We may need more fixes -- this time real code changes :)
@selvanair pretty much all the HLK tests passed. Those few that failed were probably not related, but I can't be sure of that.
If getting HLK to work for tap-windows6 was not such a pain it would be good to use it for regression testing.
@lygstate ok, I'll have unsigned drivers for you guys tomorrow.
Unsigned driver never worked for me (testsigning is on). Doesn't load unless its signed with some certificate which need not be trusted. I use a code-signing cert issued by my own CA and that works. Loading the CA to the trusted roots in Windows makes the install dialog look more legit, but not required.
Hi,
On Wed, Sep 23, 2020 at 10:23:41AM -0700, Selva Nair wrote:
Although my patch fixes reading the MAC set by user, its not enough. I only tested that the MAC of the adapter changes and we get an IP via dhcp, not that the tunnel really "works"..
Previously we used to overwrite the permanent address by what's set by the user. Now we only set the current address which is good, I suppose. But, ProcessARP() in txpath.c compares the src MAC with the permanent address not the current address. This is not going to work.
Did this pass any of the HLK tests?
To make the HLK test, we needed to run in TAP mode, with a p2p setup (because the HLK test injects lots of "interesting" packets that it wants to see on the other end, including varying src/dst MAC addresses).
So, no, these bits have never been truly tested it seems. Bah :-(
gert
-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]
Okay, looks like both proxy arp and IPv6 NA are affected. In tun mode, I can ping the interface address but nothing else as would be expected if proxy arp fails. I'll do some more tests as this looks like something we can fix without needing Windows driver foo.. sigh..
Hi,
On Wed, Sep 23, 2020 at 11:08:01AM -0700, Selva Nair wrote:
Okay, looks like both proxy arp and IPv6 NA are affected. In tun mode, I can ping the interface address but nothing else as would be expected if proxy arp fails. I'll do some more tests as this looks like something we can fix without needing Windows driver foo.. sigh..
Now this is something I feel more comfortable reviewing - it's just C code looking at packet offsets.
I do not have a test rig to build and test the driver right now, so I can only stare and point...
gert
"If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]
@mattock unsigned driver are enough, so user doesn't need to build it to verify things, construct a build env are not that easy
@lygstate Its simpler than it looks. Assuming you have python installed, download EWDK iso and mount it as, say, drive E: Then cd to tap-windows6 directory and edit paths.py to have EWDK = E:. That's all what it takes.
To build unsigned drivers, run "python buidtap.py -b"
Hi,
patch has been merged (thanks, Selva) - @mattock: can you bump the driver version and build a new driver for us, please?
gert
-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]
@cron2 sure. Should we go the "unsigned test driver first" -> "test" -> "release driver second" route? Or are the fixes "obviously correct" and/or tested? :smile:
@mattock: I've mildly tested using a self-signed driver on a Windows 10, and the two patches merged cant possibly break anything. But always better to get more test reports from users as driver programming is not my thing.
The driver I built is available if there is interest (will have to be installed using tapinstall or devcon) (oops, keyboard gone wild...)