MySQL Bugs: #52923: Inadequate documentation of "Can't get hostname for your address" error

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

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

Thank you for the report.

Verified as described.

Grants used:

grant all on *.* to bug52923@'192.168.0.%';

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.

Pushed into trunk-bugfixing.

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.

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

Also pushed to NDB-7.0.15/7.1.4 (per Magnus email).

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.

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.

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'

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)

Pushed into mysql-next-mr (revid:alik@sun.com-20100615080558-cw01bzdqr1bdmmec) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (pib:16)

IDEM confirm this bug !

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.

As of 5.5.5, this is not yet fixed.

As of 5.5.6, this is not fixed yet...
(It's Run it on FreeBSD8.1)

As of 5.5.8, this is not fixed yet...

As of 5.5.9, this is not fixed yet...

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.

Getting MySQL to work in a standard networking environment should not require messing with the hosts file.

Why is this problem still unsolved?

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.

> 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

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.

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?

>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.

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.

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.

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

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: ...."

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.

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.

> 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?

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.

A new bug has been filed to fix that follow-up problem.

A fix for the follow-up problem has been pushed.
It should be in the next 5.5 version (5.5.12).

http://bugs.mysql.com/bug.php?id=62419 marked as duplicate of this one.

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

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?

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.

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.

There are serious, well documented reasons for avoiding SP3. The issue is not fixed for XP SP2. That's a bug.