-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
x/net/nettest: SupportsIPv6 reports false even IPv6 is enabled #57386
Comments
Change https://go.dev/cl/458096 mentions this issue: |
Don't some operating systems (depending on security policy) throw a confirmation dialog when attempting to listen on any interface other than the loopback? |
I don't know about this, I can only tested it on some of my Linux boxes. The linux-arm* builders also reveal this thing, they support IPv6 but was disabled for loopback (See https://go-review.googlesource.com/c/net/+/458096 for details). |
Yes, the loopback listen (for both IPv4 and IPv6) was explicitly done to avoid OS firewall dialog boxes during tests. |
Then I think test should just use the |
I think the real problem is that It says:
Does that mean?
Seems like we'd want to figure out what this function is supposed to be reporting first. |
Totally agree! For me, I'm leaning to report that we can do IPv6 at least on one of all interfaces. That also help us implementing more easily using |
Something like this:
|
Change https://go.dev/cl/460715 mentions this issue: |
I've reopened this issue because I've mailed a revert for the fix CL (in https://go.dev/cl/460715) — it caused test failures for We can either resolve the problem by implementing |
I mailed https://go-review.googlesource.com/c/net/+/460735 for fixing the tests. The problem is not about |
SupportsIPv6 probe the stack by attempting to listen on
[::1]:0
to detect if IPv6 was enabled. However, servers may disabled IPv6 on loopback interface (for policies, security reason ...), but still enable for the others.For IPv6, maybe it's better to use[::]:0
instead.A better approach is looking for any "UP" interface that we can route ipv4/ipv6 traffic.
The text was updated successfully, but these errors were encountered: