Chris SiebenmannFeb 2

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.

Show threadChris SiebenmannFeb 4

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
Show threadChris Siebenmann

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

Feb 4 at 8:09pmWeb
Show threadChris SiebenmannFeb 5
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.
Show threadChris SiebenmannFeb 5

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

Show threadChris SiebenmannFeb 5

Bonus round: this 'ssh 0' behavior also works for the IPv6 equivalent, 'ssh ::0' or 'ssh ::'. That means it will probably also work in browsers.

Surprise: blocking DNS rebinding to localhost requires screening out more than 127/8 and ::1 answers. This is my face.

Show threadChris SiebenmannFeb 5
It turns out that 0.0.0.0 was already known as an issue for browsers; in 2024 there was a '0.0.0.0 Day' security issue that prompted Chrome and Safari to block access to it (and hopefully the IPv6 version too). One article from the time is from the Register (I know, but): https://www.theregister.com/2024/08/09/0000_day_bug/
It's 2024 and we're just getting round to stopping browsers insecurely accessing 0.0.0.0

Can't reach someone's private server on localhost from outside? No problem

The Register
Show threadإمي ❄️🏳️‍⚧️🇵🇸Feb 5
@cks Oh. We have a service that calls external URLs, and we made sure it fails on local and RFC 1918 addresses (and other special address ranges I can't recall right now). I better check what happens if it encounters 0.0.0.0.
Show threadmirabilosFeb 6

@cks thankfully not on sane systems:

ssh: connect to host :: port 22: Invalid argument
Show threadreggie seidmanFeb 5
I stumbled across this accidentally a long time ago.
Show threadJustin AzoffFeb 5
@cks 23 years ago glibc broke this https://lists.debian.org/debian-glibc/2003/03/msg00403.html I was annoyed enough to file a bug.. I thought it was telnet that broke but it got routed to the right place
Re: Bug#185485: telnet: resolving ip in decimal form stopped working

Show threadpenguin42Feb 5
@cks @lyda I've used that in the past on qemu migration (which I used to work on); when you're testing between two instances on the same machine the easiest way is migrate tcp:0:portnumber
Show threadKevin LydaFeb 5
@cks I never learned to type so I'll use any shortcut going! Pretty sure I learned telnet 0 back when I was learning about socket programming - then applied it to ssh. I didn't learn 127.1 until someone explained similar behaviour in ipv6. Obviously more useful there.
Show threadJdeBPFeb 5

@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

Show threadDavid LeadbeaterFeb 6
@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.
Show threadDavid LeadbeaterFeb 6

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

Show threadChris SiebenmannFeb 6

@dgl @JdeBP @lyda @ska Actually I believe connecting to 0.0.0.0 itself does still work on OpenBSD (or at least it does in testing for me). You need a tool and a tool environment that will do it (which stock OpenBSD SSH doesn't seem to), but given such a tool¹ it appears to work.

¹ I use https://github.com/siebenmann/call but that's because I wrote it, and also it's in Go so it bypasses some of the OpenBSD C library restrictions on what it will map to 0.0.0.0.

GitHub - siebenmann/call: Basically a Go version of something vaguely like Netcat that got complicated

Basically a Go version of something vaguely like Netcat that got complicated - siebenmann/call

GitHub
Show threadDavid LeadbeaterFeb 6
@cks @JdeBP @lyda @ska Go special cases OpenBSD: https://github.com/golang/go/blob/d4febb45179fa99ee1d5783bcb693ed7ba14115c/src/net/ipsock_posix.go#L161-L163 (maybe it should also now special case FreeBSD there? -- I commented on the issue)
go/src/net/ipsock_posix.go at d4febb45179fa99ee1d5783bcb693ed7ba14115c · golang/go

The Go programming language. Contribute to golang/go development by creating an account on GitHub.

GitHub
Show threadChris SiebenmannFeb 6

@dgl @JdeBP @lyda @ska Oh, nice. I tried to find something doing that in the net package but clearly didn't look deeply enough. That hopefully means fixing it for FreeBSD might be feasible for Go 1.26, or maybe 1.26.1.

(I was thinking it was going to need major changes which would definitely be a no-go for 1.26.)

The special case explains why my Go program worked, oops; I was assuming it used INADDR_ANY when Go is cleverer.

Show threadJdeBPFeb 6

@dgl @cks @lyda

In the majority of cases there actually is no separate inet_pton() manual page.

https://man.freebsd.org/cgi/man.cgi?query=inet_pton&sektion=3

https://man.netbsd.org/inet_pton.3

http://tribblix.org/man/man3c/inet_pton.html

https://man.omnios.org/man3c/inet.3c

http://uw714doc.xinuos.com/en/man/html.3N/inet.3N.html

Although most of those call out inet_pton(), SCO #UnixWare in fact documented the four human-readable IPv4 formats for inet_pton(), and did not even have an inet_aton().

In #NetBSD, the internal inet_pton4() function was indeed updated by Christos Zoulas from the old Paul Vixie code to support the four human-readable formats of inet_aton(), 22 years ago; although it's not clear where this additional IPv4 conversion functionality is actually used.

The old Paul Vixie code from 1996 is retained in GNU libc, #FreeBSD, & #OpenBSD; this being code from the BIND DNS client library.

It was superseded by a from-scratch reimplementation based around a str2inet_addr() function in #Solaris/ #Illumos/ #Tribblix/ #OmniOS. musl libc also has its own from-scratch version.

@ska

inet_pton(3)

Show threadmirabilosFeb 6

@cks as it should.

ssh: Could not resolve hostname 0: no address associated with name
Show threadRobert Pluim 🇪🇺Feb 4
@cks INADDR_ANY as a *destination* address? The socket API never fails to surprise 😃
Show threadChris SiebenmannFeb 4
@rpluim Yeah this was my surprised face too. Apparently it's traditional behavior to make it the same as connecting to localhost, but said traditional behavior has apparently caused security issues because higher-level APIs often treat a blank host as INADDR_ANY (either explicitly or just implicitly because it's 0, so a zero-initialized host address that's never set is INADDR_ANY).