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

pkch · 2017-07-15T19:30:15Z

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.

The text was updated successfully, but these errors were encountered:

pkch · 2017-07-15T21:27:17Z

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 · 2017-07-19T03:54:57Z

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

mikioh · 2017-07-21T02:45:37Z

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.

alexbrainman · 2017-07-26T07:24:30Z

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 · 2017-08-28T02:36:51Z

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

Thank you.

Alex

gopherbot · 2017-08-28T02:41:28Z

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

gopherbot · 2017-12-08T17:52:43Z

Change https://golang.org/cl/82975 mentions this issue: 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>

bradfitz added help wanted OS-Windows Testing An issue that has been verified to require only test changes, not just a test failure. labels Jul 15, 2017

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

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

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

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

gopherbot closed this as completed in c19abe3 Nov 10, 2017

golang locked and limited conversation to collaborators Dec 8, 2018

gopherbot added the FrozenDueToAge label Dec 8, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

pkch commented Jul 15, 2017

pkch commented Jul 15, 2017 •

edited

alexbrainman commented Jul 19, 2017

mikioh commented Jul 21, 2017

alexbrainman commented Jul 26, 2017

alexbrainman commented Aug 28, 2017

gopherbot commented Aug 28, 2017

gopherbot commented Dec 8, 2017

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

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

Comments

pkch commented Jul 15, 2017

pkch commented Jul 15, 2017 • edited

alexbrainman commented Jul 19, 2017

mikioh commented Jul 21, 2017

alexbrainman commented Jul 26, 2017

alexbrainman commented Aug 28, 2017

gopherbot commented Aug 28, 2017

gopherbot commented Dec 8, 2017

pkch commented Jul 15, 2017 •

edited