Dump HTTP2 Frame error: connection error: PROTOCOL_ERROR

[admln]

Dump HTTP2 Frame error: connection error: PROTOCOL_ERROR

./ecapture tls --ecaptureq=ws://192.168.137.126:28257

• Device: Pixel 6
• Kernel Info: uname -a
• Linux localhost 5.10.209-android13-4-00008-g28a6e1ad779c-ab11971276 5.10.101 not support #1 SMP PREEMPT Fri Jun 14 01:29:26 UTC 2024 aarch64 Toybox
• eCapture Version: ecapture -v
  eCapture version: androidgki_arm64:v1.5.2:6.8.0-1044-azure

[dosubot]

Hi @admln! I'm Dosu and I’m helping the ecapture team.

The HTTP/2 PROTOCOL_ERROR messages are usually triggered by malformed or incomplete frames, which can happen if the captured TLS data is partial or corrupted during streaming. Recent versions of ecapture suppress these errors for expected cases, but it's unclear if your version includes this fix. The recurring WebSocket errors (readPump: error receiving message, writePump: sender channel closed) often indicate issues with the connection lifecycle or message handling, and can also be triggered if the WebSocket client or any proxy is attempting to use HTTP/2 instead of HTTP/1.1, since ecapture's WebSocket server only supports HTTP/1.1 upgrade handshakes and will drop connections it can't understand, resulting in these errors.

To address this:

• Make sure your WebSocket client is connecting using HTTP/1.1, not HTTP/2.
• Double-check that your WebSocket URL ends with a / and uses a specific IP address (not 0.0.0.0).
• If you continue to see these errors, try updating ecapture to the latest version, as recent fixes reduce spurious HTTP/2 frame error logs.
• For more reliable HTTP/2 capture, consider using pcap mode if possible, since there are known limitations with HTTP/2 stream handling in text mode (such as HPACK decoder sharing) source.

If the issue persists, enabling debug logging or collecting more detailed logs may help pinpoint the root cause.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}