Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MsQuic interoperability with cronet #4162

Open
2 of 4 tasks
arunb2001 opened this issue Feb 28, 2024 · 1 comment
Open
2 of 4 tasks

MsQuic interoperability with cronet #4162

arunb2001 opened this issue Feb 28, 2024 · 1 comment
Labels
Area: Testing Related to test coverage external Proposed by non-MSFT question Further information is requested
Milestone

Comments

@arunb2001
Copy link

Describe the bug

Hi @nibanks . I'm facing issues with MsQuic interop server. On the client side I have Cronet quic. Certificate verification is disabled on the client side. The client wants to GET a webpage index.html (1619 bytes) from the server. I am not configuring POST request on the server.

I normally run the 'quicinteropserver' executable on the server side and 'quic_client' on the client side with required command-line arguments. The connection between the server and the client gets established. Cronet client opens 2 different streams with the MsQuic server: one unidirectional stream and one bidirectional stream. MsQuic will have a separate callback handler for each stream. When data is received on the unidirectional stream, MsQuic indicates a QUIC_STREAM_EVENT_RECEIVE event. Here it checks whether the server is configured for POST and if it isn't, then Abort() function is called and MsQuic->StreamShutdown() API is called with QUIC_STREAM_SHUTDOWN_FLAG_ABORT flag and 'HttpRequestExtraRecv' error code. Due to this STOP_SENDING frame is sent to the client and the client closes the connection without reading the received stream data. Below is a snippet of the log highlighting the issue. I have added some logs of my own to debug the issue.

[strm][0xb400007b795d0510] Indicating QUIC_STREAM_EVENT_RECEIVE [41 bytes, 1 buffers, 0x0 flags] [StreamAppReceive:/home/a.bhagavath/msquic/msquic/src/core/stream_recv.c:963]
Arun QuicUnidiCallbackHandler
[strm][0xb400007b795d0510] Data received length = 41 Data:
[ api] Enter 1 (0xb400007b795d0510). [ApiEnter:/home/a.bhagavath/msquic/msquic/src/core/api.c:1517]
[ api] Exit 0 [ApiExitStatus:/home/a.bhagavath/msquic/msquic/src/core/api.c:1602]
[192.168.69.15:39450] Server not configured for POST!
Arun HttpRequest:Abort ErrorCode:7
[strm] Arun MsQuicStreamShutdown ErrorCode:7 Flags:6 [StreamWriteFrames:/home/a.bhagavath/msquic/msquic/src/core/api.c:882]
[ api] Enter 21 (0xb400007b795d0510). [ApiEnter:/home/a.bhagavath/msquic/msquic/src/core/api.c:893]
[ api] Exit 4294967294 [ApiExitStatus:/home/a.bhagavath/msquic/msquic/src/core/api.c:991]
[strm][0xb400007b795d0510] Receive complete [41 bytes] [StreamAppReceiveComplete:/home/a.bhagavath/msquic/msquic/src/core/stream_recv.c:1077]

Another issue is that though we can see that 41 bytes of data has been received, when I try to print the buffer using '%s' format specifier I am not able to see anything.

Is there any way to fix this? Is there a way I can test interoperability between MsQuic and cronet quic?

msquic-cronet_server_logs[1].txt
msquic-cronet_client_logs[1].txt

Affected OS

  • Windows
  • Linux
  • macOS
  • Other (specify below)

Additional OS information

Android 14

MsQuic version

main

Steps taken to reproduce bug

  1. Run server. $ ./quicinteropserver -listen:* -port:4567 -file:/data/data/msquic/arunquic.com.crt -key:/data/data/msquic/device.key -root:/data/data/msquic/files
  2. Run client. $ ./quic_client --host=192.168.69.39 --port=4567 --disable_certificate_verification --ignore_errors --v=1 https://www.example.org/

Expected behavior

Server should not abortively shut down the stream. It should send the required files to the client and then close the stream.

Actual outcome

Server abortively shut down the stream

Additional details

No response

@nibanks
Copy link
Member

nibanks commented Feb 28, 2024

Is cronet trying to do HTTP/3? Our interop server doesn't support that.

@nibanks nibanks added question Further information is requested Area: Testing Related to test coverage external Proposed by non-MSFT labels Feb 28, 2024
@nibanks nibanks added this to the Future milestone Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Testing Related to test coverage external Proposed by non-MSFT question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants