ietf quic(h3-29) will handshake failed when sent in first 0RTT

281 views
Skip to first unread message

刘宏强

unread,
Apr 23, 2021, 9:31:33 AM4/23/21
to QUIC Prototype Protocol Discussion group
hello,  we use command-line to start canary with quic(h3-29)  which version is 92.0.4485.0,   but the first 0RTT handshake will failed：
.\chrome.exe --enable-quic --quic-version=h3-29 --log-net-log="C:\Users\cm.json" www.abc.com.  the first 0RTT will be failed.
  so my questions:
1. canary can send the 0RTT data after received the server handshake, is the behaviour right?
2. why canary  did not ack the handshake msg to server?
shangchuan.png

Ryan Hamilton

unread,
Apr 23, 2021, 10:09:27 AM4/23/21
to QUIC Prototype Protocol Discussion group
What is candy? Do you have a net-internals log?

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/c7ea479a-c80a-4a7b-99bd-1d8a112c50a3n%40chromium.org.

刘宏强

unread,
Apr 24, 2021, 5:32:39 PM4/24/21
to QUIC Prototype Protocol Discussion group, r...@chromium.org
Sorry, the client is Chrome Canary.  I have attached the net-internals log. You can check the quic session which event id is 654. 
canary(1).json

Fan Yang

unread,
Apr 26, 2021, 8:01:18 AM4/26/21
to proto...@chromium.org, r...@chromium.org
Thanks for the net-log.
From the net-log, the client does not derive the HANDSHAKE key after receiving the INITIAL packet 1 (SHLO), so the HANDSHAKE packet (and 1-RTT packet) cannot be processed and gets buffered. This is why the client sends 0-RTT data afterwards (as well as the client cannot ACK the handshake packets).
Question please: is it easy to reproduce this issue? It would be great to understand why clients do not derive the HANDSHAKE key after receiving SHLO.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/1284f6bf-31a8-41d6-81cb-b5fde225c8a6n%40chromium.org.

刘宏强

unread,
Apr 26, 2021, 11:01:16 AM4/26/21
to QUIC Prototype Protocol Discussion group, fay...@chromium.org, r...@chromium.org
It‘s easy to reproduce the issue in my pc . How can I debug the reason why clients do not derive the HANDSHAKE key after receiving SHLO.

Fan Yang

unread,
Apr 26, 2021, 11:09:20 AM4/26/21
to 刘宏强, QUIC Prototype Protocol Discussion group, r...@chromium.org
Oh, exciting! Do you have any experience of compiling and building chromium (https://www.chromium.org/developers/how-tos/get-the-code)?

刘宏强

unread,
Apr 26, 2021, 11:27:25 AM4/26/21
to QUIC Prototype Protocol Discussion group, fay...@chromium.org, QUIC Prototype Protocol Discussion group, r...@chromium.org, 刘宏强
You mean to build a canary client,  right? But I think it is not good way,  because another pc's canary did not reproduce the issue. From the netlog,  can you judge it's client issue or server issue?  BTW, our server is built  on the chromium which  version is  
87.0.4280.141.

Fan Yang

unread,
Apr 26, 2021, 3:03:05 PM4/26/21
to 刘宏强, QUIC Prototype Protocol Discussion group, r...@chromium.org
Got it. This looks like a client issue, and we are actively investigating it. Thanks again for the net-log!

刘宏强

unread,
Apr 27, 2021, 10:04:50 AM4/27/21
to QUIC Prototype Protocol Discussion group, fay...@chromium.org, QUIC Prototype Protocol Discussion group, r...@chromium.org, 刘宏强
Wlc, I have dump the pcap and ssl_log.log. Please help investigate it together.
sslkeyfile_error.log
pxw.pcap

David Schinazi

unread,
May 4, 2021, 2:09:05 PM5/4/21
to 刘宏强, QUIC Prototype Protocol Discussion group
Hello,

The fix for this issue should now be in Chrome Canary 92.0.4497.0.
Could you please check that it resolves the issues you were experiencing?

Thanks,
David

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/84f8fab9-2148-444e-8868-a7f4e1c90e6fn%40chromium.org.

刘宏强

unread,
May 4, 2021, 6:45:40 PM5/4/21
to QUIC Prototype Protocol Discussion group, dschina...@gmail.com, QUIC Prototype Protocol Discussion group, 刘宏强
Thanks very much,  would you pls tell me what's wrong with Chrome Canary?

David Schinazi

unread,
May 4, 2021, 6:50:59 PM5/4/21
to 刘宏强, QUIC Prototype Protocol Discussion group
The issue was a deadlock inside the QUIC code, the fix is here:

Can you tell us if the problem is fixed in Canary 92.0.4497.0 please?

Thank you!
David
Reply all
Reply to author
Forward
0 new messages