classification
Title: socket.getaddrinfo fails for hostname that is all digits 0-9
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: ariel, ariel-wikimedia, neologix, r.david.murray
Priority: normal Keywords:

Created on 2014-01-28 12:43 by ariel-wikimedia, last changed 2014-01-29 18:05 by neologix. This issue is now closed.

Messages (5)
msg209539 - (view) Author: (ariel-wikimedia) Date: 2014-01-28 12:43
With python 2.7.5 (running on fedora 20 with all updates), socket.getaddrinfo for a hostname such as 836937931829 will fail.  Docker produces these sorts of hostnames (really random hex strings, but some hex strings only contain digits 0-9).

How to reproduce:

Add the lines

172.17.10.53    blobber
172.17.10.54    836937931829

to /etc/hosts

run the following:

import socket
print socket.getaddrinfo('172.17.10.53',80,socket.AF_INET,0,socket.SOL_TCP)
print socket.getaddrinfo('blobber',80,socket.AF_INET,0,socket.SOL_TCP)
print socket.getaddrinfo('172.17.10.54',80,socket.AF_INET,0,socket.SOL_TCP)
print socket.getaddrinfo('836937931829',80,socket.AF_INET,0,socket.SOL_TCP)

Expected output:
[(2, 1, 6, '', ('172.17.10.53', 80))]
[(2, 1, 6, '', ('172.17.10.53', 80))]
[(2, 1, 6, '', ('172.17.10.54', 80))]
[(2, 1, 6, '', ('172.17.10.54', 80))]

Actual output:
[(2, 1, 6, '', ('172.17.10.53', 80))]
[(2, 1, 6, '', ('172.17.10.53', 80))]
[(2, 1, 6, '', ('172.17.10.54', 80))]
Traceback (most recent call last):
  File "./test-getaddrinfo.py", line 6, in <module>
    print socket.getaddrinfo('836937931829',80,socket.AF_INET,0,socket.SOL_TCP)
socket.gaierror: [Errno -2] Name or service not known
msg209568 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-01-28 17:36
getaddrinfo is a thin wrapper around the system call.  Have you tried the same thing in a C program and had it work?

My guess would be that the all-numeric 'hostname' is being treated as the integer form of an IP address.  I can't immediately find any documentation that addresses this for getaddrinfo, but the impression I get from googling is that turning numbers into ip addresses is not specified behavior but is what (most?) libc implementations do.
msg209572 - (view) Author: Ariel Glenn (ariel) Date: 2014-01-28 18:32
Yes, I had checked that just in case; getaddrinfo(3) works for the all-digit hostname, returning no error.  I'm using these hints:

   memset(&hints, 0, sizeof(struct addrinfo));
   hints.ai_family = AF_UNSPEC;
   hints.ai_socktype = SOCK_STREAM;
   hints.ai_flags = AI_PASSIVE;
   hints.ai_protocol = 0;
   hints.ai_canonname = NULL;
   hints.ai_addr = NULL;
   hints.ai_next = NULL;

Tested on glibc-2.18.
msg209593 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2014-01-28 21:52
The culprint isn't Python, but the libc:
"""
$ ./python  -c "import socket; print(socket.getaddrinfo('836937931829', 80, socket.AF_INET, 0, socket.SOL_TCP))"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
socket.gaierror: [Errno -2] Name or service not known
"""

But with AF_UNSPEC:
"""
$ ./python  -c "import socket; print(socket.getaddrinfo('836937931829', 80, socket.AF_UNSPEC, 0, socket.SOL_TCP))"
[(2, 1, 6, '', ('172.17.10.54', 80))]
"""

And gdb confirms that the arguments are correctly passed to the libc:
"""
$ gdb --args ./python  -c "import socket; print(socket.getaddrinfo('836937931829', 80, socket.AF_INET, 0, socket.SOL_TCP))"
Breakpoint 1, __GI_getaddrinfo (name=0xb7cc9c84 "836937931829", service=0xbffff24e "80", hints=0xbffff278, pai=0xbffff274) at ../sysdeps/posix/getaddrinfo.c:2379
(gdb) p *hints
$4 = {ai_flags = 0, ai_family = 2, ai_socktype = 0, ai_protocol = 6, ai_addrlen = 0, ai_addr = 0x0, ai_canonname = 0x0, ai_next = 0x0}
"""

You can also check directly with getaddrinfo(3).
msg209623 - (view) Author: Ariel Glenn (ariel) Date: 2014-01-29 08:02
Verified that with AF_INET instead of AF_UNSPEC I get the error from my c program.  I'll take this to the glibc folks and see what's up. Thanks.
History
Date User Action Args
2014-01-29 18:05:05neologixsetstatus: open -> closed
resolution: not a bug
stage: resolved
2014-01-29 08:02:46arielsetmessages: + msg209623
2014-01-28 21:52:04neologixsetnosy: + neologix
messages: + msg209593
2014-01-28 18:32:13arielsetnosy: + ariel
messages: + msg209572
2014-01-28 17:36:18r.david.murraysetnosy: + r.david.murray
messages: + msg209568
2014-01-28 12:43:06ariel-wikimediacreate