Server responds with empty packet during session negotiation resulting in client giving a malformed packet error

I laid out clear terms as to what was going on, suggesting it was likely a configuration issue on the specific server I was trying to connect to (eg, happens on server 1, but not server 2, though they are the same version). That sort of thing is on-topic:

If you have a question about...

    Database Administration including configuration and backup / restore

I provided clear and detailed evidence and output of what I had tried and what failed, with exact syntax errors and pcap data. Yet it got closed as off topic as a possibly typo or command error? That is the sort of action I'd expect from someone who doesn't understand or want to try to understand how a protocol works - not what I'd expect from a community of experts...

In any case, I dug through the protocol myself and figured out it was in fact a configuration issue, not a simple "too old" of a version as suggested in comments without providing any evidence or reasoning as to why he thought that...

In any case, I still think it is valid (yes 5.0 is old, but old does not mean out of production). Lots of enterprises still use old software simply because it still works, and that makes this sort of issue more likely to be seen. I added all the proper documentation from the MySQL site showing the configuration that caused the problem.

3 Answers 3


I was not one of the reviewers or close voters, but a contributory factor may have been the first comment (now deleted):


A vote to close as too localized around the same time initiated a Close Review process. Privileged users taking part in that review had the following options:

  • Vote to leave the question open; (three needed)
  • Edit the question to improve it; (one needed, leaves the question open)
  • Skip the item;
  • Add another vote to close. (five needed)

Three votes to close were acquired via the review process. None of the other available options were selected by reviewers. A further two close votes were placed outside the review process, bringing the total to the five community close votes needed to place the question on hold.

It seems (to me) at least possible that reviewers and direct voters were influenced by the apparent "basic error" pointed out in the first comment.

This is one of the reasons I dislike answers in comments so much; alongside the fact that 'comment answers' cannot be downvoted if incorrect (and other factors, but I will try not to rant).

The question has now been reopened (by five community votes). You did the right thing by bringing this up on meta, thank you.

Note: I have invited all the closing process participants to contribute here, should they wish to explain their own reasoning.


The "close reason" text:

Too localized - this could be because your code has a typo, basic error, or is not relevant to most of our audience.

I've italicized the part I feel is relevant to your question. Please don't take this personally; I think you did a fantastic job of providing a lot of detail, even going so far as to provide packet data, which most people don't even know how to do, let alone that they might provide it.

In my mind, since the question appears to be related to the protocol, it would only appeal to a very small slice of DBAs; those with network-sniffer experience.

I've voted to re-open the question since you've added details that I think help make the question have broader appeal. Assuming the question gets enough "re-open" votes, you might want to provide the answer, which I'm certain will be up-voted.

  • 2
    Question has been reopened. Apr 15, 2016 at 5:42

All my fault. I missed:

I would accept that answer if it didn't work perfectly with another server of the same version already

... so you can blame me :-)

That part completely changed the question, and I skimmed over it.

I enjoy admitting being wrong, so it's all good.

You must log in to answer this question.

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