-
Notifications
You must be signed in to change notification settings - Fork 7k
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
Websocket server cannot handle big messages (IDFGH-5463) #7202
Comments
@Osetinski Thanks for producing detailed steps to reproduce the issue. We will take into a look and reply you ASAP. |
@Osetinski What IDF version you uesd. I use tag v4.3 version with your code and script. It's ok for me. Could you please check your IDF version and update to v4.3 to test. |
@ESP-YJM Thanks for the quick response. I am sure I'm using v4.3. I get the following result for git describe command in my esp idf directory:
Additionally the Bootloader logs the following during startup:
Doesn't the communication abort for you at all? I always get at least unclear messages (like the third one in my log above) in the ESP log and some kind of "connection closed abnormally" error during execution of the Python script. |
@Osetinski What about your python version? ESP32 ws_echo_server can successfully receive 50 counts data with length 1433 in my environment. |
@ESP-YJM Okay, that's confusing. Could you try more Bytes? Maybe up to 1600? You might need to update the LONG_DATA variable in my script so it contains more characters. |
Ok, i will test it with larger bytes. And will response you my result ASAP. |
@ESP-YJM I tried to capture the packets with Wireshark, though I was not exactly sure how to properly export it. Please find the exported file here. 192.168.30.176 is the IP of the ESP, while 192.168.30.147 is the IP of my PC. I guess the most interesting frames are 280 and 297. Frame 280 shows that the whole packet is transmitted correctly over the network to the ESP. Frame 297 is the echo from ESP back to PC and seems to have some kind mixed up data. This is how frame 280 looks like in Wireshark: Then frame 297 looks like this: The payload of frame 297 is the one, where some wrong data is echo'd back, just as it was output in the log console. Console log looks like this: Payload of frame 280 is correct at the end: Frame 299 closes the connection, which is initiated from PC, because the Python script throws an exception at this point. Concrete error: |
@Osetinski Could you please share your whole wireshark capture file instead of txt file. I think it maybe caused by PING & PONG packet. But i didn't capture any PING & PONG packet in my environment. |
@Osetinski Thanks for your capture file. It seems our ESP device reply PONG packet to your PC and the Python script can not handle it properly, maybe need add logic to handle PONG type data. Besides, i don't know where and which packet that client send PING packet in capture file. Maybe need change LOG level from |
@ESP-YJM On second thought I think the PONG-Opcode might be misleading and more of a coincidence. Sometimes I saw other opcodes too, which aren't even specified e.g. opcode=5. I guess it is just some kind of random data written to the stream and being misinterpreted in this case as a PONG-packet with opcode 10. As you suggested I ran it with LOG level set to debug. Please find the log file here. I also swapped the line sending the websocket packets in the Python script with this: await websocket.send(str(count).zfill(3) + data) This way you can keep track of the message from ESP Log. From the log file I can read on the last received data, that 1453 should be read, but only 1432 could be received correctly. Still the handler gets the length 1453, which explains the random symbols at the end of the logged message. Hope it helps. |
@Osetinski Could you please modify code like this and re-try
|
@ESP-YJM I modified the code as you said, this is what I get:
|
@Osetinski Did you change code here
|
@ESP-YJM Yes I did |
@Osetinski Please revert the previous changes and test again according to the following changes.
|
@ESP-YJM Yes, this seems to fix the problem! The log also proofs that now all Bytes are received when reading multiple times as well as when all Bytes are received with one call:
Also tested it in my actual setup, where the problem first appeared, and it works there too. Thank you again for all your time and effort! |
…incorrectly. Closes espressif#7202
Environment
VS Code with Espressif IDF Extension v1.1.0
Problem Description
The Websocket handler in the httpd server has a problem handling larger incoming data. When a client sends this much data a few times, the ESP seems to mix something up and receives wrong packet type, followed by message "httpd_ws_recv_frame: WS frame is not properly masked." during httpd_ws_recv_frame(). Typically this doesn't happen on the first frame and not everytime on the same consecutive one, but it happens guaranteed and consistently within the next 50 incoming messages. Though it is very likely to happen in the next 5.
After testing the limits I'm pretty sure this only happens when receiving messages with length 1433 bytes and up. Did not see it with less bytes yet.
Expected Behavior
The messages should be received correctly each time for a message length >= 1433 Bytes.
Actual Behavior
As the example run further down shows, the first message is received correctly, the second one already has a '0' instead of 'D' at the end which indicates something is messed up. The third time len is 1, type is wrong and the message is not readable. The fourth time an error is detected (WS frame not properly masked) and the connection ends there with the log "httpd_ws_recv_frame: WS frame is not properly masked."
Steps to reproduce
Code to reproduce this issue
I used the example from Websocket Echo Server with the following URI handler:
As a client I used this python script:
Debug Logs
The text was updated successfully, but these errors were encountered: