Closed lucamuscat closed 8 months ago
That's really weird. The opcode is 0110
which is 6. websockets doesn't declare an opcode 6.
Are you sure that this frame is sent by the websockets client to the server, rather than the opposite?
Are you able to enable debug logs and share them when the error happens? That would help me a lot.
For a quick workaround, I tried to disable the keepalive ping by setting ping_timeout=None, however, websockets.sync.client.connect does not expose this parameter, unlike its asyncio counterpart. Is it possible to disable keepalive pings for the threading variant of the library?
They aren't implemented yet in the threading variant :-) So it's not that!
Thanks for the speedy reply 😊
I ran the test suite again, and recorded the log file as requested. The following is what was generated (with the GET url and host redacted by myself):
= connection is CONNECTING
> GET ... HTTP/1.1
> Host: ...
> Upgrade: websocket
> Connection: Upgrade
> Sec-WebSocket-Key: TjKDbdIYPkfnFeLXFvkNJQ==
> Sec-WebSocket-Version: 13
> Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
> User-Agent: Python/3.11 websockets/11.0.3
< HTTP/1.1 101 Switching Protocols
< Alt-Svc: h3=":443"; ma=2592000
< Connection: Upgrade
< Sec-Websocket-Accept: +WjrN8tmvMfDxaJVpCvPh/V5SdM=
< Server: Caddy
< Upgrade: websocket
< Date: Tue, 16 Jan 2024 13:27:12 GMT
= connection is OPEN
> BINARY 82 a4 74 79 70 65 a8 4e 61 76 69 67 61 74 65 a4 ... 6f 61 64 2e 68 74 6d 6c [99 bytes]
< CLOSE 1005 (no status code [internal]) [0 bytes]
> CLOSE 1005 (no status code [internal]) [0 bytes]
= connection is CLOSING
< EOF
> EOF
= connection is CLOSED
This time, the websocket server complained that an invalid opcode of 3 was received. The following is another screenshot from wireshark, notice the client sending the invalid message after the server sends a close message:
From the client's perspective, the logs show:
This looks proper.
Your wireshark screenshot must be read bottom-to-top (based on timestamps). It shows:
I'm unconvinced by your claim that this is generated by the websockets library. I understand that you cannot share the full code; perhaps you can share at least how you invoke connect
and how you build all arguments passed to connect
? Also, can you confirm that you you aren't mocking anything on which websockets depends?
I apologize for the delay for getting back to you; I appreciate your patience and the help that you have provided!
I guess it's back to the drawing board for me, however, I think that you are correct about the bug having nothing to do with the websocket client itself.
I will close this issue, and re-open it in case I find anything else that might be of interest to this repo 😊
Hi!
I have recently encountered an issue similar to that of #922, where (possibly?) the automatic keepalive ping causes a websocket message with an invalid opcode to be sent, consequently killing the connection between the client and the connection.
For some context, I am using a different websocket server to that mentioned in #922 , written in a completely different language (tokio tungestenite, rust). I suspect that this error is not due to the websocket server not being able to handle pings with arbitrary data, but a race condition occuring in the websocket client itself.
The following is a screenshot of a wireshark dump, highlighting an erroneous websocket message generated by the websockets library: .
Unfortunately, I do not have an MVP for this bug, as it manifests itself sporadically inside a suite of integration tests. Looking through the ping's code, the fact that
self.send_in_progress
is not checked prior to sending the ping is highly suspicious: https://github.com/python-websockets/websockets/blob/35bc7dd8288445289134c335aae8af859862ccd1/src/websockets/sync/connection.py#L419-L462I encountered this bug in both v11.0.2 and v12 of the library on an Ubuntu 20.04 machine.
For a quick workaround, I tried to disable the keepalive ping by setting
ping_timeout=None
, however, websockets.sync.client.connect does not expose this parameter, unlike its asyncio counterpart. Is it possible to disable keepalive pings for the threading variant of the library?Regards, Luca