Python socket library confused by IPV6 notation in /etc/host

[esr]

BPO	1603527
Nosy	@loewis
Files	g.c c.py

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2006-12-18.10:12:58.000>
created_at = <Date 2006-11-27.05:43:39.000>
labels = ['library']
title = 'Python socket library confused by IPV6 notation in /etc/host'
updated_at = <Date 2006-12-18.10:12:58.000>
user = 'https://bugs.python.org/esr'

bugs.python.org fields:

activity = <Date 2006-12-18.10:12:58.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2006-11-27.05:43:39.000>
creator = 'esr'
dependencies = []
files = ['2241', '2242']
hgrepos = []
issue_num = 1603527
keywords = []
message_count = 9.0
messages = ['30686', '30687', '30688', '30689', '30690', '30691', '30692', '30693', '30694']
nosy_count = 4.0
nosy_names = ['loewis', 'esr', 'exarkun', 'rjbsourceforge']
pr_nums = []
priority = 'normal'
resolution = 'works for me'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1603527'
versions = ['Python 2.4']

[esr]

Robert J.Berger <rberger@ibd.com> reported this on the gpsd-dev mailing list of the GPSD project.

"Until I changed the line in /etc/hosts from:

::1 localhost.localdomain localhost

to:

127.0.0.1 localhost.localdomain localhost

the gps.py [library distributed by the GPSD project] would fail when trying to open the socket connection to gpsd:

File "/usr/local/bin/spGps.py", line 198, in __init__
self.connect(host, port)
File "/usr/local/bin/spGps.py", line 237, in connect
raise socket.error, msg
socket.error: (111, 'Connection refused')

This is with Python 2.4.4 under Red Hat Linux, kernel version not reported.

Robert believes, and I concur, that this is not a GPSD bug. Rather, something lower-level -- possibly the Python socket library, possibly some C library it uses -- is having indigestion on the IPV6 notation.

[esr]

Berger reports the kernel is 2.6.18. Fedora Core 6.

[loewis]

Can you please report the values of "host" and "port" when that error is raised?

[esr]

host is 'localhost'
port is 2947

What's going on here is that gps.py is a Python client module for a local daemon that monitors GPS devices on the host's serial and USB ports and presents output on port 2947. While it is possible to use gps.py to monitor a remote host, Berger wasn't doing that. The socket module threw an error while attempting to connect to localhost.

[exarkun]

This seems to work fine for me:

>>> s = socket.socket(socket.AF_INET6)
>>> s.bind(('ip6-localhost', 8091))
>>> s.getsockname()
('::1', 8091, 0, 0)
>>> 

exarkun@charm:$ grep ip6-localhost /etc/hosts
::1 ip6-localhost ip6-loopback
exarkun@charm:$

Are you sure this isn't a local misconfiguration? Perhaps gpsd isn't listening on ::1, only 127.1?

[esr]

Are you sure this isn't a local misconfiguration?

I'm not. I didn't see it happen. I suggest you email Mr. Berger and ask him.

[rjbsourceforge]

I will try to get a simple example that reproduces it. Unfortunately I don't have access to the system that was doing it today. I will try to get something in the bug report in the next day or so.

But basically if /etc/hosts had localhost defined as ::1 the connect method failded, when I set localhost to 127.0.0.1 the connect worked.

Other non-python (c++) processes were able to access the socket when localhost was set to ::1

This was on Fedora Core 6 with the latest patches at that time.

[loewis]

I believe this is a local configuration error, and possibly a C library error.

I'll attach two programs: g.c does what I believe gpsd does, and c.py
does what I believe spGps.py does.

This works fine on my system after I change localhost to be ::1 in /etc/hosts,
even though g.c only listens on IPv4 interfaces. On my system, it "works" because
libc (getaddrinfo) then goes to DNS, and my DNS server has an entry for localhost.

If C programs work on the machine, it may be because they use gethostbyname,
not getaddrinfo.

Closing as "works for me".
File Added: g.c

[loewis]

File Added: c.py