[gnutls-devel] gnutls-cli-debug failing with IPv6-only hosts?

[Daniel Kahn Gillmor]

i have a server listening only on the IPv6 loopback (not on IPv4). (This
is with GnuTLS 3.1.6)

/etc/hosts has these two lines in it:

127.0.0.1 localhost
::1       localhost


In this situation, if i try to connect on "localhost", gnutls-cli-debug
fails with a misleading error message, while "::1" works fine.

0 dkg at alice:~$ gnutls-cli-debug -p 9932 localhost
Resolving 'localhost'...
Connecting to '::1:9932'...
connect: Connection refused
1 dkg at alice:~$ gnutls-cli-debug -p 9932 ::1
Resolving '::1'...
Connecting to '::1:9932'...
Checking for SSL 3.0 support... yes
[...]


if i run "strace gnutls-cli-debug -p 9932 localhost", then i can see
that it's actually trying to connect on IPv4 as well as IPv6, even
though it doesn't report that on stdout:

0 dkg at alice:~$ strace gnutls-cli-debug -p 9932 localhost
execve("/usr/bin/gnutls-cli-debug", ["gnutls-cli-debug", "-p", "9932", "localhost"], [/* 40 vars */]) = 0
brk(0)                                  = 0x2424000
[...]
write(1, "Connecting to '::1:9932'...\n", 28Connecting to '::1:9932'...
) = 28
connect(4, {sa_family=AF_INET6, sin6_port=htons(9932), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 5
connect(5, {sa_family=AF_INET6, sin6_port=htons(9932), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(9932), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)
close(6)                                = 0
dup(2)                                  = 6
fcntl(6, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(6, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 11), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f65c428d000
lseek(6, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(6, "connect: Connection refused\n", 28connect: Connection refused
) = 28
close(6)                                = 0
munmap(0x7f65c428d000, 4096)            = 0
exit_group(1)                           = ?
1 dkg at alice:~$ 



And attempts to increase verbosity don't help explain that it's trying
to connect via IPv4 and failing too:

1 dkg at alice:~$ gnutls-cli-debug -p 9932 localhost -VVVVVVVVVVVV
Resolving 'localhost'...
Connecting to '::1:9932'...
connect: Connection refused
1 dkg at alice:~$ 

Looking at it with ltrace, i see the following:

connect(4, 0xb9ace0, 28, 0x409d4c, 5)                                                                                                      = 0
socket(10, 1, 6)                                                                                                                           = 5
getnameinfo(0x00b9ad40, 28, "::1", 4096, NULL, 0, 1)                                                                                       = 0
connect(5, 0xb9ad40, 28, 0, 0xfefefefefefefeff)                                                                                            = 0
socket(2, 1, 6)                                                                                                                            = 6
getnameinfo(0x00b9ac90, 16, "::1", 4096, NULL, 0, 1)                                                                                       = 0
connect(6, 0xb9ac90, 16, 0, 0xfefefefefefefeff)                                                                                            = -1
close(6)                                                                                                                                   = 0
perror("connect"connect: Connection refused
)                                                                                                                          = <void>
+++ exited (status 1) +++
0 dkg at alice:~$ 


I think that IPv6 addrinfo's are 28 bytes long, but IPv4 are 16 bytes.

This makes me think that there's a bug in getnameinfo, that it could be
passed an AF_INET IPv4 address with the NI_NUMERICHOST, and still have
it respond "::1", even though an IPv4 address clearly shouldn't be
mapped to a name of "::1".

This is happening around line 268 of src/cli-debug.c, fwiw.

Any ideas?  Should i take this up with libc folks instead?

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 965 bytes
Desc: not available
URL: </pipermail/attachments/20130129/73b24baa/attachment.pgp>