ERR_EMPTY_RESPONSE and SSH not working
Indrek Ots
by Indrek Ots
1 min read

Categories

  • articles

Tags

  • ssh
  • chromium
  • chrome
  • git
  • mtu
  • ifconfig

Notice! This post is more than a year old. It may be outdated.

I was browsing the Internet on a WiFi network I have never used before. Everything seemed fine until I found that some web apps did not work correctly. Initially I thought the web app had problems and didn’t pay much attention to it, hoping it would be fixed soon. Then I realized that the same web apps work correctly on my phone. Something smells fishy and I started to debug.

Have I updated anything major recently? Not that I know of. Did I try a different browser? Yes, same issues. For some websites Chrome says the website didn’t send any data (ERR_EMPTY_RESPONSE).

Error in Chromium
Error screen in Chromium

At first I thought ERR_EMPTY_RESPONSE can be caused by ad-block software. After disabling all browser plugins, the issue still persisted. Then I used a different WiFi network by creating a hotspot with my phone. Surprisingly the issues were resolved. Something wrong with the network then, right? Probably. Since I was not going to use the problematic WiFi network for long, I decided that I can manage without some web apps for now.

All went well until I started to use Git. As luck would have it, pushing commits did not work. Turns out, SSH does not make the connection. Running SSH with verbose mode I saw that it got stuck at expecting SSH2_MSG_KEX_ECDH_REPLY.

After some further googling I found that there might be a MTU/fragmentation problem.

At each routing hop, IP packets bigger than the outgoing interface’s Maximum Transmission Unit (MTU) get fragmented. Only the first fragment has TCP port numbers. Firewalls often behave badly in the presence of packet fragmentation, dropping everything but the first fragment since the subsequent ones can’t be matched against the firewall rules. Some NAT configuration (eg many-to-one NAT or port address translation) can’t match the fragments against their translation state tables.

Setting my network interface’s MTU to 576 solved all issues. SSH started working correctly and no issues with Chrome either.

# view ifconfig to see all interfaces
# eth0 is the interface I was using
$ ifconfig eth0 mtu 576