Calling GetAdaptersAddresses with GAA_FLAG_INCLUDE_ALL_INTERFACES for listing all network interfaces including virtual/logical/pseudo stuff, or just checking the results contained in scraping stuff.

It's all your call. Because unlike BSD variants and Linux, Windows has not only common virtual interfaces such as ISATAP/6to4/Teredo/L2TP/PPPoE tunnel interfaces but pseudo-application helper network interfaces such as IKE blah blah.

FYI, GetAdaptersAddresses is not provided wide function. So it need to convert character-set using MultiByteToWideChar.

@mikioh I have plan for fixing TestInterfacesWithNetsh (CL 17850), but looking for suggestions on how to modify TestInterfaceHardwareAddrWithGetmac to make it PASS here. Thank you.

Alex

CL https://golang.org/cl/17850 mentions this issue.

@mikioh TestInterfacesWithNetsh is fixed now. But TestInterfaceHardwareAddrWithGetmac is still broken. Do you have any suggestions of changing the test so it PASSes? Thank you.

Alex

@alexbrainman,

Sorry, I'm not a windows user and have no windows box. I'd recommend you to drop or disable TestInterfaceHardwareAddrWithGetmac unless you are sure getmac command uses information from where and how. It's fine because they are auxiliary test cases and we already have other test cases in interface_test.go and interface_windows_test.go.

... It's fine because they are auxiliary test cases and we already have other test cases in interface_test.go and interface_windows_test.go.

I have created CL 17993 to test your theory - just to see what tests will fail if I leave Interface.HardwareAddr blank. It appears (https://storage.googleapis.com/go-build-log/74b9c8ae/windows-amd64-gce_e2dcba01.log) only TestInterfaceHardwareAddrWithGetmac fails:

--- FAIL: TestInterfaceHardwareAddrWithGetmac (1.13s)
    net_windows_test.go:515: unexpected MAC addresses ["Local Area Connection=00:00:00:00:00:00"], want ["Local Area Connection=42:01:0a:f0:00:13"]
FAIL
FAIL    net 25.539s

so if we disable this test, then we can easily regress just like I did in CL 17993.

I think we need to keep as much of TestInterfaceHardwareAddrWithGetmac as we can.

Alex

I have created CL 17993 to test your theory

Sorry, I don't understand why it's related to. If you want to have a unit test which verifies payload for some reason, please do it. I don't think TestInterfaceHardwareAddrWithGetmac is a unit or integration test case. It looks an end-to-end test case. For standard library, there's no reason to prefer end-to-end test to unit/integration test.

CL https://golang.org/cl/17994 mentions this issue.