IPv4 connections to quic-go server fail on FreeBSD

[peterjeremy]

quic-go uses dual-stack sockets so incoming IPv4 connections appear as IPv4-mapped IPv6 connections (see RFC2553 §3.7). #3881 changed the behaviour of the OOB data associated with the connection (quic.sconn) in this case (see the change to OOB() in sys_conn_oob.go): Previously, an IPv4-mapped address was treated as IPv4 and would result in a struct in_pktinfo being attached (this doesn't exist on FreeBSD so the OOB data is empty). The current behaviour is that an IPv4-mapped address is treated as IPv6 and results in a struct in6_pktinfo being attached. FreeBSD doesn't support struct in6_pktinfo for IPv4 addresses and the sendmsg call that responds to the incoming connection will return EINVAL.

(Note that FreeBSD recommends that separate IPv4 and IPv6 sockets should be used rather than dual-stack sockets for security reasons - see the Interaction between IPv4/v6 sockets section of inet6(4)).

[peterjeremy]

The attached sys_conn_oob.txt reverts to the previous behaviour, where an IPv4-mapped IPv6 address is treated as an IPv4 address. This corrects the behaviour on FreeBSD and still works on Linux (at least Ubuntu 22.04.3 LTS). I can't check MacOS.

Note that a complete fix to make quic-go v0.39.0 server work on FreeBSD also requires the fix to #4106.

[marten-seemann]

@peterjeremy Can you submit a PR with the fix please?

[marten-seemann]

I can't reproduce this. Connecting to google.com with an IPv4-mapped IPv6 address (go run example/client/main.go https://[::ffff:142.250.103.102]) on a FreeBSD GCP VM was successful.

[marten-seemann]

Closing, since this is not reproducible. Please comment here / reopen the issue with more details on how to reproduce it if you think this is incorrect.

[MirkoGamerman]

Perhaps this information will be useful

1. Change const addr = "localhost:4242" -> const addr = ":4242" in example/echo/echo.go
2. Add const addr_dst = "localhost:4242" (addr_dst for connect from client)
   3.Change conn, err := quic.DialAddr(context.Background(), addr, tlsConf, nil) -> conn, err := quic.DialAddr(context.Background(), addr_dst, tlsConf, nil)
3. Run go run example/echo/echo.go

% go run example/echo/echo.go
panic: timeout: no recent network activity

goroutine 1 [running]:
main.main()
/home/gamer/3/quic/example/echo/echo.go:31 +0x45
exit status 2

netstat -na | grep udp
udp46 0 0 *.4242 .

uname -a
FreeBSD bot 13.1-RELEASE-p6 FreeBSD 13.1-RELEASE-p6 GENERIC amd64

But if you apply attached https://github.com/quic-go/quic-go/files/12787012/sys_conn_oob.txt
Demo work good
go run example/echo/echo.go
Client: Sending 'foobar'
Server: Got 'foobar'
Client: Got 'foobar'

[temtemy]

I can reproduce it in Yggdrasil's Go implementation (version 0.5.2), which uses quic-go 0.39.3: https://github.com/yggdrasil-network/yggdrasil-go/blob/develop/go.mod

I have a FreeBSD 12.3 VPS that only has IPv4, and I got stumped for hours trying to get Yggdrasil to open a UDP/QUIC port. Even at the most verbose level of logging I didn't get any clues on what went wrong; it just told me it opened a listener at [::]:<port>. And netstat doesn't return anything about my UDP port being open. Which does tell me that something really went wrong, just didn't point me where. If I didn't search here I wouldn't have figured out that I was using 0.0.0.0 as my listener IP address which gets translated internally to [::]. I currently have to set the listener IP specifically to my public IPv4 to get QUIC working for Yggdrasil.

[marten-seemann]

@temtemy If you think there's still an issue with the current release, please open a new issue.