packet_write_wait Broken pipe even leaving top running?
This bloody error makes my headache going bigger and bigger everyday. I never met a same situation like this time.
Well, after I authenticated into SSH successfully, doing few stuffs then my SSH connection being dropped suddenly!!?
Here is my error message: packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe
I wished my error message look like this: Write Failed: broken pipe a lot, believe me!
I tried a tons of resolution on the Internet like added ServerAliveInterval, ServerAliveCountMax, ClientAlive....
Someone said: Turn your TCPKeepAlive to no, added ServerAlive bllah blah idiot. I did that also but still same error.
There is no luck for me until this moment.
Any help will be appreciate.
ssh
asked Feb 2 '16 at 4:16
Toan NguyenToan Nguyen
2761412
add a comment |
This bloody error makes my headache going bigger and bigger everyday. I never met a same situation like this time.
Well, after I authenticated into SSH successfully, doing few stuffs then my SSH connection being dropped suddenly!!?
Here is my error message: packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe
I wished my error message look like this: Write Failed: broken pipe a lot, believe me!
I tried a tons of resolution on the Internet like added ServerAliveInterval, ServerAliveCountMax, ClientAlive....
Someone said: Turn your TCPKeepAlive to no, added ServerAlive bllah blah idiot. I did that also but still same error.
There is no luck for me until this moment.
Any help will be appreciate.
ssh
asked Feb 2 '16 at 4:16
Toan NguyenToan Nguyen
2761412
1
If you are in a corporate environment, check with your firewall admins and see if they were updating rules and/or restarting the firewall after some sort of a change when this happens. If it is happening to a personal server of yours, you need to provide more information on what were you doing on the sshd server side, when this happened.Broken pipegenerally means there was a network disconnect for some reason.
– MelBurslan
Feb 2 '16 at 6:20
I just moved and this is happening constantly with my new connection. Cox Cable is my ISP, and I've got a Netgear C6300BD cable modem running on default settings from the install. This used to happen at my old location and I could never resolve it. It lasted for months and eventually stopped happening. I forgot how miserable and unsolvable it was until today.
– T. Brian Jones
Apr 19 '16 at 22:15
I feel your pain. I came here as a last resort before I'm going to slap all my hardware into tiny little pieces. Isn't this supposed to be a fairly simple protocol?
– DerpyNerd
May 30 '17 at 11:11
I had the same error on Virtualized Linux, the problem solved changing the ethernet adapter to bridged
– Abel Barrios
Oct 12 '18 at 14:35
add a comment |
This bloody error makes my headache going bigger and bigger everyday. I never met a same situation like this time.
Well, after I authenticated into SSH successfully, doing few stuffs then my SSH connection being dropped suddenly!!?
Here is my error message: packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe
I wished my error message look like this: Write Failed: broken pipe a lot, believe me!
I tried a tons of resolution on the Internet like added ServerAliveInterval, ServerAliveCountMax, ClientAlive....
Someone said: Turn your TCPKeepAlive to no, added ServerAlive bllah blah idiot. I did that also but still same error.
There is no luck for me until this moment.
Any help will be appreciate.
ssh
asked Feb 2 '16 at 4:16
Toan NguyenToan Nguyen
2761412
This bloody error makes my headache going bigger and bigger everyday. I never met a same situation like this time.
Well, after I authenticated into SSH successfully, doing few stuffs then my SSH connection being dropped suddenly!!?
Here is my error message: packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe
I wished my error message look like this: Write Failed: broken pipe a lot, believe me!
I tried a tons of resolution on the Internet like added ServerAliveInterval, ServerAliveCountMax, ClientAlive....
Someone said: Turn your TCPKeepAlive to no, added ServerAlive bllah blah idiot. I did that also but still same error.
There is no luck for me until this moment.
Any help will be appreciate.
ssh
ssh
asked Feb 2 '16 at 4:16
Toan NguyenToan Nguyen
2761412
asked Feb 2 '16 at 4:16
Toan NguyenToan Nguyen
2761412
asked Feb 2 '16 at 4:16
Toan NguyenToan Nguyen
2761412
asked Feb 2 '16 at 4:16
Toan NguyenToan Nguyen
2761412
asked Feb 2 '16 at 4:16
Toan NguyenToan Nguyen
2761412
2761412
1
If you are in a corporate environment, check with your firewall admins and see if they were updating rules and/or restarting the firewall after some sort of a change when this happens. If it is happening to a personal server of yours, you need to provide more information on what were you doing on the sshd server side, when this happened.Broken pipegenerally means there was a network disconnect for some reason.
– MelBurslan
Feb 2 '16 at 6:20
I just moved and this is happening constantly with my new connection. Cox Cable is my ISP, and I've got a Netgear C6300BD cable modem running on default settings from the install. This used to happen at my old location and I could never resolve it. It lasted for months and eventually stopped happening. I forgot how miserable and unsolvable it was until today.
– T. Brian Jones
Apr 19 '16 at 22:15
I feel your pain. I came here as a last resort before I'm going to slap all my hardware into tiny little pieces. Isn't this supposed to be a fairly simple protocol?
– DerpyNerd
May 30 '17 at 11:11
I had the same error on Virtualized Linux, the problem solved changing the ethernet adapter to bridged
– Abel Barrios
Oct 12 '18 at 14:35
add a comment |
1
If you are in a corporate environment, check with your firewall admins and see if they were updating rules and/or restarting the firewall after some sort of a change when this happens. If it is happening to a personal server of yours, you need to provide more information on what were you doing on the sshd server side, when this happened.Broken pipegenerally means there was a network disconnect for some reason.
– MelBurslan
Feb 2 '16 at 6:20
I just moved and this is happening constantly with my new connection. Cox Cable is my ISP, and I've got a Netgear C6300BD cable modem running on default settings from the install. This used to happen at my old location and I could never resolve it. It lasted for months and eventually stopped happening. I forgot how miserable and unsolvable it was until today.
– T. Brian Jones
Apr 19 '16 at 22:15
I feel your pain. I came here as a last resort before I'm going to slap all my hardware into tiny little pieces. Isn't this supposed to be a fairly simple protocol?
– DerpyNerd
May 30 '17 at 11:11
I had the same error on Virtualized Linux, the problem solved changing the ethernet adapter to bridged
– Abel Barrios
Oct 12 '18 at 14:35
1
1
If you are in a corporate environment, check with your firewall admins and see if they were updating rules and/or restarting the firewall after some sort of a change when this happens. If it is happening to a personal server of yours, you need to provide more information on what were you doing on the sshd server side, when this happened.
Broken pipe generally means there was a network disconnect for some reason.– MelBurslan
Feb 2 '16 at 6:20
If you are in a corporate environment, check with your firewall admins and see if they were updating rules and/or restarting the firewall after some sort of a change when this happens. If it is happening to a personal server of yours, you need to provide more information on what were you doing on the sshd server side, when this happened.
Broken pipe generally means there was a network disconnect for some reason.– MelBurslan
Feb 2 '16 at 6:20
I just moved and this is happening constantly with my new connection. Cox Cable is my ISP, and I've got a Netgear C6300BD cable modem running on default settings from the install. This used to happen at my old location and I could never resolve it. It lasted for months and eventually stopped happening. I forgot how miserable and unsolvable it was until today.
– T. Brian Jones
Apr 19 '16 at 22:15
I just moved and this is happening constantly with my new connection. Cox Cable is my ISP, and I've got a Netgear C6300BD cable modem running on default settings from the install. This used to happen at my old location and I could never resolve it. It lasted for months and eventually stopped happening. I forgot how miserable and unsolvable it was until today.
– T. Brian Jones
Apr 19 '16 at 22:15
I feel your pain. I came here as a last resort before I'm going to slap all my hardware into tiny little pieces. Isn't this supposed to be a fairly simple protocol?
– DerpyNerd
May 30 '17 at 11:11
I feel your pain. I came here as a last resort before I'm going to slap all my hardware into tiny little pieces. Isn't this supposed to be a fairly simple protocol?
– DerpyNerd
May 30 '17 at 11:11
I had the same error on Virtualized Linux, the problem solved changing the ethernet adapter to bridged
– Abel Barrios
Oct 12 '18 at 14:35
I had the same error on Virtualized Linux, the problem solved changing the ethernet adapter to bridged
– Abel Barrios
Oct 12 '18 at 14:35
add a comment |
4 Answers
4
active
oldest
votes
Dear 2018 and later readers,
Let me show you a comment from MelBurslan,
If you are in a corporate environment, check with your firewall admins and see if they were updating rules and/or restarting the firewall after some sort of a change when this happens. If it is happening to a personal server of yours, you need to provide more information on what were you doing on the sshd server side, when this happened. Broken pipe generally means there was a network disconnect for some reason.
So basically, if you are trying to use ssh username@0.0.0.0 over a VPN (corporate environment). Then this error must be there with you over and over.
The only solution I found so far is mobile-shell. Thanks who created it.
You will need to install mosh-server in your target (the server you want to ssh'ed to) and mosh-client in your host machine.
It will auto reconnect when your packets lost, that's pretty cool and suit all our needs, I think.
Happy ssh'ing!
answered Nov 1 '17 at 23:18
Toan NguyenToan Nguyen
2761412
add a comment |
First, make sure your issue is not related to this one.
If not and the problem is still present, read on.
I experienced this problem as well and spent a few days tried to bissect it.
Like specified, playing with SSH KeepAlive parameters or kernel TCP parameters (TCPKeepAlive on/off) does not solve the problem.
After playing with usb to ethernet drivers and TCP dump, I realized the issue was due to the kernel 4.8. I switched the source (sending side) to 4.4 LTS and the problem disappeared (rsync, scp were working nicely again). The destination side can remain on 4.8 if you want, in my use case this was working (tested).
On the technical side, we can narrow a little bit the issue thanks to the wireshark dump below I made. We can see the TCP channel of the SSHv2 protocol is being reset (RST flag of TCP set to 1) causing the connection to abort. I don't know the cause of the RST yet. I need to make some bisection from 4.8.1 to 4.8.11 for that. 
I'm not saying your problem is specifically due to the kernel 4.8, but wrt. the date you posted your question/message, you may have been using a kernel version which was actually buggy.
Answered initially on StackOverflow.
edited May 23 '17 at 12:39
Community♦
1
answered Dec 8 '16 at 17:21
wgetwget
1135
Kernel is not the problem, because I was using 4.4 LTS all the time. The real problem here was answered by @MelBursan in question's comment. My internet connection using VPN, that is why. Solution: mosh.org
– Toan Nguyen
Dec 9 '16 at 4:14
@ToanNguyen Ok. That way, could you please put his/her comment as answer to your question and mark it as fixed? :-) If you have found the technical reasons why you needed mosh, please add them too :-). On my side, I have VPN connections as well and these were working flawlessly without mosh.
– wget
Dec 9 '16 at 10:12
I'm getting back on this. The problem was not due to a buggy kernel, but to a buggy driver, especially the part dedicated to the hardware checksum offload. See this thread for more info.
– wget
Jun 2 '17 at 14:38
Does it solve your problem?
– Toan Nguyen
Jun 3 '17 at 3:24
@ToanNguyen Actually last time I had this issue I simply downgraded the kernel and it was working again. Now, I simply disabled the hw checksum offload, without downgrading anything and it solved the issue, yes.
– wget
Jun 4 '17 at 14:42
add a comment |
Open the ssh.config file on the target server with the below command:
sudo nano /etc/ssh/ssh.config
Add the below lines at the end of that file
ClientAliveInterval 300
ClientAliveCountMax 2
press Ctrl+o and enter.
sudo reboot
This acutally worked for me. I was in the same situation. Tried this and that but just follow these steps. Only this.
I hope it will work for you too.
answered Sep 12 '18 at 13:47
DonFeraRRiDonFeraRRi
11
add a comment |
I discovered it was an IPQoS option issue on my VMware Guest setup.
On the VM I set the ~/.ssh/config value for IPQoS from the default of "IPQoS af21 cs1" being low latency data for interactive first and lower effort for non-interactive for the second. Setting a new value for af21 was my solution:
Host *
IPQoS throughput
Worked for me, otherwise yes MoSH is also worked, but mosh doesn't handling my Proxy setup in a convenient way so I stick with ProxyJump commands in
answered 6 mins ago
rupert160rupert160
1062
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f259225%2fpacket-write-wait-broken-pipe-even-leaving-top-running%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Dear 2018 and later readers,
Let me show you a comment from MelBurslan,
If you are in a corporate environment, check with your firewall admins and see if they were updating rules and/or restarting the firewall after some sort of a change when this happens. If it is happening to a personal server of yours, you need to provide more information on what were you doing on the sshd server side, when this happened. Broken pipe generally means there was a network disconnect for some reason.
So basically, if you are trying to use ssh username@0.0.0.0 over a VPN (corporate environment). Then this error must be there with you over and over.
The only solution I found so far is mobile-shell. Thanks who created it.
You will need to install mosh-server in your target (the server you want to ssh'ed to) and mosh-client in your host machine.
It will auto reconnect when your packets lost, that's pretty cool and suit all our needs, I think.
Happy ssh'ing!
answered Nov 1 '17 at 23:18
Toan NguyenToan Nguyen
2761412
add a comment |
Dear 2018 and later readers,
Let me show you a comment from MelBurslan,
If you are in a corporate environment, check with your firewall admins and see if they were updating rules and/or restarting the firewall after some sort of a change when this happens. If it is happening to a personal server of yours, you need to provide more information on what were you doing on the sshd server side, when this happened. Broken pipe generally means there was a network disconnect for some reason.
So basically, if you are trying to use ssh username@0.0.0.0 over a VPN (corporate environment). Then this error must be there with you over and over.
The only solution I found so far is mobile-shell. Thanks who created it.
You will need to install mosh-server in your target (the server you want to ssh'ed to) and mosh-client in your host machine.
It will auto reconnect when your packets lost, that's pretty cool and suit all our needs, I think.
Happy ssh'ing!
answered Nov 1 '17 at 23:18
Toan NguyenToan Nguyen
2761412
add a comment |
Dear 2018 and later readers,
Let me show you a comment from MelBurslan,
If you are in a corporate environment, check with your firewall admins and see if they were updating rules and/or restarting the firewall after some sort of a change when this happens. If it is happening to a personal server of yours, you need to provide more information on what were you doing on the sshd server side, when this happened. Broken pipe generally means there was a network disconnect for some reason.
So basically, if you are trying to use ssh username@0.0.0.0 over a VPN (corporate environment). Then this error must be there with you over and over.
The only solution I found so far is mobile-shell. Thanks who created it.
You will need to install mosh-server in your target (the server you want to ssh'ed to) and mosh-client in your host machine.
It will auto reconnect when your packets lost, that's pretty cool and suit all our needs, I think.
Happy ssh'ing!
answered Nov 1 '17 at 23:18
Toan NguyenToan Nguyen
2761412
Dear 2018 and later readers,
Let me show you a comment from MelBurslan,
If you are in a corporate environment, check with your firewall admins and see if they were updating rules and/or restarting the firewall after some sort of a change when this happens. If it is happening to a personal server of yours, you need to provide more information on what were you doing on the sshd server side, when this happened. Broken pipe generally means there was a network disconnect for some reason.
So basically, if you are trying to use ssh username@0.0.0.0 over a VPN (corporate environment). Then this error must be there with you over and over.
The only solution I found so far is mobile-shell. Thanks who created it.
You will need to install mosh-server in your target (the server you want to ssh'ed to) and mosh-client in your host machine.
It will auto reconnect when your packets lost, that's pretty cool and suit all our needs, I think.
Happy ssh'ing!
answered Nov 1 '17 at 23:18
Toan NguyenToan Nguyen
2761412
answered Nov 1 '17 at 23:18
Toan NguyenToan Nguyen
2761412
answered Nov 1 '17 at 23:18
Toan NguyenToan Nguyen
2761412
answered Nov 1 '17 at 23:18
Toan NguyenToan Nguyen
2761412
2761412
add a comment |
add a comment |
First, make sure your issue is not related to this one.
If not and the problem is still present, read on.
I experienced this problem as well and spent a few days tried to bissect it.
Like specified, playing with SSH KeepAlive parameters or kernel TCP parameters (TCPKeepAlive on/off) does not solve the problem.
After playing with usb to ethernet drivers and TCP dump, I realized the issue was due to the kernel 4.8. I switched the source (sending side) to 4.4 LTS and the problem disappeared (rsync, scp were working nicely again). The destination side can remain on 4.8 if you want, in my use case this was working (tested).
On the technical side, we can narrow a little bit the issue thanks to the wireshark dump below I made. We can see the TCP channel of the SSHv2 protocol is being reset (RST flag of TCP set to 1) causing the connection to abort. I don't know the cause of the RST yet. I need to make some bisection from 4.8.1 to 4.8.11 for that.
I'm not saying your problem is specifically due to the kernel 4.8, but wrt. the date you posted your question/message, you may have been using a kernel version which was actually buggy.
Answered initially on StackOverflow.
edited May 23 '17 at 12:39
Community♦
1
answered Dec 8 '16 at 17:21
wgetwget
1135
Kernel is not the problem, because I was using 4.4 LTS all the time. The real problem here was answered by @MelBursan in question's comment. My internet connection using VPN, that is why. Solution: mosh.org
– Toan Nguyen
Dec 9 '16 at 4:14
@ToanNguyen Ok. That way, could you please put his/her comment as answer to your question and mark it as fixed? :-) If you have found the technical reasons why you needed mosh, please add them too :-). On my side, I have VPN connections as well and these were working flawlessly without mosh.
– wget
Dec 9 '16 at 10:12
I'm getting back on this. The problem was not due to a buggy kernel, but to a buggy driver, especially the part dedicated to the hardware checksum offload. See this thread for more info.
– wget
Jun 2 '17 at 14:38
Does it solve your problem?
– Toan Nguyen
Jun 3 '17 at 3:24
@ToanNguyen Actually last time I had this issue I simply downgraded the kernel and it was working again. Now, I simply disabled the hw checksum offload, without downgrading anything and it solved the issue, yes.
– wget
Jun 4 '17 at 14:42
add a comment |
First, make sure your issue is not related to this one.
If not and the problem is still present, read on.
I experienced this problem as well and spent a few days tried to bissect it.
Like specified, playing with SSH KeepAlive parameters or kernel TCP parameters (TCPKeepAlive on/off) does not solve the problem.
After playing with usb to ethernet drivers and TCP dump, I realized the issue was due to the kernel 4.8. I switched the source (sending side) to 4.4 LTS and the problem disappeared (rsync, scp were working nicely again). The destination side can remain on 4.8 if you want, in my use case this was working (tested).
On the technical side, we can narrow a little bit the issue thanks to the wireshark dump below I made. We can see the TCP channel of the SSHv2 protocol is being reset (RST flag of TCP set to 1) causing the connection to abort. I don't know the cause of the RST yet. I need to make some bisection from 4.8.1 to 4.8.11 for that.
I'm not saying your problem is specifically due to the kernel 4.8, but wrt. the date you posted your question/message, you may have been using a kernel version which was actually buggy.
Answered initially on StackOverflow.
edited May 23 '17 at 12:39
Community♦
1
answered Dec 8 '16 at 17:21
wgetwget
1135
Kernel is not the problem, because I was using 4.4 LTS all the time. The real problem here was answered by @MelBursan in question's comment. My internet connection using VPN, that is why. Solution: mosh.org
– Toan Nguyen
Dec 9 '16 at 4:14
@ToanNguyen Ok. That way, could you please put his/her comment as answer to your question and mark it as fixed? :-) If you have found the technical reasons why you needed mosh, please add them too :-). On my side, I have VPN connections as well and these were working flawlessly without mosh.
– wget
Dec 9 '16 at 10:12
I'm getting back on this. The problem was not due to a buggy kernel, but to a buggy driver, especially the part dedicated to the hardware checksum offload. See this thread for more info.
– wget
Jun 2 '17 at 14:38
Does it solve your problem?
– Toan Nguyen
Jun 3 '17 at 3:24
@ToanNguyen Actually last time I had this issue I simply downgraded the kernel and it was working again. Now, I simply disabled the hw checksum offload, without downgrading anything and it solved the issue, yes.
– wget
Jun 4 '17 at 14:42
add a comment |
First, make sure your issue is not related to this one.
If not and the problem is still present, read on.
I experienced this problem as well and spent a few days tried to bissect it.
Like specified, playing with SSH KeepAlive parameters or kernel TCP parameters (TCPKeepAlive on/off) does not solve the problem.
After playing with usb to ethernet drivers and TCP dump, I realized the issue was due to the kernel 4.8. I switched the source (sending side) to 4.4 LTS and the problem disappeared (rsync, scp were working nicely again). The destination side can remain on 4.8 if you want, in my use case this was working (tested).
On the technical side, we can narrow a little bit the issue thanks to the wireshark dump below I made. We can see the TCP channel of the SSHv2 protocol is being reset (RST flag of TCP set to 1) causing the connection to abort. I don't know the cause of the RST yet. I need to make some bisection from 4.8.1 to 4.8.11 for that.
I'm not saying your problem is specifically due to the kernel 4.8, but wrt. the date you posted your question/message, you may have been using a kernel version which was actually buggy.
Answered initially on StackOverflow.
edited May 23 '17 at 12:39
Community♦
1
answered Dec 8 '16 at 17:21
wgetwget
1135
First, make sure your issue is not related to this one.
If not and the problem is still present, read on.
I experienced this problem as well and spent a few days tried to bissect it.
Like specified, playing with SSH KeepAlive parameters or kernel TCP parameters (TCPKeepAlive on/off) does not solve the problem.
After playing with usb to ethernet drivers and TCP dump, I realized the issue was due to the kernel 4.8. I switched the source (sending side) to 4.4 LTS and the problem disappeared (rsync, scp were working nicely again). The destination side can remain on 4.8 if you want, in my use case this was working (tested).
On the technical side, we can narrow a little bit the issue thanks to the wireshark dump below I made. We can see the TCP channel of the SSHv2 protocol is being reset (RST flag of TCP set to 1) causing the connection to abort. I don't know the cause of the RST yet. I need to make some bisection from 4.8.1 to 4.8.11 for that.
I'm not saying your problem is specifically due to the kernel 4.8, but wrt. the date you posted your question/message, you may have been using a kernel version which was actually buggy.
Answered initially on StackOverflow.
edited May 23 '17 at 12:39
Community♦
1
answered Dec 8 '16 at 17:21
wgetwget
1135
edited May 23 '17 at 12:39
Community♦
1
edited May 23 '17 at 12:39
Community♦
1
edited May 23 '17 at 12:39
Community♦
1
1
answered Dec 8 '16 at 17:21
wgetwget
1135
answered Dec 8 '16 at 17:21
wgetwget
1135
answered Dec 8 '16 at 17:21
wgetwget
1135
1135
Kernel is not the problem, because I was using 4.4 LTS all the time. The real problem here was answered by @MelBursan in question's comment. My internet connection using VPN, that is why. Solution: mosh.org
– Toan Nguyen
Dec 9 '16 at 4:14
@ToanNguyen Ok. That way, could you please put his/her comment as answer to your question and mark it as fixed? :-) If you have found the technical reasons why you needed mosh, please add them too :-). On my side, I have VPN connections as well and these were working flawlessly without mosh.
– wget
Dec 9 '16 at 10:12
I'm getting back on this. The problem was not due to a buggy kernel, but to a buggy driver, especially the part dedicated to the hardware checksum offload. See this thread for more info.
– wget
Jun 2 '17 at 14:38
Does it solve your problem?
– Toan Nguyen
Jun 3 '17 at 3:24
@ToanNguyen Actually last time I had this issue I simply downgraded the kernel and it was working again. Now, I simply disabled the hw checksum offload, without downgrading anything and it solved the issue, yes.
– wget
Jun 4 '17 at 14:42
add a comment |
Kernel is not the problem, because I was using 4.4 LTS all the time. The real problem here was answered by @MelBursan in question's comment. My internet connection using VPN, that is why. Solution: mosh.org
– Toan Nguyen
Dec 9 '16 at 4:14
@ToanNguyen Ok. That way, could you please put his/her comment as answer to your question and mark it as fixed? :-) If you have found the technical reasons why you needed mosh, please add them too :-). On my side, I have VPN connections as well and these were working flawlessly without mosh.
– wget
Dec 9 '16 at 10:12
I'm getting back on this. The problem was not due to a buggy kernel, but to a buggy driver, especially the part dedicated to the hardware checksum offload. See this thread for more info.
– wget
Jun 2 '17 at 14:38
Does it solve your problem?
– Toan Nguyen
Jun 3 '17 at 3:24
@ToanNguyen Actually last time I had this issue I simply downgraded the kernel and it was working again. Now, I simply disabled the hw checksum offload, without downgrading anything and it solved the issue, yes.
– wget
Jun 4 '17 at 14:42
Kernel is not the problem, because I was using 4.4 LTS all the time. The real problem here was answered by @MelBursan in question's comment. My internet connection using VPN, that is why. Solution: mosh.org
– Toan Nguyen
Dec 9 '16 at 4:14
Kernel is not the problem, because I was using 4.4 LTS all the time. The real problem here was answered by @MelBursan in question's comment. My internet connection using VPN, that is why. Solution: mosh.org
– Toan Nguyen
Dec 9 '16 at 4:14
@ToanNguyen Ok. That way, could you please put his/her comment as answer to your question and mark it as fixed? :-) If you have found the technical reasons why you needed mosh, please add them too :-). On my side, I have VPN connections as well and these were working flawlessly without mosh.
– wget
Dec 9 '16 at 10:12
@ToanNguyen Ok. That way, could you please put his/her comment as answer to your question and mark it as fixed? :-) If you have found the technical reasons why you needed mosh, please add them too :-). On my side, I have VPN connections as well and these were working flawlessly without mosh.
– wget
Dec 9 '16 at 10:12
I'm getting back on this. The problem was not due to a buggy kernel, but to a buggy driver, especially the part dedicated to the hardware checksum offload. See this thread for more info.
– wget
Jun 2 '17 at 14:38
I'm getting back on this. The problem was not due to a buggy kernel, but to a buggy driver, especially the part dedicated to the hardware checksum offload. See this thread for more info.
– wget
Jun 2 '17 at 14:38
Does it solve your problem?
– Toan Nguyen
Jun 3 '17 at 3:24
Does it solve your problem?
– Toan Nguyen
Jun 3 '17 at 3:24
@ToanNguyen Actually last time I had this issue I simply downgraded the kernel and it was working again. Now, I simply disabled the hw checksum offload, without downgrading anything and it solved the issue, yes.
– wget
Jun 4 '17 at 14:42
@ToanNguyen Actually last time I had this issue I simply downgraded the kernel and it was working again. Now, I simply disabled the hw checksum offload, without downgrading anything and it solved the issue, yes.
– wget
Jun 4 '17 at 14:42
add a comment |
Open the ssh.config file on the target server with the below command:
sudo nano /etc/ssh/ssh.config
Add the below lines at the end of that file
ClientAliveInterval 300
ClientAliveCountMax 2
press Ctrl+o and enter.
sudo reboot
This acutally worked for me. I was in the same situation. Tried this and that but just follow these steps. Only this.
I hope it will work for you too.
answered Sep 12 '18 at 13:47
DonFeraRRiDonFeraRRi
11
add a comment |
Open the ssh.config file on the target server with the below command:
sudo nano /etc/ssh/ssh.config
Add the below lines at the end of that file
ClientAliveInterval 300
ClientAliveCountMax 2
press Ctrl+o and enter.
sudo reboot
This acutally worked for me. I was in the same situation. Tried this and that but just follow these steps. Only this.
I hope it will work for you too.
answered Sep 12 '18 at 13:47
DonFeraRRiDonFeraRRi
11
add a comment |
Open the ssh.config file on the target server with the below command:
sudo nano /etc/ssh/ssh.config
Add the below lines at the end of that file
ClientAliveInterval 300
ClientAliveCountMax 2
press Ctrl+o and enter.
sudo reboot
This acutally worked for me. I was in the same situation. Tried this and that but just follow these steps. Only this.
I hope it will work for you too.
answered Sep 12 '18 at 13:47
DonFeraRRiDonFeraRRi
11
Open the ssh.config file on the target server with the below command:
sudo nano /etc/ssh/ssh.config
Add the below lines at the end of that file
ClientAliveInterval 300
ClientAliveCountMax 2
press Ctrl+o and enter.
sudo reboot
This acutally worked for me. I was in the same situation. Tried this and that but just follow these steps. Only this.
I hope it will work for you too.
answered Sep 12 '18 at 13:47
DonFeraRRiDonFeraRRi
11
answered Sep 12 '18 at 13:47
DonFeraRRiDonFeraRRi
11
answered Sep 12 '18 at 13:47
DonFeraRRiDonFeraRRi
11
answered Sep 12 '18 at 13:47
DonFeraRRiDonFeraRRi
11
11
add a comment |
add a comment |
I discovered it was an IPQoS option issue on my VMware Guest setup.
On the VM I set the ~/.ssh/config value for IPQoS from the default of "IPQoS af21 cs1" being low latency data for interactive first and lower effort for non-interactive for the second. Setting a new value for af21 was my solution:
Host *
IPQoS throughput
Worked for me, otherwise yes MoSH is also worked, but mosh doesn't handling my Proxy setup in a convenient way so I stick with ProxyJump commands in
answered 6 mins ago
rupert160rupert160
1062
add a comment |
I discovered it was an IPQoS option issue on my VMware Guest setup.
On the VM I set the ~/.ssh/config value for IPQoS from the default of "IPQoS af21 cs1" being low latency data for interactive first and lower effort for non-interactive for the second. Setting a new value for af21 was my solution:
Host *
IPQoS throughput
Worked for me, otherwise yes MoSH is also worked, but mosh doesn't handling my Proxy setup in a convenient way so I stick with ProxyJump commands in
answered 6 mins ago
rupert160rupert160
1062
add a comment |
I discovered it was an IPQoS option issue on my VMware Guest setup.
On the VM I set the ~/.ssh/config value for IPQoS from the default of "IPQoS af21 cs1" being low latency data for interactive first and lower effort for non-interactive for the second. Setting a new value for af21 was my solution:
Host *
IPQoS throughput
Worked for me, otherwise yes MoSH is also worked, but mosh doesn't handling my Proxy setup in a convenient way so I stick with ProxyJump commands in
answered 6 mins ago
rupert160rupert160
1062
I discovered it was an IPQoS option issue on my VMware Guest setup.
On the VM I set the ~/.ssh/config value for IPQoS from the default of "IPQoS af21 cs1" being low latency data for interactive first and lower effort for non-interactive for the second. Setting a new value for af21 was my solution:
Host *
IPQoS throughput
Worked for me, otherwise yes MoSH is also worked, but mosh doesn't handling my Proxy setup in a convenient way so I stick with ProxyJump commands in
answered 6 mins ago
rupert160rupert160
1062
answered 6 mins ago
rupert160rupert160
1062
answered 6 mins ago
rupert160rupert160
1062
answered 6 mins ago
rupert160rupert160
1062
1062
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f259225%2fpacket-write-wait-broken-pipe-even-leaving-top-running%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
If you are in a corporate environment, check with your firewall admins and see if they were updating rules and/or restarting the firewall after some sort of a change when this happens. If it is happening to a personal server of yours, you need to provide more information on what were you doing on the sshd server side, when this happened.
Broken pipegenerally means there was a network disconnect for some reason.– MelBurslan
Feb 2 '16 at 6:20
I just moved and this is happening constantly with my new connection. Cox Cable is my ISP, and I've got a Netgear C6300BD cable modem running on default settings from the install. This used to happen at my old location and I could never resolve it. It lasted for months and eventually stopped happening. I forgot how miserable and unsolvable it was until today.
– T. Brian Jones
Apr 19 '16 at 22:15
I feel your pain. I came here as a last resort before I'm going to slap all my hardware into tiny little pieces. Isn't this supposed to be a fairly simple protocol?
– DerpyNerd
May 30 '17 at 11:11
I had the same error on Virtualized Linux, the problem solved changing the ethernet adapter to bridged
– Abel Barrios
Oct 12 '18 at 14:35