Handshake timeout when bound to 0.0.0.0 rather than specific interface(s) about quic-go HOT 11 CLOSED

Scratch that, after trying the patch I was listening on 433 rather than 443... No wonder I still couldn't connect. It does solve the issue, so if you prefer me drafting a PR rather than just committing it yourself, I'll give it a shot later today.

from quic-go.

I wasn't able to reproduce #4105. Can you help me debug this issue?

What are the packets that are received by quic-go? What do you think where things go wrong? 3b5950a looks completely harmless to me, as it's only changing the way the IP is encoded internally, but maybe I'm missing something?

from quic-go.

This is the first time I'm touching Go, so I asked ChatGP for a basic UDP server, and went from there. Apologies if it's bad in any way. My goal was to investigate any differences in how netip treats IPv4 addresses on a dual stack socket vs. how net does that.

Consider the following code:

func main() {
    pc, err := net.ListenPacket("udp", ":8080")
    if err != nil {
        log.Fatalf("Failed to listen on UDP port 8080: %v", err)
    }
    defer pc.Close()

    log.Println("UDP server listening on port 8080")

    for {
        buf := make([]byte, 1024)

        n, addr, err := pc.ReadFrom(buf)
        if err != nil {
            log.Printf("Error reading from UDP: %v", err)
            continue
        }

        log.Printf("Source before conversion: %s", addr)

        addrIP, ok := netip.AddrFromSlice(addr.(*net.UDPAddr).IP)
        if !ok {
            log.Printf("Error converting net.Addr to netip.Addr")
            continue
        }

        log.Printf("Source after conversion: %s", addrIP)
    }
}

On FreeBSD, it outputs:

Source before conversion: 192.168.0.2:51207
Source after conversion: ::ffff:192.168.0.2

This changes when binding to an actual IPv4 address, i.e. net.ListenPacket("udp", "192.168.0.1:8080"), in which case the relevant part is the same, and the issue doesn't occur:

Source before conversion: 192.168.0.2:60374
Source after conversion: 192.168.0.2

Combined with the comment on the other issue that (paraphrasing) FreeBSD doesn't allow sending IPv4 packets using 4-in-6 notation, or at least not in every situation, my best guess would be that this is what's happening. ::ffff:192.168.0.2 cannot be used as a destination, but first needs to be converted to 192.168.0.2 (using Unmap(), safe to call always...?).

Note that 0.0.0.0, usually meaning just any IPv4 address, is interpreted as [::] and therefore results in a dual stack socket too.

from quic-go.

Thank you @thijsvandien!

We don't use AddrFromSlice though: 3b5950a#diff-18d15af7517a1da90325d39231f5dba3c53c9be1a3770e256cddddb4d90a670f. We use netip.AddrFrom4 and netip.AddrFrom16, respectively, depending on the kind of cmsg we get from the kernel.

I'm wondering if AsSlice does something unexpected in 3b5950a#diff-7079110d65c69886586d1a21acb3426d8a668b443cd745f5199fe62b5ede9c0f, but looking at the implementation of that function in the standard library, it seems to distinguish between IPv4 and IPv6 as well.

from quic-go.

I'm not familiar enough with this code to come up with a more realistic demo, but if you have any further tests you'd like me to run, I'd be happy to. Also I already set up a FreeBSD server that I could give you access to, should you need one to investigate it yourself.

This may be important: ::ffff:192.168.0.2 returns true for Is6() and Is4In6(), but false for Is4().

from quic-go.

I assume you're running Caddy, right? Unfortunately, Caddy isn't currently set up to support qlogs.

What you could try though is running it with QUIC_GO_LOG_LEVEL=debug. Do you find anything interesting in the log output when you hit your endpoint with curl or a browser?

from quic-go.

Since it has basically been established that the issue is with this library rather than Caddy, I've been testing with the example server and now just a minimal piece of Go as listed above. The former I could try with that variable set. Also please note my last comment after editing.

from quic-go.

If you're using the example server, you can enable qlogging by setting the QLOGDIR environment variable (set it to the directory you want to export the qlogs to).

This may be important: ::ffff:192.168.0.2 returns true for Is6() and Is4In6(), but false for Is4().

Interesting. This could be relevant due to

from quic-go.

That is also exactly the part that was suggested in the other issue to change: #4105 (comment).

from quic-go.

Does the patch resolve your issue? If so, would you mind sending a PR?

from quic-go.

Weirdly enough, it doesn't seem to change anything in relation to this issue. Also, the QLOGDIR remains empty. Neither does the console show much interesting.

from quic-go.