Lost connection to mysql server at handshake reading initial communication packet system error 11

Skip to content

Lost connection to MySQL server at reading initial communication packet, is an error we get while connecting to a MySQL database.

As part of our Server management services, Bobcares provides solutions for every query.

Let’s take a look at how our Support team handled this situation.

Lost connection to MySQL server at ‘reading initial communication packet

While connecting to a MySQL database, we might run into this error: Lost connection to MySQL server at reading initial communication packet, system error: 0

There appears to be an issue with the firewall, which is preventing outside connections. We should check the firewall rules to see if they are blocking any MySQL connections.

If the firewall isn’t the problem, check the list below to see if we have any of the following:

1. Verify that MySQL is running on the server’s IP address.
2. Then, Make sure MySQL is listening on port 3306.
3. Ensure that the user has permission to connect to the server IP.
4. Make sure we’re using the correct password for connecting from the host address we’re connecting from if one is required.

Most of the time, MySQL only listens on localhost and does not accept connections from other computers. As a result, we can’t connect from the outside leading to the Lost Connection to MySQL Server error.

In the my.cnf file, look at the bind-address variable. Because it defaults to localhost, only connections from that host will work.

• Comment out the line: to ensure MySQL listens on all addresses. #bind-address = 127.0.0.1

• Then restart the server as follows: sudo service mysql restart

• GRANT ALL PRIVILEGES ON ourDB.* TO 'username'@'OUR_APPLICATION_IP' IDENTIFIED BY 'OUR_PASSWORD' WITH GRANT OPTION;

If we still get the error, then:

1. Allow applications through the Windows Firewall.
2. The path to mysql is typically C:/Program Files (x86)/MySQL/bin/mysql, so we’ll need to add it to the list.
3. Click Apply after marking both private and public networks.

If the IP address is blocked by Firewalld. Use the following commands to grant access: firewall-cmd --permanent --zone=trusted --add-source=OUR_IP/32 firewall-cmd --permanent --zone=trusted --add-port=3306/tcp firewall-cmd --reload

Another solution for the Lost Connection to MySQL Server error is to choose + to add a new connection in the workbench and enter the following information:

• TCP/IP over SSH is the connection method.
• xxx.xxx.xx.xx:xx (replace xx with remote SSH server IP and port(optional)) is the SSH Hostname
• Enter the SSH username
• At the prompt, we can set a password.
• MYSQL Localhost or 127.0.0.1 is the hostname.
• Port:3306 MYSQL Server
• At the prompt, we can enter a password or add a new one.

Then, check the connection. If it is successful, click OK.

If nothing else works, flush the privileges. mysql> FLUSH PRIVILEGES;

[Looking for a solution to another query? We are just a click away.]

Conclusion

To sum up, our Support team was successful in resolving the error: Lost connection to MySQL server at reading initial communication packet with the above steps

To share a bit more detail: the reason for this is generally that your MySQL GRANT is configured as user@localhost. Therefore, connecting over the external IP address does not match the @localhost portion, and your connection is rejected. Specifically, because no users in the mysql.user table match the external address in their host column, the connection is rejected immediately. You can see this by the simple expedient of telneting to the port:

$ telnet example.com 3306
Trying 255.0.0.71...
Connected to example.com.
Escape character is '^]'.
FHost '255.0.0.70' is not allowed to connect to this MySQL serverConnection closed by foreign host.
$

As you can see, before authentication is even attempted, the connection is killed. If you had a host entry that could have satisfied this request, you would have gotten an authentication failed message, instead. But in this case, the connection died before authentication was even requested or sent, thus the lost connection at «reading initial communication packet»; the very first packet sent included a disconnection!

To resolve this, either use a hostname value in your databases array for which there will be a corresponding host column entry in the mysql.user table, or add an explicit grant that covers the use case, e.g.:

GRANT ALL ON drupal.* TO 'drupal'@'255.0.0.70' IDENTIFIED BY 'YjbW7dUT';
FLUSH HOSTS; FLUSH PRIVILEGES;

Note that you can also use ‘%’ as a wildcard, as in:

GRANT ALL ON drupal.* TO 'drupal'@'255.0.0.%' IDENTIFIED BY 'YjbW7dUT';

or even:

GRANT ALL ON drupal.* TO 'drupal'@'%' IDENTIFIED BY 'YjbW7dUT';

Don’t use this last one unless you have a firewall in front of your MySQL server. (Which you already have anyway, right? Right.)

Bonus Section

MySQL treats localhost specially. Specifically, localhost means to use the UNIX socket, whereas 127.0.0.1 means to use TCP/IP networking. Therefore, you can run into the strange case where the two are not interchangeable, despite the fact that in every other part of the *NIX world, they are. This can commonly happen when you have skip-name-resolve specified in your my.cnf; your GRANTs for localhost now don’t cover access over TCP/IP, and vice versa.

To fix, either add a localhost GRANT for each 127.0.0.1 one (and vice versa), or change all host columns in the user table to %—which, at the risk of repeating myself from earlier, should only be done if you are behind a firewall in which you are eminently confident.