In both the C# and TS implementations, the ChannelSignalMessage explicitly sets wantReply to false before sending:
However, this change is done while the message is being written to binary, after the SshChannel checks the value:
|
if (!request.wantReply) { |
This means that if you set wantReply on the message, the SshChannel will wait for a response which will never come, because it wasn't actually asked for.
This is easy to reproduce:
const signalMessage = new ChannelSignalMessage();
signalMessage.signal = 'INT';
signalMessage.wantReply = true;
// get a channel...
const res = await channel.request(signalMessage); // Deadlock!
There's no comment on the line that overrides the wantReply value so I'm not sure the purpose of it - reading the OpenSSH source it seems like wantReply is valid for a signal message and would be handled.
If this is intentional, it would probably just be best to remove the wantReply property from the ChannelSignalMessage. Otherwise, it would be good to remove the override.
In both the C# and TS implementations, the
ChannelSignalMessageexplicitly setswantReplytofalsebefore sending:dev-tunnels-ssh/src/ts/ssh/messages/connectionMessages.ts
Line 403 in 1cd94f9
However, this change is done while the message is being written to binary, after the
SshChannelchecks the value:dev-tunnels-ssh/src/ts/ssh/sshChannel.ts
Line 201 in 1cd94f9
This means that if you set
wantReplyon the message, theSshChannelwill wait for a response which will never come, because it wasn't actually asked for.This is easy to reproduce:
There's no comment on the line that overrides the
wantReplyvalue so I'm not sure the purpose of it - reading the OpenSSH source it seems likewantReplyis valid for asignalmessage and would be handled.If this is intentional, it would probably just be best to remove the
wantReplyproperty from theChannelSignalMessage. Otherwise, it would be good to remove the override.