Today's accomplishment: got sufficiently irritated by Go failing self-tests on stock FreeBSD systems that I finally filed a report on the second issue: https://github.com/golang/go/issues/77411

The first issue on stock FreeBSD is https://github.com/golang/go/issues/70702

It's very obvious that approximately nobody runs Go's all.bash on real FreeBSD systems. At best it is "tested" on Go's builder machines, which are clearly non-standard in multiple ways.

My "Go failing selftests for its net package on FreeBSD" issue¹ turns out to be specific to FreeBSD 15. Evidently there's some networking change that is doing something different from what Go is counting on. If I'm energetic, I can peruse FreeBSD changelogs and stuff.

(It's possible all of the failures involve IPv6 / IPv4 interactions.)

¹ https://github.com/golang/go/issues/77411

net: consistent all.bash failure on stock FreeBSD 15 · Issue #77411 · golang/go

Go version go version go1.25.6 freebsd/amd64 also go version go1.27-devel_d99be5c444 Mon Feb 2 01:42:56 2026 -0800 freebsd Output of go env in your module/workspace: AR='ar' CC='clang' CGO_CFLAGS='...

GitHub

I believe I've found the FreeBSD 15 networking change that breaks Go's net package self-tests, and it's an interesting one¹. As described in the release notes²:

Making a connection to INADDR_ANY, i.e., using it as an alias for localhost, is now disabled by default. This functionality can be re-enabled by setting the net.inet.ip.connect_inaddr_wild sysctl to 1.

I can see the point, even though this is a behavior change.

¹ https://cgit.freebsd.org/src/commit/?id=cd240957d7ba
² https://www.freebsd.org/releases/15.0R/relnotes/#network-general

src - FreeBSD source tree

This is my face that you can do 'ssh 0' (assuming your machine runs a SSH daemon) and it will probably work. Well, unless you're on FreeBSD 15. Or OpenBSD, which laughs at you.

For proper credit (or if you prefer, blame), I learned about 'ssh 0' from a comment @lyda left on my techblog. But now that I've seen it I can't unsee it. What else will accept '0' as a hostname? Feel free to try it today.

(Firefox will, it looks like.)

@cks @lyda

Everything that can accept human-readable IPv4 addresses in place of hostnames, and that does so by using the conventional C library inet_aton() or inet_pton() functions.

A single (32-bit) number has been an accepted human-readable form from the start, back in the 4.3BSD days. It's a thing that gets regularly rediscovered.

(Bernstein's networking tools use a ip4_scan() function that only supports strict 4-decimal-numbers form. But several of them special case and re-map the string "0" before calling this function. libowfat's scan_ip4() is similar to ip4_scan(). As is ip4_scan() in @ska's libstddjb.)

This and three other accepted formats are explained in all of the #FreeBSD, #OpenBSD, #NetBSD, and Linux GNU libc manual pages. They also explain why 0x00000000 and 0x7F000001 and 0177.1 will work as IPv4 addresses with such programs.

#BerkeleySockets

@JdeBP @cks @lyda @ska it’s worth pointing out the inet_aton man page mentions this behaviour but inet_pton doesn’t and it doesn’t support it (see CAVEATS on OpenBSD’s version). The result is, as mentioned upthread OpenBSD laughs at you twice, once as many tools have been switched to inet_pton and again because 0.0.0.0 doesn’t work anyway. A good reminder to use modern APIs.

@JdeBP @cks @lyda @ska and it seems as part of the ASR resolver within libc getaddrinfo() will call inet_pton rather than inet_aton — see sockaddr_from_str — this is why e.g. “ssh 0” gives a “no address associated with name” error. This looks like it’s been around for ~14 years, so this hasn’t worked on OpenBSD for a long time.

Of course because it doesn’t special case numeric addresses putting:
localhost 127.0.0.1 0
in /etc/hosts works. But don’t do that.