On Sat, 22 Jun 2024 12:53:52 +0100, Stuart Henderson <s...@spacehopper.org> wrote: > > > www/py-aioquic has an issue, IPV6_V6ONLY is neutered on OpenBSD so > > it is broken, so I'm not entirely happy importing it as-is (although > > mitmproxy itself does work as long as you don't use the quic support). > > I tried the attached patch as a dumb attempt. With that, I picked a > v4-only example from https://bagder.github.io/HTTP3-test/ which works > correctly with curl --http3 and tried this: > > $ cd `make show=WRKSRC` > $ python3 examples/http3_client.py -v https://pgjones.dev/ > > which looks successful: > > 2024-06-22 12:47:13,379 DEBUG asyncio Using selector: KqueueSelector > 2024-06-22 12:47:13,520 DEBUG quic [5af065b80f12c352] TLS > State.CLIENT_HANDSHAKE_START -> State.CLIENT_EXPECT_SERVER_HELLO > 2024-06-22 12:47:13,548 DEBUG quic [5af065b80f12c352] > QuicConnectionState.FIRSTFLIGHT -> QuicConnectionState.CONNECTED > 2024-06-22 12:47:13,550 DEBUG quic [5af065b80f12c352] TLS > State.CLIENT_EXPECT_SERVER_HELLO -> State.CLIENT_EXPECT_ENCRYPTED_EXTENSIONS > 2024-06-22 12:47:13,550 DEBUG quic [5af065b80f12c352] TLS > State.CLIENT_EXPECT_ENCRYPTED_EXTENSIONS -> > State.CLIENT_EXPECT_CERTIFICATE_REQUEST_OR_CERTIFICATE > 2024-06-22 12:47:13,550 DEBUG quic [5af065b80f12c352] Discarding epoch > Epoch.INITIAL > 2024-06-22 12:47:13,551 DEBUG quic [5af065b80f12c352] TLS > State.CLIENT_EXPECT_CERTIFICATE_REQUEST_OR_CERTIFICATE -> > State.CLIENT_EXPECT_CERTIFICATE_VERIFY > 2024-06-22 12:47:13,564 DEBUG quic [5af065b80f12c352] TLS > State.CLIENT_EXPECT_CERTIFICATE_VERIFY -> State.CLIENT_EXPECT_FINISHED > 2024-06-22 12:47:13,564 DEBUG quic [5af065b80f12c352] TLS > State.CLIENT_EXPECT_FINISHED -> State.CLIENT_POST_HANDSHAKE > 2024-06-22 12:47:13,564 INFO quic [5af065b80f12c352] ALPN negotiated protocol > h3 > 2024-06-22 12:47:13,565 DEBUG quic [5af065b80f12c352] Stream 3 created by peer > 2024-06-22 12:47:13,565 DEBUG quic [5af065b80f12c352] Stream 7 created by peer > 2024-06-22 12:47:13,565 DEBUG quic [5af065b80f12c352] Stream 11 created by > peer > 2024-06-22 12:47:13,588 DEBUG quic [5af065b80f12c352] Discarding epoch > Epoch.HANDSHAKE > 2024-06-22 12:47:13,659 DEBUG quic [5af065b80f12c352] Stream 0 discarded > 2024-06-22 12:47:13,659 INFO client Response received for GET / : 22268 bytes > in 0.1 s (1.901 Mbps) > 2024-06-22 12:47:13,659 INFO quic [5af065b80f12c352] Connection close sent > (code 0x100, reason ) > 2024-06-22 12:47:13,660 DEBUG quic [5af065b80f12c352] > QuicConnectionState.CONNECTED -> QuicConnectionState.CLOSING > 2024-06-22 12:47:13,922 DEBUG quic [5af065b80f12c352] Discarding epoch > Epoch.ONE_RTT > 2024-06-22 12:47:13,922 DEBUG quic [5af065b80f12c352] > QuicConnectionState.CLOSING -> QuicConnectionState.TERMINATED > > which looks fairly successful. > > If I pick an example which has a v6 address (again testing that it works > with curl --http3 and does use quic), it's not so good though: > > $ python3 examples/http3_client.py -v https://nghttp2.org/ > 2024-06-22 12:51:37,231 DEBUG asyncio Using selector: KqueueSelector > 2024-06-22 12:51:37,387 DEBUG quic [6a973bf9427e3818] TLS > State.CLIENT_HANDSHAKE_START -> State.CLIENT_EXPECT_SERVER_HELLO > 2024-06-22 12:51:37,592 DEBUG quic [6a973bf9427e3818] Loss detection triggered > 2024-06-22 12:51:37,592 DEBUG quic [6a973bf9427e3818] Scheduled CRYPTO data > for retransmission > 2024-06-22 12:51:38,002 DEBUG quic [6a973bf9427e3818] Loss detection triggered > 2024-06-22 12:51:38,002 DEBUG quic [6a973bf9427e3818] Scheduled CRYPTO data > for retransmission > 2024-06-22 12:51:38,812 DEBUG quic [6a973bf9427e3818] Loss detection triggered > 2024-06-22 12:51:38,812 DEBUG quic [6a973bf9427e3818] Scheduled CRYPTO data > for retransmission > ^C2024-06-22 12:51:40,422 INFO quic [6a973bf9427e3818] Connection close sent > (code 0x0, reason ) > 2024-06-22 12:51:40,422 DEBUG quic [6a973bf9427e3818] > QuicConnectionState.FIRSTFLIGHT -> QuicConnectionState.CLOSING > 2024-06-22 12:51:41,032 DEBUG quic [6a973bf9427e3818] Discarding epoch > Epoch.INITIAL > 2024-06-22 12:51:41,032 DEBUG quic [6a973bf9427e3818] Discarding epoch > Epoch.HANDSHAKE > 2024-06-22 12:51:41,032 DEBUG quic [6a973bf9427e3818] Discarding epoch > Epoch.ONE_RTT > 2024-06-22 12:51:41,032 DEBUG quic [6a973bf9427e3818] > QuicConnectionState.CLOSING -> QuicConnectionState.TERMINATED > 2024-06-22 12:51:41,033 ERROR asyncio Future exception was never retrieved > future: <Future finished exception=ConnectionError()> >
Ooops, seems that we had working on this IPv6 issue in parallel. My approach is different with attempt to avoid dual stack, which based on use AI_ADDRCONFIG to determine which stack should be used. What should fix both cases I guess. Just a side note: do you know any other OS which doesn't support dual-stack? -- wbr, Kirill
