Bug #52923 Inadequate documentation of "Can't get hostname for your address" error
Submitted: 18 Apr 2010 3:25 Modified: 20 Sep 2011 17:18
Reporter: Peter Brawley (Basic Quality Contributor) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Command-line Clients Severity:S3 (Non-critical)
Version:5.5 OS:Any (MS Windows, Mac OS X)
Assigned to: Alexander Nozdrin CPU Architecture:Any
Tags: qc, regression

[18 Apr 2010 3:25] Peter Brawley
Description:
After upgrading from 5.5.2 to 5.5.3 on our LAN PC that serves as our 5.5 testbed, all _other_ machines on the LAN, running both *Nix and Windows, were refused connection to the machine running 5.5 ...

mysql -hMACHINE_NAME -uUSR -pPWD
mysql -hMACHINE_IPADDRESS -uUSR -pPWD

with the message "Can't get hostname for your address"

until we added ...

skip-name-resolve

to my.ini on the machine running 5.5.3. 

There are several problems with this: 

1. Our fix is a hack. It works in our case only because all mysql.user.host values in that installation box are '%'.

2. It is counter-intuitive, to say the least, that a server parameter called skip-name-resolve fixes connection via IP address!

3. In general, it's impossible to find documentation on "Can't get hostname for your address" in the manual (unfortunately there's a rather long list of issues on which the manual is silent). The manual needs (i) coverage of this error and (ii) a better explanation of how the server deals with hostnames than simply naming the obscure C function which the server calls for the purpose.

How to repeat:
As above

Suggested fix:
As above
[21 Apr 2010 7:22] Sveta Smirnova
Thank you for the report.

Verified as described.

Grants used:

grant all on *.* to bug52923@'192.168.0.%';
[12 May 2010 14:26] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/108155

3038 Alexander Nozdrin	2010-05-12
      Fix for Bug#52923 (Inadequate documentation of "Can't get hostname for your address" error).
      
      The thing is that on some platforms (e.g. Mac OS X) sockaddr_in / sockaddr_in6
      contain a non-standard field (sin_len / sin6_len), that must be set.
      
      The problem was that only standard fields were set, thus getnameinfo() returned
      EAI_SYSTEM instead of EAI_NONAME.
      
      The fix is to introduce configure-time checks (for GNU auto-tools and CMake) for
      those additional fields and to set them if they are available.
[21 May 2010 13:26] Alexander Nozdrin
Pushed into trunk-bugfixing.
[21 May 2010 14:48] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/108880

3054 Alexander Nozdrin	2010-05-21
      Fix for Bug#52923 (Inadequate documentation of "Can't get hostname for your address" error).
      
      The thing is that on some platforms (e.g. Mac OS X) sockaddr_in / sockaddr_in6
      contain a non-standard field (sin_len / sin6_len), that must be set.
      
      The problem was that only standard fields were set, thus getnameinfo() returned
      EAI_SYSTEM instead of EAI_NONAME.
      
      The fix is to introduce configure-time checks (for GNU auto-tools and CMake) for
      those additional fields and to set them if they are available.
[26 May 2010 9:50] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/109245
[26 May 2010 11:14] Jon Stephens
Also pushed to NDB-7.0.15/7.1.4 (per Magnus email).
[1 Jun 2010 10:32] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/109690

3403 Horst.Hunger	2010-06-01
      Patch for bug#52923 including the review results.
[1 Jun 2010 10:46] Horst Hunger
Forget the patch committed by Horst Hunger. It is for bug#52913. As you see a typo is the reason why it was put into this bug report. sorry.
[14 Jun 2010 10:57] Tor Didriksen
This fails to build, non-deterministically, on windows.
We *sometimes* get
-- Performing Test HAVE_SOCKADDR_IN_SIN_LEN
-- Performing Test HAVE_SOCKADDR_IN_SIN_LEN - Failed
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_LEN
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_LEN - Success

since the cmake macro CHECK_STRUCT_HAS_MEMBER sometimes, mistakenly,
returns success, the build fails:

6>.\viosocket.c(1086) : error C2039: 'sin6_len' : is not a member of 'sockaddr_in6'
6>        C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\ws2ipdef.h(156) : see declaration of 'sockaddr_in6'
[15 Jun 2010 8:12] Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100615080459-smuswd9ooeywcxuc) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (merge vers: 5.1.47) (pib:16)
[15 Jun 2010 8:28] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100615080558-cw01bzdqr1bdmmec) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (pib:16)
[6 Jul 2010 21:27] gufo rosso
IDEM confirm this bug !
[7 Jul 2010 18:42] Paul DuBois
Noted in 5.5.5 changelog.

On some systems, such as Mac OS X, the sockaddr_in and sockaddr_in6
structures contain a non-standard field (sin_len / sin6_len) that
must be set but was not. This resulted in hostname lookup failure.
[1 Sep 2010 16:18] Peter Brawley
As of 5.5.5, this is not yet fixed.
[26 Oct 2010 1:48] Yasuaki Fukuda
As of 5.5.6, this is not fixed yet...
(It's Run it on FreeBSD8.1)
[27 Dec 2010 1:35] Tairone Soares de Souza
As of 5.5.8, this is not fixed yet...
[21 Feb 2011 6:18] Robert Gagnon
As of 5.5.9, this is not fixed yet...
[12 Mar 2011 6:28] Robert Gagnon
Rather than use skip-name-resolve I just added the computer name associated with the IP address I was connecting from to the %systemroot%\system32\drivers\etc\hosts file and this should work for anyone using a basic LAN setup where the computer names are in the same group/domain (viewable to each other).  For more complex networking setups you will first have to find out what IP and hostname you are presenting to MySQL (I used wireshark monitoring my MySQL listening port) and enter that instead of the machine name.  This will allow it to resolve the reverse-dns of your client.  Of course this assumes that access to the hosts file on the MySQL server is possible.
[13 Mar 2011 2:04] Peter Brawley
Getting MySQL to work in a standard networking environment should not require messing with the hosts file.

Why is this problem still unsolved?
[14 Mar 2011 14:19] Robert Gagnon
Agreed...my suggestion is not a 'fix' to the problem but a workaround until one is delivered.

I am curious as to why the bug history shows submissions of a fix into the product build (15-Jun-2010, 5.5.5) but it doesn't appear to either be adopted or be an actual fix.  5.5.5 was released 6-Jul-2010 with 4 more releases since.
[14 Mar 2011 16:55] Davi Arnaut
> I am curious as to why the bug history shows submissions of a fix into the product build

Because the original issue has been fixed. Yet you might get the same error message for various other reasons. Details are needed in order to diagnostic what is happening and to identify whether it is a internal or external problem.

Also, this is worth a read: http://dev.mysql.com/doc/refman/5.5/en/dns.html
[14 Mar 2011 17:14] Robert Gagnon
My take on the bug thread that the fix was not applicable to this bug but rather a different bug.  The original post to this bug seems to still apply (albeit no mention explictly of hostname resolve).  I had come across the page your link cites but again, it describes using skip-name-resolve - not a viable option if you want to still use names rather than IPs in the grants.  Using skip-name-resolve is a workaround, not a fix as it limits the feature set of MySQL and does not provide an alternate means of utilizing it.
[14 Mar 2011 17:18] Davi Arnaut
So, could you please provide details on what is happening in your setup? The IP address in your case has forward (name-to-address) and reverse (address-to-name) DNS entries that match each other?
[14 Mar 2011 17:23] Peter Brawley
>Because the original issue has been fixed. Yet you might get the same error 
>message for various other reasons. Details are needed in order to diagnostic
>what is happening and to identify whether it is a internal or external 
>problem. -- Robert Gagnon

Please review my original bug report on 18 Apr 2010. MySQL client behaviour described there is identical in 5.5.9.
[14 Mar 2011 18:07] Robert Gagnon
Aye, what he (Peter B.) said.
Only difference (and not applicable) is the fact that I use a client app (SQLYog) to connect versus the command line...same problem results.
[1 Apr 2011 11:03] Alexander Nozdrin
Okay, I just tried to reproduce the problem and failed.
Here is what I did.

I used two machines: duo and quad.
duo is running Windows 7 x64, mysql-5.5.11.
quad runs Ubuntu Linux 10.10 x86_64, mysql-5.5.11

I compiled and run the server 5.5.11 on duo (Windows).
I used the client on quad (Linux).

quad has IP address 192.168.1.2
duo has IP address 192.168.1.3

The server was started like this:
> mysqld.exe --defaults-file=C:\Users\Alik\Documents\MySQL\my.cnf --console

The client was started like this (few attempts):
> mysql -u root -h 192.168.1.3
> mysql -u root -h duo

Then I created user 'u1' and checked it works too
(it actually doesn't matter, but anyway):
> mysql -u root -h duo
# CREATE DATABASE db1;
# CREATE DATABASE db2;
# GRANT SELECT ON db1.* TO u1@quad;

> mysql -u u1 -h duo db1
--> OK

> mysql -u u1 -h duo db2
ERROR 1044 (42000): Access denied for user 'u1'@'quad' to database 'db2'

The server uses the following my.cnf:
-----------------------------------------------------------------
[mysql]
prompt              = '[\d]> '

[client]
port                = 3306

[mysqld]
server_id           = 1
port                = 3306

max_allowed_packet  = 20000000

language            = C:/Users/Alik/Documents/MySQL/mysql-5.5.11/00.bin/sql/share

character-sets-dir  = C:/Users/Alik/Documents/MySQL/mysql-5.5.11/sql/share/charsets
basedir             = C:/Users/Alik/Documents/MySQL/mysql-5.5.11
datadir             = C:/Users/Alik/Documents/MySQL/var-5.5.11

skip-stack-trace
-----------------------------------------------------------------

The client uses the following my.cnf (located in $HOME):
-----------------------------------------------------------------
[mysql]
prompt              = '[\d]> '

[client]
port                = 3306
socket              = /home/alik/MySQL/var/mysql-5.5/mysqld.socket
-----------------------------------------------------------------

If you still experience this bug, please provide *all* the information,
which I have listed, i.e.:
  - config files for the client & server 
  - your LAN configuration (host names, IP addresses, platforms)
  - the way the client and the server are started

Thank you.
[1 Apr 2011 13:58] Peter Brawley
Version: 5.5.9 32-bit Win
~~~~~~~

OS: Win XP SP2
~~

Computer Management "Path to executable" for MySQL Service:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Server start: "C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld" --defaults-file="C:\Program Files\MySQL\MySQL Server 5.5\my.ini" MySQL

C:\Program Files\MySQL\MySQL Server 5.5\my.ini:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[client]
port=3306

[mysql]
prompt=\h.\d>\n
default-character-set=utf8

[mysqld]

port=3306
federated

# 2010-04-17: FIX 5.5 "CAN'T GET HOSTNAME" ERROR 
skip-name-resolve

basedir="C:/Program Files/MySQL/MySQL Server 5.5/"
datadir="C:/Documents and Settings/All Users/Application Data/MySQL/MySQL Server 5.5/Data/"
performance_schema=1
character_set_server=utf8

# Auto default as of 5.5.5
# default-storage-engine=INNODB

max_connections=100
query_cache_size=15M
table_cache=256
tmp_table_size=17M
thread_cache_size=8

myisam_max_sort_file_size=100G
myisam_sort_buffer_size=34M
key_buffer_size=23M
read_buffer_size=64K
read_rnd_buffer_size=256K
sort_buffer_size=256K
innodb_data_home_dir="C:/MySQL Datafiles/"

innodb_additional_mem_pool_size=2M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=1M
innodb_buffer_pool_size=200M
innodb_log_file_size=10M
innodb_thread_concurrency=8

Problem occurs on access from:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Win32 MySQL 6.0.7 installation on Win32 XP SP2 on the LAN
Win32 MySQL 5.1.91 installation on Win2000 SP3 installation on the LAN
MySQL 5.0.77 installation on Ubuntu on the LAN
[1 Apr 2011 14:00] Davi Arnaut
Also, do you see any information in the server error log? Something along the lines of "IP address 'xxx.xxx.xxx.xxx' could not be resolved: ...."
[1 Apr 2011 14:18] Peter Brawley
100414 12:37:27 [Warning] IP address '192.168.0.106' could not be resolved: getnameinfo() returned error (code: 11004).

100901 11:17:27 [Warning] IP address '192.168.0.106' could not be resolved: getnameinfo() returned error (code: 11004).

100901 11:19:58 [Warning] IP address '192.168.0.105' could not be resolved: getnameinfo() returned error (code: 11004).

110308 20:05:48 [Warning] IP address '192.168.1.3' could not be resolved: getnameinfo() returned error (code: 11004).

Once I restore skip-name-resolve to my.ini, the errors no longer occur.
[1 Apr 2011 14:36] Davi Arnaut
Hum, code 11004 is WSANO_DATA. Quoting from Windows sockets error codes: "The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for."

So, there seems to be some misconfiguration associated with these hosts. Anyway, perhaps the server should just use the ip address in the presence of failures to resolve hostnames.
[1 Apr 2011 14:54] Peter Brawley
> there seems to be some misconfiguration associated with these hosts.

If so, the only manifestation we can find is the MySQL 5.5 failure to recognise its callers. What other manifestations could we look for?
[1 Apr 2011 15:17] Robert Gagnon
My take on it is that gethostname is now being used (portability with IPv6) rather than the old gethostbyaddr (deprecated).

Found this post which helps explains why my suggestion on 12-Mar works...
http://www.experts-exchange.com/Programming/System/Windows__Programming/Q_20398429.html
...which mentions that the gethostname function does not support netbios where the deprecated gethostbyaddr did.

So setting up DNS service on our LAN's would fix the issue just as well as making an entry in the HOSTS file but implies that all existing users that are upgrading from the old 5.1 (or whatever the exact version gethostname was integrated) will experience this issue and have to either:
- change the HOSTS file on all workstations - unrealistic and more likely not permitted on a corporate network
- have DNS service implemented for the internal network - not very difficult but the point is that you are asking your customers to change network architecture to be able to upgrade their software.

To me an better solution which should not take much coding or subsequent regression testing (since it was used in earlier versions) would be to try gethostbyaddr first trapping any error code (to handle it finally being deprecated out of implementation in the Winsock) and use getnameinfo as a fallback.  There is negligible delay in both of these function calls so performance should not be degraded with the initial gethostbyaddr call either.
[5 Apr 2011 14:29] Alexander Nozdrin
A new bug has been filed to fix that follow-up problem.
[8 Apr 2011 11:00] Alexander Nozdrin
A fix for the follow-up problem has been pushed.
It should be in the next 5.5 version (5.5.12).
[13 Sep 2011 0:14] MySQL Verification Team
http://bugs.mysql.com/bug.php?id=62419 marked as duplicate of this one.
[13 Sep 2011 0:24] Don Cohen
1. why does the server need to get the host name at all?
2. even if it has some use (putting it in the log), why is failure to get it
   reason to refuse the connection?
3. it would be nice if the error message (and manual) had some explanation
[13 Sep 2011 0:52] Peter Brawley
Despite ...

> [8 Apr 13:00] Alexander Nozdrin
> A fix for the follow-up problem has been pushed.
> It should be in the next 5.5 version (5.5.12).

As of 5.6.2, this bug in basic MySQl functionality, a year and a half after it was first reported, is still NOT fixed. Why?
[20 Sep 2011 16:48] Alexander Nozdrin
Don,

the server needs client's host name to do security checks.

If you don't need that, you can start the server with --skip-name-resolve.
[20 Sep 2011 16:54] Alexander Nozdrin
Peter,

I thought, the fix resolved your problem.

If not, I suggest you file a support request.

The configuration you posted works in our lab.
The patch was tested on Windows XP SP3 + latest updates.
You indicated that your machine is Windows XP SP2 -- may be
this is the reason.
[20 Sep 2011 17:18] Peter Brawley
There are serious, well documented reasons for avoiding SP3. The issue is not fixed for XP SP2. That's a bug.