search

quinn-rs / quinn

Async-friendly QUIC implementation in Rust
Apache License 2.0
3.76k stars 380 forks source link

MSQUIC Client talking with QUINN Endpoint #1486

Closed cuyler closed 1 year ago

cuyler commented 1 year ago

Hi all! Randomish question but has anyone had any success getting an msquic client to handshake with a quinn endpoint? From what we can tell, it appears that msquic is setting an ALPN by default which Quinn is rejecting as unverifiable/unknown during the handshake process and rejecting with "error 120: peer doesn't support any known protocol".

Since QUIC is a standard, it seems like it should work but we're a bit perplexed. Thoughts?

djc commented 1 year ago

What ALPN protocols are you configuring on the client, and on the server? You'll need to have overlap between both.

cuyler commented 1 year ago

It's a good question; It appears that it's just a string settable to 'whatever' on the msquic side. Weirdly, it's required, even though it's optional in the QUIC spec, from what I can tell... It would be pretty funny to me if all of this cryptography was failing to handshake on a string compare. 😄

seblaf1 commented 1 year ago

Client is set to h3, but it seems that the server rejects h3 as well. Is Quinn not using HTTP/3 "h3" by default ?

djc commented 1 year ago

For H3 functionality you have to rely on the h3 crate, we currently don't offer it as part of Quinn.

Ralith commented 1 year ago

You can of course easily configure a Quinn server to offer whatever ALPN IDs you like (see rustls::ServerConfig::alpn_protocols), but QUIC is only one part of a complete HTTP/3 implementation. Did you intend to use HTTP/3 or QUIC?

Ralith commented 1 year ago

Presuming solved.