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: TestInterfaceAddrsWithNetsh is flaky #13981

Closed
jucie opened this issue Jan 16, 2016 · 16 comments

Comments

Projects
None yet
5 participants
@jucie
Copy link

commented Jan 16, 2016

What version of Go are you using (go version)?
go version go1.6beta2 windows/amd64

What operating system and processor architecture are you using?
OS Name: Microsoft Windows 8 Single Language
OS Version: 6.2.9200 N/A Build 9200
Intel64 Family 6 Model 58 Stepping 9 GenuineIntel ~2400 Mhz

What did you do?
cd go\src
all.bat

What did you expect to see?
A clean build & test output.

What did you see instead?
--- FAIL: TestInterfaceAddrsWithNetsh (6.59s)
net_windows_test.go:433: Local Area Connection* 13: unexpected addresses list ["169.254.129.89/16" "fe80::85ef:998a:25c7:8159"], want ["fe80::85ef:998a:25c7:8159"]
net_windows_test.go:433: Bluetooth Network Connection: unexpected addresses list ["169.254.80.206/16" "fe80::4ca8:627d:ea16:50ce"], want ["fe80::4ca8:627d:ea16:50ce"]
net_windows_test.go:433: Ethernet: unexpected addresses list ["169.254.130.171/16" "fe80::d16c:aa5d:b3b4:82ab"], want ["fe80::d16c:aa5d:b3b4:82ab"]
net_windows_test.go:433: isatap.{729DD26D-8C51-46ED-8530-F0CB45D3073B}: unexpected addresses list ["fe80::5efe:c0a8:167"], want ["fe80::5efe:192.168.1.103"]
FAIL

@ianlancetaylor ianlancetaylor changed the title TestInterfaceAddrsWithNetsh doesn't pass in my Windows box. net: TestInterfaceAddrsWithNetsh doesn't pass in my Windows box Jan 16, 2016

@ianlancetaylor ianlancetaylor added this to the Go1.6 milestone Jan 16, 2016

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 16, 2016

@mikioh mikioh changed the title net: TestInterfaceAddrsWithNetsh doesn't pass in my Windows box net: TestInterfaceAddrsWithNetsh is flakey Jan 16, 2016

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jan 16, 2016

Thanks for the report. It looks like the test has two issues. One is that it doesn't assume netsh command never returns IPv4 link-local addresses. Another is that it does literal address comparison incorrectly for IPv6 addressing for IPv4/IPv6 translators (see RFC 6052) used in ISATAP, 6to4, XLAT and MAP.

@mikioh mikioh modified the milestones: Go1.7, Go1.6 Jan 16, 2016

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jan 17, 2016

We can skip TestInterfaceAddrsWithNetsh in Go 1.6 because we have bottom line test cases in interface_test.go and interface_windows_test.go.

@mikioh mikioh added the Testing label Jan 17, 2016

@mikioh mikioh changed the title net: TestInterfaceAddrsWithNetsh is flakey net: TestInterfaceAddrsWithNetsh is flaky Jan 17, 2016

@gopherbot

This comment has been minimized.

Copy link

commented Jan 17, 2016

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

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jan 17, 2016

@jucie please run

netsh interface ipv4 show address

command and show us its output. Thank you.

Alex

@jucie

This comment has been minimized.

Copy link
Author

commented Jan 17, 2016

netsh interface ipv4 show address >netshOutput.txt
netshOutput.txt

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jan 17, 2016

Perhaps we should just skip interfaces that are not "enabled". @jucie can you show us more, please? It would be nice to know what

netsh interface ipv4 show int
netsh interface ipv4 show addr
netsh interface ipv6 show int
netsh interface ipv6 show addr

commands output. Thank you.

Alex

@jucie

This comment has been minimized.

Copy link
Author

commented Jan 18, 2016

I collected the output of all this commands into a single file, Alex.
commandsOutput.txt
Feel free to ask for any additional info you may need. It is a pleasure for me to help you.

gopherbot pushed a commit that referenced this issue Jan 18, 2016

Mikio Hara
net: disable TestInterfaceAddrsWithNetsh on windows
Updates #13981.

Change-Id: Id8f3cd56a81a7a993cea5c757e619407da491fed
Reviewed-on: https://go-review.googlesource.com/18710
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jan 18, 2016

@jucie, thank you for testing. It seems to me that netsh does not display any addresses for interfaces that are disabled. So your CL 18711 to skip appropriate tests sounds like a good solution for this issue. One thing that still puzzules me is (see your output above):

net_windows_test.go:433: Local Area Connection* 13: unexpected addresses list ["169.254.129.89/16" "fe80::85ef:998a:25c7:8159"], want ["fe80::85ef:998a:25c7:8159"]

"169.254.129.89/16" is returned by Go net library for your "Local Area Connection* 13" network interface. Given that netsh displays no such address, where does this address come from? @mikio ? @jucie, did you had this address configured / used in the past? If so, how is this address of any use to anyone? @mikio ? Perhaps we should return no address if interface is down?

Alex

@jucie

This comment has been minimized.

Copy link
Author

commented Jan 18, 2016

Hi, Alex. The suggestion to skip TestInterfaceAddrsWithNetsh was from @mikioh. I don't know that code.

This box of mine is a notebook. I only use Wifi connection. Maybe 169.254.129.89/16 is for the wired connection, that I don't use anymore. I used wired connection a while back, when my Wifi wasn't ok.

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jan 19, 2016

The suggestion to skip TestInterfaceAddrsWithNetsh was from @mikioh. I don't know that code.

I was refering to your https://go-review.googlesource.com/#/c/18711/

Thank you for checking your usage of 169.254.129.89/16. My questions to @mikioh still stand.

Alex

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jan 19, 2016

As mentioned above, 169.254.0.0/16 is the prefix containing IPv4 link-local addresses: https://tools.ietf.org/html/rfc3927.

As per MSDN, IP_ADAPTER_UNICAST_ADDRESS strucuture contains a few states such as Flags and DadState. That means that it's possible for netsh command to veil IPv4 addresses which are not important for non-IP infrastructure applications with its display filters even on an interface that is operational status is up. I think that addresses displayed by netsh command are a subset of addresses returned from GetAdapterAddresses but not vice versa.

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jan 19, 2016

Thank you for explaining @mikioh. But I still don't see how it is helpful to user of GetAdapterAddresses that Ethernet interface has "169.254.130.171/16" address. It is marked as "DHCP enabled", so even when we bring this interface up there is no guarantee that address will remain. I think this knowledge is pretty useless and confusing. Don't you think?

Can you also, please, review https://go-review.googlesource.com/#/c/18711/ ? Thank you.

Alex

@gopherbot

This comment has been minimized.

Copy link

commented Jan 19, 2016

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

@jucie

This comment has been minimized.

Copy link
Author

commented Jan 19, 2016

Only to make things clear, I must say that https://go-review.googlesource.com/#/c/18711/ is Tim Ebringer's work, not mine.

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jan 20, 2016

Only to make things clear, I must say that https://go-review.googlesource.com/#/c/18711/ is Tim Ebringer's work, not mine.

My confusion. Sorry about that.

Alex

@gopherbot gopherbot closed this in 489f65b Jan 21, 2016

@golang golang locked and limited conversation to collaborators Jan 23, 2017

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.