-
Notifications
You must be signed in to change notification settings - Fork 88
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
If the client is suspended, the server enters a busy loop with WS_WINDOW_FULL #607
Comments
How did you configure wolfSSH and which version are you using? I'm not getting the window full status. I'm on macOS; I consider it BSD. I'm configuring with:
I'm using the master branch (commit 173dfd9). I'm running the server with I also went back to the v1.4.14 release. I configured with:
I had to use those CFLAGS because the version of OpenSSH I'm using doesn't allow SHA-1 anything, and that version of wolfSSH has a bug with AES-CTR. I used the same |
I did the test on the master branch (commit 74cf1d4), configured with Ran the echoserver with I couldn't reproduce the issue with the v1.4.14 release either, but we were having this very issue in our product that uses v1.4.14 and I thought the trigger might be the different way our worker loop was built, compared to the echoserver's one; the master branch's echoserver has seen the worker loop refactored in a way more similar to the one we're using, and incidentally I could reproduce the very same issue there. The fact you can't reproduce it with master is puzzling, to say the least. Got any ideas? |
I moved my test to my Ubuntu box and ran it in a VM and recreated this. Taking a deeper look. |
Should be fixed now. |
This might address the specific behavior in the echoserver, but is it normal at all for the library to hand to the library's user the duty to deal with a full window? Doesn't it rather mean that there's something to be "fixed" in the library itself? The echoserver for us was just a proxy for an issue we're experiencing outside of the echo server, and it's not clear whether we could employ the same strategy as the echoserver's to deal with it. On this topic, I've added a comment to the PR: #612 (comment) |
If you tell me I can only send you 128kb, and I send you 128kb, there's nothing I can do to send more until you tell me you've consumed any of the data I sent. That's the agreement when setting up the channel. WS_WINDOW_FULL is analogous to WS_WANT_WRITE, but it is for a specific channel and not the socket. |
To reproduce on unix:
The echoserver will start spinning, printing out endless consecutive copies of this log snippet:
The text was updated successfully, but these errors were encountered: