6

The situation is this: there is a an ssh client (Ubuntu 14.04) and an ssh server (Debian 7). There is a bunch of networking in between them. SSH connection is easily (and quickly) established and works fine and fast.

However, if the connection is left idle for some time, then a strange thing happens - the connection is still alive: I can enter commands, run them and the commands will be executed on the server, but if one of those commands or a sum of multiple executions produces too much data (just a few lines of text is enough) then the connection freezes and after a while (when I press something again) disconnects with a broken pipe. During the freeze both server and client handle the connection as still being open.

The connection does not get into that state if there is something like 'top' running there to keep sending data all the time.

I've tried all kinds of debugging options and logs, but see no hints that would explain what is happening. The most confusing part is that the connection still works for a bit before actually freezing. Any hint is appreciated.

2 Answers 2

3

You likely have an MTU issue in your connection between your client and server.

Sometimes this will be found at the router level, or it could a firewall issue (allowing fragmented packets helps in some cases). You'll often see this if you run something like dmesg (with a lot of output) versus smaller commands.

Do you manage the intermediate networking? Can you mention this to whomever is responsible for it?

2
  • MTU is stable 1500 all the way. And that does not explain why running something like "ps aux" or "dmesg" works fine when I have just connected to the server, but only returns a few lines before freezing after some 15 minutes of inactivity in the connection?
    – aigarius
    Nov 27, 2014 at 14:15
  • This is not a server issue alone. You can configure keepalives on the server end, but this also lies in the networking between you and the server. Who manages the networking?
    – ewwhite
    Nov 27, 2014 at 14:46
1

If they are in the same network it could be a problem with jumbo frames, a particular case of an mtu problem.

Lots of fast output force bigger packets.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .