Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: TestInterfaceHardwareAddrWithGetmac fails on Windows 10 when using virtual adapters #21027

Closed
pkch opened this issue Jul 15, 2017 · 7 comments

Comments

Projects
None yet
5 participants
@pkch
Copy link

commented Jul 15, 2017

Running all.bat on Windows 10 after checking out source from master and disabling cgo (set CGO_ENABLED=0) due to issues with gcc. Go compiled fine, but the tests failed with:

--- FAIL: TestInterfaceHardwareAddrWithGetmac (2.40s)
        net_windows_test.go:614: getmac lists "Ethernet 2", but it could not be found among Go interfaces map[vEthernet (Kubernetes):00:ff:a5:e2:a6:1c vEthernet (DockerNAT):00:15:5d:2b:ba:28 Local Area Connection* 2:1a:4f:32:f7:77:4f Wi-Fi:18:4f:32:f7:77:4f]
FAIL
FAIL    net     12.139s

My "Ethernet 2" adapter is not a real ethernet (I have none), it's a virtual adapter installed with some VPN. Its type is listed as [TAP-Windows Adapter V9[(https://www.iocreed.net/what-is-tap-windows-adapter-and-how-to-remove-it/), and it's apparently required to use OpenVPN.

@bradfitz bradfitz added this to the Go1.9Maybe milestone Jul 15, 2017

@bradfitz bradfitz changed the title Tests fail on Windows 10 due to network adapter issues net: tests fail on Windows 10 due to network adapter issues Jul 15, 2017

@pkch

This comment has been minimized.

Copy link
Author

commented Jul 15, 2017

The test is for function net.Interfaces(). The docs aren't clear about which adapters should be listed, so I'm not sure if the test is expecting too much or if the function returns too little.

The test creates the expected output by running getmac /fo list /v (from the shell), and skipping the adapters with "n/a" in Transport Name or "disabled" or "n/a" in Physical Address. Here's what this yields on my system (no items were skipped):

Connection Name:  Ethernet 2
Network Adapter:  TAP-Windows Adapter V9
Physical Address: 00-FF-A5-E2-A6-1C
Transport Name:   Media disconnected

Connection Name:  Wi-Fi
Network Adapter:  The Broadcom 802.11 Network Adapter provides wireless local area networking.
Physical Address: 18-4F-32-F7-77-4F
Transport Name:   \Device\Tcpip_{7F92366B-4BF9-420F-9F9D-6879F2CB6839}

Connection Name:  vEthernet (Kubernetes)
Network Adapter:  Hyper-V Virtual Ethernet Adapter
Physical Address: 00-FF-A5-E2-A6-1C
Transport Name:   Media disconnected

Connection Name:  vEthernet (DockerNAT)
Network Adapter:  Hyper-V Virtual Ethernet Adapter #2
Physical Address: 00-15-5D-2B-BA-28
Transport Name:   \Device\Tcpip_{45614417-1E8F-4962-8D79-32773F46C325}

Note how two of the adapters have the same Physical Address.

OTOH, net.Interfaces() grabs the information using Windows syscalls, which at some point (in adapterAddresses) yields the list of physical addresses:

00ffa5e2a61c0000
00155d2bba280000
1a4f32f7774f0000
184f32f7774f0000
0000000000000000

Note how all physical addresses are unique.

Consistent with that, net.Interfaces() returns an array of 5 items:

net.Interface{Index:3, MTU:1500, Name:"vEthernet (Kubernetes)", HardwareAddr:net.HardwareAddr{0x0, 0xff, 0xa5, 0xe2, 0xa6, 0x1c}, Flags:0x12}

net.Interface{Index:9, MTU:1500, Name:"vEthernet (DockerNAT)", HardwareAddr:net.HardwareAddr{0x0, 0x15, 0x5d, 0x2b, 0xba, 0x28}, Flags:0x13}

net.Interface{Index:10, MTU:1500, Name:"Local Area Connection* 2", HardwareAddr:net.HardwareAddr{0x1a, 0x4f, 0x32, 0xf7, 0x77, 0x4f}, Flags:0x12}

net.Interface{Index:13, MTU:1500, Name:"Wi-Fi", HardwareAddr:net.HardwareAddr{0x18, 0x4f, 0x32, 0xf7, 0x77, 0x4f}, Flags:0x13}

net.Interface{Index:1, MTU:-1, Name:"Loopback Pseudo-Interface 1", HardwareAddr:net.HardwareAddr(nil), Flags:0x15}}

The test skips the loopback interface.

In other words, net.Interfaces() happens to report vEthernet (Kubernetes) adapter instead of Ethernet 2 adapter expected by the test (both have the same physical address). In addition, the test doesn't expect the adapter Local Area Connection* 2 which the net.Interfaces() does return.

In other words, net.Interfaces returns Ethernet 2, Wi-Fi, vEthernet (Kubernetes), vEthernet (DockerNet), while the test expects Local Area Connection* 2, Wi-Fi, vEthernet (Kubernetes), vEthernet (DockerNet).

Maybe someone familiar with Windows networking could clarify what Interfaces() should return in case of duplicate physical addresses.

For reference, the actual adapters on my system (as shown in Windows control panel) are:

Name:	vEthernet (Kubernetes)
Description:	Hyper-V Virtual Ethernet Adapter
*Physical address (MAC):	00:ff:a5:e2:a6:1c
Status:	Not operational
Maximum transmission unit:	1500
IPv4 address:	169.254.48.97/16
IPv6 address:	fe80::6c6a:e9f:5b04:3061%3/64
DNS servers:	fec0:0:0:ffff::1%1, fec0:0:0:ffff::2%1, fec0:0:0:ffff::3%1
Connectivity (IPv4/IPv6):	Disconnected
	                                   
	                                   
Name:	vEthernet (DockerNAT)
Description:	Hyper-V Virtual Ethernet Adapter #2
*Physical address (MAC):	00:15:5d:2b:ba:28
Status:	Operational
Maximum transmission unit:	1500
IPv4 address:	10.0.75.1/24
IPv6 address:	fe80::80f:e10b:b033:cc81%9/64
DNS servers:	fec0:0:0:ffff::1%1, fec0:0:0:ffff::2%1, fec0:0:0:ffff::3%1
Connectivity (IPv4/IPv6):	Connected to unknown network, no traffic
	                                   
	                                   
Name:	Local Area Connection* 2
Description:	Microsoft Wi-Fi Direct Virtual Adapter
*Physical address (MAC):	1a:4f:32:f7:77:4f
Status:	Not operational
Maximum transmission unit:	1500
IPv4 address:	169.254.254.103/16
IPv6 address:	fe80::4d0:a521:d65f:fe67%10/64
DNS servers:	fec0:0:0:ffff::1%1, fec0:0:0:ffff::2%1, fec0:0:0:ffff::3%1
Connectivity (IPv4/IPv6):	Disconnected
	                                   
	                                   
Name:	Wi-Fi
Description:	The Broadcom 802.11 Network Adapter provides wireless local area networking.
*Physical address (MAC):	18:4f:32:f7:77:4f
Status:	Operational
Maximum transmission unit:	1500
Link speed (Receive/Transmit):	216/144 (Mbps)
DHCP enabled:	Yes
DHCP servers:	192.168.43.1
DHCP lease obtained:	‎Saturday, ‎July ‎15, ‎2017 1:01:43 PM
DHCP lease expires:	‎Saturday, ‎July ‎15, ‎2017 2:01:43 PM
IPv4 address:	192.168.43.186/24
IPv6 address:	fe80::8543:bef4:4263:daef%13/64
Default gateway:	192.168.43.1
DNS servers:	192.168.43.1
DNS domain name:	
DNS connection suffix:	
DNS search suffix list:	
Network name:	AndroidAP  439
Network category:	Public
Connectivity (IPv4/IPv6):	Connected to Internet / Connected to unknown network
	                                   
	                                   
Name:	Ethernet 2
Description:	TAP-Windows Adapter V9
Physical address (MAC):	00:ff:a5:e2:a6:1c
Status:	Not operational
Maximum transmission unit:	1500
Connectivity (IPv4/IPv6):	Disconnected
	                                   
	                                   
Name:	Local Area Connection* 3
Description:	Microsoft Wi-Fi Direct Virtual Adapter #3
*Physical address (MAC):	1a:4f:32:f7:77:4f
Status:	Not Present
Maximum transmission unit:	0
Connectivity (IPv4/IPv6):	Disconnected
@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jul 19, 2017

Very comprehensive report, thank you.

I do not know enough about this subject. But I think Interfaces is correct here. I think the test should ignore interfaces with duplicate MAC address. What do you think @pkch and @mikioh ?

Alex

@bradfitz bradfitz modified the milestones: Go1.9Maybe, Go1.10 Jul 20, 2017

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2017

Looks like this is a bug of TestInterfaceHardwareAddrWithGetmac. There's no guarantee that link-layer identifiers/addresses are unique in node-local scope. They are just unique in each link-local scope.

@mikioh mikioh changed the title net: tests fail on Windows 10 due to network adapter issues net: TestInterfaceHardwareAddrWithGetmac fails on Windows 10 when using virtual adapters Jul 21, 2017

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jul 26, 2017

Looks like this is a bug of TestInterfaceHardwareAddrWithGetmac

Thank you. I will adjust the test to ignore interfaces with duplicate MAC addresses when I get home in August. Unless someone bits me to it.

Alex

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Aug 28, 2017

@pkch can you, please, try https://go-review.googlesource.com/59411 to see if it fixes your problem?

Thank you.

Alex

@gopherbot

This comment has been minimized.

Copy link

commented Aug 28, 2017

Change https://golang.org/cl/59411 mentions this issue: net: ignore duplicate interfaces in TestInterfaceHardwareAddrWithGetmac

@gopherbot gopherbot closed this in c19abe3 Nov 10, 2017

@gopherbot

This comment has been minimized.

Copy link

commented Dec 8, 2017

Change https://golang.org/cl/82975 mentions this issue: net: enable TestInterfaceHardwareAddrWithGetmac on all windows versions

gopherbot pushed a commit that referenced this issue Dec 8, 2017

net: enable TestInterfaceHardwareAddrWithGetmac on all windows versions
Re-work the test to use wmic instead of PowerShell's getmac that's
only avaliable on Server 2008. Maintains duplicate detection added
for #21027.

Tested on windows-amd64-{2008, 2012, 2016} buildlets.
Enabling for Windows XP because it should work[1].

Fixes #20073

[1] https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/wmic_overview.mspx?mfr=true

Change-Id: Ic11d569f7964f61d08ae0dcc1b926efc5336ac5b
Reviewed-on: https://go-review.googlesource.com/82975
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

@golang golang locked and limited conversation to collaborators Dec 8, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.