How do SSH tunnels handle TCP RSTs on either side?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
Say I have an SSH tunnel from my local machine to a database on a remote server.
If I send a query into the tunnel, it comes out on the other side, but halfway through sending the query or receiving the result the Database triggers a TCP RST, how does SSH handle that?
Does it:
- Wait to ACK packets on either side until it has received an ACK from the endpoints?
- Buffer application level data and resend until successful?
- Other?
My worry is that if the tunnel ACKs before the other side ACKs, and the other side instead sends a RST then there is no way to propagate that RST back. Both sides will just hang.
ssh ssh-tunneling
asked Mar 7 at 15:00
Breedly
1083
add a comment |Â
up vote
1
down vote
favorite
Say I have an SSH tunnel from my local machine to a database on a remote server.
If I send a query into the tunnel, it comes out on the other side, but halfway through sending the query or receiving the result the Database triggers a TCP RST, how does SSH handle that?
Does it:
- Wait to ACK packets on either side until it has received an ACK from the endpoints?
- Buffer application level data and resend until successful?
- Other?
My worry is that if the tunnel ACKs before the other side ACKs, and the other side instead sends a RST then there is no way to propagate that RST back. Both sides will just hang.
ssh ssh-tunneling
asked Mar 7 at 15:00
Breedly
1083
ACKs are handled by the TCP layer, not the application.
– Barmar
Mar 7 at 21:02
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
Say I have an SSH tunnel from my local machine to a database on a remote server.
If I send a query into the tunnel, it comes out on the other side, but halfway through sending the query or receiving the result the Database triggers a TCP RST, how does SSH handle that?
Does it:
- Wait to ACK packets on either side until it has received an ACK from the endpoints?
- Buffer application level data and resend until successful?
- Other?
My worry is that if the tunnel ACKs before the other side ACKs, and the other side instead sends a RST then there is no way to propagate that RST back. Both sides will just hang.
ssh ssh-tunneling
asked Mar 7 at 15:00
Breedly
1083
Say I have an SSH tunnel from my local machine to a database on a remote server.
If I send a query into the tunnel, it comes out on the other side, but halfway through sending the query or receiving the result the Database triggers a TCP RST, how does SSH handle that?
Does it:
- Wait to ACK packets on either side until it has received an ACK from the endpoints?
- Buffer application level data and resend until successful?
- Other?
My worry is that if the tunnel ACKs before the other side ACKs, and the other side instead sends a RST then there is no way to propagate that RST back. Both sides will just hang.
ssh ssh-tunneling
asked Mar 7 at 15:00
Breedly
1083
asked Mar 7 at 15:00
Breedly
1083
asked Mar 7 at 15:00
Breedly
1083
asked Mar 7 at 15:00
Breedly
1083
1083
ACKs are handled by the TCP layer, not the application.
– Barmar
Mar 7 at 21:02
add a comment |Â
ACKs are handled by the TCP layer, not the application.
– Barmar
Mar 7 at 21:02
ACKs are handled by the TCP layer, not the application.
– Barmar
Mar 7 at 21:02
ACKs are handled by the TCP layer, not the application.
– Barmar
Mar 7 at 21:02
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
How will "both sides will just hang"? Do you actually observe that?
Quoting from "TCP/IP Illustrated, Volume 1, 2nd edition" p. 628:
The reset segment contains a sequence number and acknowledgement number. Also notice that the reset segment elicits no response from the other end—it is not acknowledged at all. The receiver of the reset aborts the connection and advises the application that the connection was reset. This often results in the error indication "Connection reset by peer" or a similar message.
And on the previous page:
Aborting a connecting provides two features...any queued data is thrown away and a reset segment is sent immediately...the receiver of the reset can tell that the other end did an abort instead of a normal close.
(You may also want to review the socket option SO_LINGER that may be used by the listening socket of your application.)
answered Mar 7 at 18:35
thrig
22.2k12852
Not so much a TCP question, but a "how does the tunnel handle TCP". Does it ACK all packets coming in before replaying them on the other side? Does it pass the TCP sequence through transparently and replay both sides? Am I guaranteed to have the same sequence numbers on either side of the tunnel?
– Breedly
Mar 7 at 20:55
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
How will "both sides will just hang"? Do you actually observe that?
Quoting from "TCP/IP Illustrated, Volume 1, 2nd edition" p. 628:
The reset segment contains a sequence number and acknowledgement number. Also notice that the reset segment elicits no response from the other end—it is not acknowledged at all. The receiver of the reset aborts the connection and advises the application that the connection was reset. This often results in the error indication "Connection reset by peer" or a similar message.
And on the previous page:
Aborting a connecting provides two features...any queued data is thrown away and a reset segment is sent immediately...the receiver of the reset can tell that the other end did an abort instead of a normal close.
(You may also want to review the socket option SO_LINGER that may be used by the listening socket of your application.)
answered Mar 7 at 18:35
thrig
22.2k12852
Not so much a TCP question, but a "how does the tunnel handle TCP". Does it ACK all packets coming in before replaying them on the other side? Does it pass the TCP sequence through transparently and replay both sides? Am I guaranteed to have the same sequence numbers on either side of the tunnel?
– Breedly
Mar 7 at 20:55
add a comment |Â
up vote
0
down vote
How will "both sides will just hang"? Do you actually observe that?
Quoting from "TCP/IP Illustrated, Volume 1, 2nd edition" p. 628:
The reset segment contains a sequence number and acknowledgement number. Also notice that the reset segment elicits no response from the other end—it is not acknowledged at all. The receiver of the reset aborts the connection and advises the application that the connection was reset. This often results in the error indication "Connection reset by peer" or a similar message.
And on the previous page:
Aborting a connecting provides two features...any queued data is thrown away and a reset segment is sent immediately...the receiver of the reset can tell that the other end did an abort instead of a normal close.
(You may also want to review the socket option SO_LINGER that may be used by the listening socket of your application.)
answered Mar 7 at 18:35
thrig
22.2k12852
Not so much a TCP question, but a "how does the tunnel handle TCP". Does it ACK all packets coming in before replaying them on the other side? Does it pass the TCP sequence through transparently and replay both sides? Am I guaranteed to have the same sequence numbers on either side of the tunnel?
– Breedly
Mar 7 at 20:55
add a comment |Â
up vote
0
down vote
up vote
0
down vote
How will "both sides will just hang"? Do you actually observe that?
Quoting from "TCP/IP Illustrated, Volume 1, 2nd edition" p. 628:
The reset segment contains a sequence number and acknowledgement number. Also notice that the reset segment elicits no response from the other end—it is not acknowledged at all. The receiver of the reset aborts the connection and advises the application that the connection was reset. This often results in the error indication "Connection reset by peer" or a similar message.
And on the previous page:
Aborting a connecting provides two features...any queued data is thrown away and a reset segment is sent immediately...the receiver of the reset can tell that the other end did an abort instead of a normal close.
(You may also want to review the socket option SO_LINGER that may be used by the listening socket of your application.)
answered Mar 7 at 18:35
thrig
22.2k12852
How will "both sides will just hang"? Do you actually observe that?
Quoting from "TCP/IP Illustrated, Volume 1, 2nd edition" p. 628:
The reset segment contains a sequence number and acknowledgement number. Also notice that the reset segment elicits no response from the other end—it is not acknowledged at all. The receiver of the reset aborts the connection and advises the application that the connection was reset. This often results in the error indication "Connection reset by peer" or a similar message.
And on the previous page:
Aborting a connecting provides two features...any queued data is thrown away and a reset segment is sent immediately...the receiver of the reset can tell that the other end did an abort instead of a normal close.
(You may also want to review the socket option SO_LINGER that may be used by the listening socket of your application.)
answered Mar 7 at 18:35
thrig
22.2k12852
answered Mar 7 at 18:35
thrig
22.2k12852
answered Mar 7 at 18:35
thrig
22.2k12852
answered Mar 7 at 18:35
thrig
22.2k12852
22.2k12852
Not so much a TCP question, but a "how does the tunnel handle TCP". Does it ACK all packets coming in before replaying them on the other side? Does it pass the TCP sequence through transparently and replay both sides? Am I guaranteed to have the same sequence numbers on either side of the tunnel?
– Breedly
Mar 7 at 20:55
add a comment |Â
Not so much a TCP question, but a "how does the tunnel handle TCP". Does it ACK all packets coming in before replaying them on the other side? Does it pass the TCP sequence through transparently and replay both sides? Am I guaranteed to have the same sequence numbers on either side of the tunnel?
– Breedly
Mar 7 at 20:55
Not so much a TCP question, but a "how does the tunnel handle TCP". Does it ACK all packets coming in before replaying them on the other side? Does it pass the TCP sequence through transparently and replay both sides? Am I guaranteed to have the same sequence numbers on either side of the tunnel?
– Breedly
Mar 7 at 20:55
Not so much a TCP question, but a "how does the tunnel handle TCP". Does it ACK all packets coming in before replaying them on the other side? Does it pass the TCP sequence through transparently and replay both sides? Am I guaranteed to have the same sequence numbers on either side of the tunnel?
– Breedly
Mar 7 at 20:55
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f428767%2fhow-do-ssh-tunnels-handle-tcp-rsts-on-either-side%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
ACKs are handled by the TCP layer, not the application.
– Barmar
Mar 7 at 21:02