net: TestInterfaceHardwareAddrWithGetmac fails on Windows 10 when using virtual adapters

[pkch]

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.

[pkch]

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]

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]

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]

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]

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

Thank you.

Alex

[gopherbot]

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

[gopherbot]

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