Huh, I saw a very similar symptom before and attempted to fix it in https://go.dev/cl/483696.

Maybe a new test was added that similarly opens an externally-visible address?

@raghvenders, can you git bisect the commit at which this behavior regressed, and/or use go test -parallel=1 -v to narrow down which specific test function triggers the firewall prompt?

(CC @golang/windows)

(TestTCPListener in particular might be good to double-check; see #60257.)

@bcmills - I am able to reproduce it in TestIPv4MulticastListener listen_test. This happens in dial_test.go too.
I am investigating further and will update.

Huh. I'm not sure why that would trigger the firewall — it is explicitly using only the loopback interface (https://cs.opensource.google/go/go/+/master:src/net/listen_test.go;l=549;drc=a81507868344dccebef13c6d8d890633e59a93e3), which should cause it to not actually require network access.

What version of Windows are you using?

This is I am encountering recent

Edition : Windows 11 Home
Microsoft Windows [Version 10.0.22621.2715]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@bcmills - Do you need any more info on this ? I started encountering this quite recent time, could be a OS patch too.

Do you think exploring multicast listener do any help ?

It would be helpful to know exactly which test (tuple of ifi×net) is triggering the firewall warning. Can you update the test to log that information?

does this info help ? shall I check-in this information so , it will be logged when we do - go test -v ?

2024/01/08 22:38:07 udp x {1 -1 Loopback Pseudo-Interface 1 up|loopback|multicast|running}
2024/01/08 22:38:07 udp4 x {1 -1 Loopback Pseudo-Interface 1 up|loopback|multicast|running}

@bcmills - Kindly suggest.

Are those log lines from before or after the prompt appears?

@bcmills

here is the call stack - may be older code sorry so line numbers may not be right - 20a03fc (origin/master, origin/HEAD, master) runtime/pprof: fix generics function names

it happens at cgocall(asmstdcallAddr, unsafe.Pointer(c)) - syscall_windows.go:544

syscall.SyscallN (c:\Users\Ragul\golang\go\src\runtime\syscall_windows.go:545)
syscall.Syscall (c:\Users\Ragul\golang\go\src\runtime\syscall_windows.go:482)
syscall.bind (c:\Users\Ragul\golang\go\src\syscall\zsyscall_windows.go:1332)
syscall.Bind (c:\Users\Ragul\golang\go\src\syscall\syscall_windows.go:942)
net.(*netFD).listenDatagram (c:\Users\Ragul\golang\go\src\net\sock_posix.go:217)
net.socket (c:\Users\Ragul\golang\go\src\net\sock_posix.go:63)
net.internetSocket (c:\Users\Ragul\golang\go\src\net\ipsock_posix.go:154)
net.(*sysListener).listenMulticastUDP (c:\Users\Ragul\golang\go\src\net\udpsock_posix.go:240)
net.ListenMulticastUDP (c:\Users\Ragul\golang\go\src\net\udpsock.go:363)
net.TestIPv4MulticastListener (c:\Users\Ragul\golang\go\src\net\listen_test.go:563)
testing.tRunner (c:\Users\Ragul\golang\go\src\testing\testing.go:1689)
testing.(*T).Run.gowrap1 (c:\Users\Ragul\golang\go\src\testing\testing.go:1742)
runtime.goexit (c:\Users\Ragul\golang\go\src\runtime\asm_amd64.s:1695)

Please let me know if you need more details.

The stack trace isn't all that useful, sorry — the question is, which subtest is currently running when the prompt first appears? (You can get that by running go test -v within the net package directory.)

@bcmills - pretty much I do as you said, it occurs first at dial_test on TestDialParallel but that is reproducible when we run these 2 tests together example

C:\Users\Ragul\golang\go\bin\go.exe test -timeout 30s -run "^(TestProhibitionaryDialArg|TestDialParallel)$" net -count 1 -v
=== RUN   TestProhibitionaryDialArg
--- PASS: TestProhibitionaryDialArg (0.00s)
=== RUN   TestDialParallel
=== RUN   TestDialParallel/0
=== RUN   TestDialParallel/1
=== RUN   TestDialParallel/2
=== RUN   TestDialParallel/3
=== RUN   TestDialParallel/4
=== RUN   TestDialParallel/5
=== RUN   TestDialParallel/6
=== RUN   TestDialParallel/7
=== RUN   TestDialParallel/8
=== RUN   TestDialParallel/9
=== RUN   TestDialParallel/10
=== RUN   TestDialParallel/11
=== RUN   TestDialParallel/12
--- PASS: TestDialParallel (0.62s)
    --- PASS: TestDialParallel/0 (0.02s)
    --- PASS: TestDialParallel/1 (0.02s)
    --- PASS: TestDialParallel/2 (0.02s)
    --- PASS: TestDialParallel/3 (0.02s)
    --- PASS: TestDialParallel/4 (0.22s)
    --- PASS: TestDialParallel/5 (0.02s)
    --- PASS: TestDialParallel/6 (0.02s)
    --- PASS: TestDialParallel/7 (0.22s)
    --- PASS: TestDialParallel/8 (0.02s)
    --- PASS: TestDialParallel/9 (0.02s)
    --- PASS: TestDialParallel/10 (0.02s)
    --- PASS: TestDialParallel/11 (0.02s)
    --- PASS: TestDialParallel/12 (0.02s)
PASS
Socket statistical information:
(inet6, stream, default): opened=1 connected=0 listened=1 accepted=0 closed=1 openfailed=0 connectfailed=0 listenfailed=0 acceptfailed=0 closefailed=0

ok      net     0.922s

Note: The stack trace I mentioned above was relevant to this test TestIPv4MulticastListener under net, under exact call the firewall pops up.

Hope this is helpful.