Change https://go.dev/cl/458096 mentions this issue: nettest: use [::] for probing ipv6 capability

Don't some operating systems (depending on security policy) throw a confirmation dialog when attempting to listen on any interface other than the loopback?

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).

https://apple.stackexchange.com/questions/393715/do-you-want-the-application-main-to-accept-incoming-network-connections-pop

Don't some operating systems (depending on security policy) throw a confirmation dialog when attempting to listen on any interface other than the loopback?

Yes, the loopback listen (for both IPv4 and IPv6) was explicitly done to avoid OS firewall dialog boxes during tests.

Don't some operating systems (depending on security policy) throw a confirmation dialog when attempting to listen on any interface other than the loopback?

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 RoutedInterface to test if we can do ipv6 on loopback?

I think the real problem is that SupportsIPv6 isn't defined well enough.

It says:

SupportsIPv6 reports whether the platform supports IPv6 networking functionality.

Does that mean?

• has a global unicast IPv6 address that works?
• can do IPv6 in theory, but might be disabled by a sysctl/OS knob? (so many people turn off their IPv6 for paranoia or while debugging something or from some misguided instructions they read somewhere and then forget they'd turned it off)
• can do IPv6 but only on certain interfaces ("for security reasons" !?)
• can do IPv6 on all interfaces

Seems like we'd want to figure out what this function is supposed to be reporting first.

I think the real problem is that SupportsIPv6 isn't defined well enough.

It says:

SupportsIPv6 reports whether the platform supports IPv6 networking functionality.

Does that mean?

• has a global unicast IPv6 address that works?

• can do IPv6 in theory, but might be disabled by a sysctl/OS knob? (so many people turn off their IPv6 for paranoia or while debugging something or from some misguided instructions they read somewhere and then forget they'd turned it off)

• can do IPv6 but only on certain interfaces ("for security reasons" !?)

• can do IPv6 on all interfaces

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 RoutedInterface.

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 RoutedInterface.

Something like this:

diff --git a/nettest/nettest.go b/nettest/nettest.go
index 8cb26a9..9ba5c99 100644
--- a/nettest/nettest.go
+++ b/nettest/nettest.go
@@ -38,10 +38,10 @@ func probeStack() {
                ln.Close()
                ipv4Enabled = true
        }
-       if ln, err := net.Listen("tcp6", "[::]:0"); err == nil {
-               ln.Close()
+       if _, err := RoutedInterface("ip6", net.FlagUp); err == nil {
                ipv6Enabled = true
        }
+
        rawSocketSess = supportsRawSocket()
        switch runtime.GOOS {
        case "aix":

Change https://go.dev/cl/460715 mentions this issue: Revert "nettest: use RoutedInterface for probing network stack capability"

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 dragonfly and js/wasm (#57623).

We can either resolve the problem by implementing RoutedInterface on those platforms, or taking some alternate approach, or applying build constraints to use RoutedInterface only where supported.

I mailed https://go-review.googlesource.com/c/net/+/460735 for fixing the tests. The problem is not about RoutedInterface, but the code path that rely on old (wrong) behavior needs to be updated.