-
-
Notifications
You must be signed in to change notification settings - Fork 127
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
channel_success and request_success are not ergonomic #380
Comments
There's some discussion about it in #348 |
I wanted to add this comment to the issue instead of the PR since it explains our specific situation and offers a reliable workaround. We ran into this. We setup a very simple client/server and when the client executed these lines:
The Server responds to shell requests thusly:
The proxy we have in between the two would throw an error saying that it had never received a CHANNEL_SUCCESS (99). We discovered that the first message we got after Side note: I wonder if the CHANNEL_OPEN_CONFIRMATION message should be the responsibility of the This is the workaround we came to. Even if it requires more understanding of individual SSH messages (and it's more code), it's a reliable solution. You can also specifically handle other common messages like
|
(Sorry, I submitted this too fast with no comment)
We just got bitten by not using
channel_success
on a channel request for a client that expected a reply (want_reply: true
).I'm wondering why this has to be manually called. Could it be instead inferred from the
Result
of each handler function?The text was updated successfully, but these errors were encountered: