0

Recently, my home ISP service changed to AT&T Uverse. While it's much faster than the old copper-wire DSL (!) I had before, there are transient drops of ssh connections.

I can't determine a pattern: sometimes, a link will stay up for several days, but then I'll have a series of drops every minute or two. This seems only to affect ssh connections. Both the server and my local machine report a "broken pipe" error.

My local machine is a System76 Lemur running Ubuntu 16.04.1; the remote is a virtual FreeBSD box (10.3). I appear to have the same results with

ssh -Y

or

ssh -X

ATT hasn't been much help (since I suppose ssh is outside the standard home user world).

2

Previous discussions:

https://askubuntu.com/questions/127369/how-to-prevent-write-failed-broken-pipe-on-ssh-connection

https://superuser.com/questions/37738/how-to-reliably-keep-an-ssh-tunnel-open

Two things spring to mind (since complaining to AT&T is going to be futile):

1) I've had problems with firewalls dropping connections when there's no traffic. That doesn't sound like your case, but it wouldn't hurt to add a 30-second keep-alive as part of the ssh session.

https://stackoverflow.com/questions/25084288/keep-ssh-session-alive

2) Use Gnu screen (or better tmux if you have it on the FreeBSD box) so that at least when you reconnect no work is lost. screen -RR in your .profile makes this incredibly convenient to make sure you always have a screen session running. Using autossh with this will at least minimize the pain.

5
  • Thanks for this. I've already tried tweaking the ssh parameters at the client and server end, and I initially thought that was the issue, but the problem is so erratically transient that you can't really tell if it's fixed. Anyway, as you suspect, that doesn't seem to b the problem. Dec 5 '16 at 14:56
  • Updating this a little: I've discovered that pushing ClientAliveInterval, ClientAliveCountMax at the server and ServerAliveInterval and ServerAliveCountMax at the client end up to pretty high values (60 and 6 in each case) will at least (in most cases) prevent the eventual "broken pipe" error and lost connection, though there can be waits of several minutes. My unsophisticated conclusion is that the problem is somewhere on the path between my laptop and my server and thus beyond my control; any ideas about what it might be? It's still a highly transient problem. Dec 6 '16 at 22:26
  • It's very challenging to figure out where the problem might be. You can start by setting something up to check the connection from your client PC to multiple locations - I've done something like this with oss.oetiker.ch/smokeping - one target being my internal Uverse router, one the server IP and then a couple of well-known addresses just for fun (www.google.com and www.att.net worked for me). After setting that up and running for a few months it just proved that Uverse is flaky. Dec 8 '16 at 3:44
  • That's what I've come to suspect (i.e. Uverse is flaky). Having adjusted the parameters at both ends to b very generous about timeouts (*AliveInterval=60,, *AliveCountMax=20), I've found that sometimes a connection will stay live for three days (just recently) and then long waits will happen every five minutes or so, eventually becoming so long I get a broken pipe. I don't see the point in paying $180/yr to ATT for advanced support, so I suppose I'll have to live with it. But thanks very much for suggesting smokeping. Dec 9 '16 at 0:08
  • It was reassuring to be able to check the smokeping pages and confirm that "yes indeed, AT&T is flipping out now, I'm not crazy". In my case I went thru six months of daily issues until one day it just fixed itself. Attempts to get support to look at my smokeping stats were futile ;-) Dec 12 '16 at 19:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.