Exposing UDP errors during connect.

[kixelated]

I'm debugging a IPv6 vs IPv4 issue.

When I try to send a packet to an IPv6 address, I get an ENETUNREACH error. I want to catch this and switch to IPv4 but quinn-udp shallows every error. Only if the user has logging enabled would they see:

WARN quinn_udp: sendmsg error: Os { code: 101, kind: NetworkUnreachable, message: "Network is unreachable" }, Transmit: { destination: [2606:4700:49::2]:443, src_ip: None, ecn: Some(Ect0), len: 2400, segment_size: Some(1200) }

I understand the idea that many UDP errors are transient, but this one seems fatal. I wish I could have the connection fail immediately so I can try the next address, rather than sit waiting for a timeout.

[djc]

Is this with released Quinn? IIRC we improved this on main recently.

[kixelated]

Is this with released Quinn? IIRC we improved this on main recently.

Claude says it was fixed for the recv path only. I'm trying to dial a connection after DNS returns both v4 and V6.

[djc]

Ah, we should probably do something similar for the send path. Want to send a PR? (Fine to use Claude but please read the AI policy in CONTRIBUTING if you haven't yet done so.)

[Ralith]

I understand the idea that many UDP errors are transient, but this one seems fatal.

FWIW, I think this is actually an especially common transient error: consider a device temporarily losing its network connection, e.g. due to flaky wifi.

[kixelated]

I understand the idea that many UDP errors are transient, but this one seems fatal.

FWIW, I think this is actually an especially common transient error: consider a device temporarily losing its network connection, e.g. due to flaky wifi.

During session establishment I would imagine it's fatal the vast majority of the time, but yeah I can imagine network blips recovering.

[kixelated]

Either way, it generally seems wrong for quinn-udp (as a library) to swallow errors and log them? The application should be surfaced the error, and it can decide if it wants to fail or log.

In this case, Quinn as the application could error on handshakes and log for established connections?

[Ralith]

I agree that quinn-udp should propagate errors, so long as doing so doesn't make it very difficult to ignore them when appropriate. I'm not convinced quinn itself should, since it seems like reliable applications should generally keep retrying until timeout -- although ideally in a way responsive to changing network configuration, which might be out of scope...

[kixelated]

I guess my specific issue is that I'm implementing happy eyeballs. I don't really want to perform two TLS handshakes every time by racing IPv4 and IPv6 simultaniously, so I give IPv6 a 250ms lead. The issue is that if I get an ENETUNREACH, then I'm stuck waiting 250ms before starting IPv4, when ideally I should start immediately.

I'm also dialing WebSocket in parallel... potentially the same issue? Like if QUIC completely fails to send a UDP packet for both IPv4 and IPv6, ideally we start dialing the WebSocket IPv6 connection immediately instead of waiting for 500ms.

Basically, it would be really nice to short-circuit when connection establishment appears impossible. I would personally propagate any errors send sending the first initial packet. Anything after than is potentially transient and gets logged.

[thomaseizinger]

Either way, it generally seems wrong for quinn-udp (as a library) to swallow errors and log them? The application should be surfaced the error, and it can decide if it wants to fail or log.

FWIW, quinn-udp itself offers the try_send API for exactly this usecase.

[Ralith]

The issue is that if I get an ENETUNREACH, then I'm stuck waiting 250ms before starting IPv4, when ideally I should start immediately. [...] I would personally propagate any errors send sending the first initial packet. Anything after than is potentially transient and gets logged.

Makes sense; I'm open to it.