For a while I've been having a problem with some SSH connections to remote servers (OpenSSH client from Gnome terminal on Ubuntu desktop to OpenSSH server on remote server). Connection is fine, but at some point during data transfer the connection will die. It's always (as far as I can tell) during transfer of date from server to client, eg I'll do "ls" and get half a directory listing, then nothing. The connection doesn't close (it becomes unresponsive and I have to kill the terminal).
Until now this has been annoying but not a show stopper; it happens fairly rarely. However, this weekend I'm at a LAN event talking to the server over a shared 3G connection (my PC -> IPCop -> Windows laptop with 3G modem and Windows Connection Sharing*) and the same symptoms are occurring, just far more frequently.
All of which I think might give a clue as to what's wrong, but I can't work it out. Any clues?
[*] 3G Modem comes with Windows software, this is the only way we could think to do this!
Mark Rogers wrote:
For a while I've been having a problem with some SSH ... The connection doesn't close (it becomes unresponsive and I have to kill the terminal).
http://www.snailbook.com/faq/mtu-mismatch.auto.html
-- Martijn
Martijn Koster wrote:
Ah, I thought it might be something to do with MTU values, but felt like I was just guessing. Thanks.
At present my MTU is set to 1500 (according to ifconfig). If I test the route to my server: ping -s 1472 -M do ip.of.my.server I get a reliable response. (-s 1473 fails, which I would expect with the TCP/IP overhead of 28bytes)
If I follow the advice of the linked FAQ I will be reducing my MTU to 576. I don't see that having a noticeably negative effect on SSH but will it negatively affect other traffic?
[NB: Test just performed from office away from 3G connection I was using over the weekend; I would not be surprised if reducing the MTU over the weekend would have been necessary. Connections from the office are far more reliable but do drop sometimes.]
On Mon, 2007-10-29 at 14:00 +0000, Mark Rogers wrote:
Martijn Koster wrote:
If things are really how I thought I understood them to be then something about that article doesn't read right. You shouldn't have to set the MTU at both ends considering the other. You simply set the MTU at each end to something appropriate for the connection it has. Then the appropriate MTU for a given connection should be determined by Path MTU or worked around with allowable fragmentation. Setting all your interfaces to an MTU that low might work around an MTU mismatch somewhere simply because the figure is so low.
But by doing that you will increase the ratio of data to tcp overhead.
It could fix your ssh problem but I suspect it will have quite a negative effect on any local traffic on the same interface.
What should happen is that Path MTU should discover the lowest MTU in the route and operate to that. The way I understand it blocking ICMP at either end will break PMTU. Also some sites (and presumably some networks) are broken in that they don't cooperate with PMTU and don't allow fragmentation either which means that if you aren't set to the correct MTU you can't talk to them.
Also check the MTU setting on your Broadband router/interface 1458 is a figure that gets mentioned a lot but it is really dependant on the ISP and encapsulation type of your connection (AOL for example often requires 1400)
-
Mark Rogers -
Martijn Koster -
Wayne Stallwood