0

Motivated by a previous issue that I had Can not ssh on remote host, I figured out the solution on Super User here, which basically amounts to reducing the MTU size that I have for my ethernet connection. In particular, using a command of the form sudo ifconfig eth0 mtu 1200 up I was able to ssh to the remote host. However, such a change is not permanent (that is, it is lost after a reboot).

According to the instructions, one should change the file /etc/network/interfaces and add the line mtu 1200. I did this, by adding the line right below the ethernet interface, but for some reason it is not read. I have also tried to leave no blank space on the same line, as well as adding 4 spaces and thus indent the command but with no luck in either case.

So, how can we make such a change permanently? Thank you in advance!

Improve this question

1 Answer 1

Reset to default
2

I find it very hard to believe that this can have anything to do with the MTU, especially since you are on the same network segment. I looked through the posts you are linking to, and none include packet captures or any other attempts to diagnose this. Remember, just because someone posts an answer on SE does not necessarily mean they know what they are talking about (that applies to me as well, of course :) ).

Before you start futzing around with changing the MTU, verify that this is actually a problem. Let's say you are on 192.0.200.33 and the target you are having trouble with is 192.0.200.42. Check your interface mtus, they should both be 1500 (if not, modify the diagnostic procedure accordingly).

  1. On .33, run tcpdump -n -v -v -v -i eth0 port 9999
  2. From another window, run telnet 192.0.200.42 9999. Look at the tcpdump output and verify that the DF bit flag is set.
  3. On .33, add a host route to .42: ip route add 192.0.200.42/32 dev eth0 mtu lock 1500
  4. On .42, run ip route add 192.0.200.33/32 dev eth0 mtu lock 1500
  5. Repeat step 2. You should now see that the DF flag has disappeared.

Now try to ssh from .33 to .42. Are you still having trouble connecting? If you do, the MTU was never the problem. If you can now connect, something really weird is going on, and it would help if you could collect tcpdump traces that could be analyzed.

To answer your original question, the permanent way to change the MTU is to add a line to /etc/network/interfaces for the interface in question. If you are configuring over dhcp, edit /etc/dhcp/dhclient.conf to contain the line supersede interface-mtu 1200; (or whatever).

Improve this answer
4
  • I understand what you say and this is precisely what I mentioned in SuperUser. However this is only part of the story. I never have a connectivity issue in my lan. The case that fails may require a particular server in between, so that link is established. For this reason, at least one of the servers on the link that is established between the two countries is different so that a certain privacy/security (or other) service can be provided all along. But now, it turns out that one of these guys breaks the link because it can not handle a certain size of MTU.
    – MightyMouse
    Commented May 31, 2016 at 11:52
  • In particular, when the key exchange fails, it is the case that aes128-ctr [email protected] none is selected to be the method/protocol that will be used and it is only this case that fails. So, at least one of the servers in the link that is established fails to work with this protocol for an MTU size of 1500. As of the rest, that's where I need help. I have tried the idea of changing /etc/network/interfaces as well as /etc/dhcp/dhclient.conf with the line that you suggested, but still, after a reboot the MTU size is 1500. Sorry but I am really looking for that whatever part.
    – MightyMouse
    Commented May 31, 2016 at 12:20
  • You didn't say your machines were on different networks. I guess something in between is not obeying PMTU discovery and messing it up.
    – JayEye
    Commented May 31, 2016 at 14:20
  • 1
    I did mention this, but perhaps it is easy to ignore this bit of information as 5 computers are tested (4 on the same network and 1 remotely in a different country). From the beginning of my post "There is a raspberry pi 2 on a different continent to which I can connect from my macbook ..." and later "With the very same ssh command I fail to do so when I use <put some recent raspberries here running jessie>". In any case, it is even stranger, because when I specifically pass as parameter the same mac, then ssh works. Even more surprisingly, automatic mac also works in the reverse direction!
    – MightyMouse
    Commented May 31, 2016 at 14:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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