packet_write_wait Broken pipe even leaving top running?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












20















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.










share|improve this question

















  • 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











  • 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















20















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.










share|improve this question

















  • 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











  • 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













20












20








20


5






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.










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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 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 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





    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 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










4 Answers
4






active

oldest

votes


















7














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!






share|improve this answer






























    1














    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. enter image description here



    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.






    share|improve this answer

























    • 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


















    0














    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.






    share|improve this answer






























      0














      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






      share|improve this answer






















        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
        );



        );













        draft saved

        draft discarded


















        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









        7














        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!






        share|improve this answer



























          7














          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!






          share|improve this answer

























            7












            7








            7







            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!






            share|improve this answer













            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!







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 1 '17 at 23:18









            Toan NguyenToan Nguyen

            2761412




            2761412























                1














                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. enter image description here



                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.






                share|improve this answer

























                • 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















                1














                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. enter image description here



                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.






                share|improve this answer

























                • 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













                1












                1








                1







                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. enter image description here



                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.






                share|improve this answer















                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. enter image description here



                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.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited May 23 '17 at 12:39









                Community

                1




                1










                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

















                • 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











                0














                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.






                share|improve this answer



























                  0














                  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.






                  share|improve this answer

























                    0












                    0








                    0







                    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.






                    share|improve this answer













                    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.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Sep 12 '18 at 13:47









                    DonFeraRRiDonFeraRRi

                    11




                    11





















                        0














                        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






                        share|improve this answer



























                          0














                          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






                          share|improve this answer

























                            0












                            0








                            0







                            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






                            share|improve this answer













                            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







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Jan 25 at 3:08









                            rupert160rupert160

                            1062




                            1062



























                                draft saved

                                draft discarded
















































                                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.




                                draft saved


                                draft discarded














                                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





















































                                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






                                Popular posts from this blog

                                How to check contact read email or not when send email to Individual?

                                Bahrain

                                Postfix configuration issue with fips on centos 7; mailgun relay