GNU bug report logs - #18914
2.0.11 REPL server listens on 127.0.0.1 but not "localhost"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18914 in the body.
You can then email your comments to 18914 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: taylanbayirli <at> gmail.com ("Taylan Ulrich Bayırlı/Kammer")
To: bug-guile <at> gnu.org
Subject: 2.0.11 REPL server listens on 127.0.0.1 but not "localhost"
Date: Thu, 30 Oct 2014 14:52:36 +0100

After starting 'guile --listen', I can connect to it via 127.0.0.1 but
not "localhost": "Ncat: Connection refused."  I don't know if
listening on "localhost" by default has any security implications?


Shell 1:

tub <at> taylan:~$ guile --listen
GNU Guile 2.0.11
Copyright (C) 1995-2014 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)>


Shell 2:

tub <at> taylan:~$ ncat localhost 37146
Ncat: Connection refused.
tub <at> taylan:~$ ncat 127.0.0.1 37146
GNU Guile 2.0.11
Copyright (C) 1995-2014 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)>


Taylan

Message #8 received at 18914 <at> debbugs.gnu.org (full text, mbox):

From: <dsmich <at> roadrunner.com>
To: 18914 <at> debbugs.gnu.org, 
 Taylan Ulrich	Bayırlı/Kammer <taylanbayirli <at> gmail.com>
Subject: Re: bug#18914: 2.0.11 REPL server listens on 127.0.0.1 but not
 "localhost"
Date: Fri, 31 Oct 2014 18:33:53 -0400

---- "Taylan Ulrich
	Bayırlı/Kammer" <taylanbayirli <at> gmail.com> wrote: 
> After starting 'guile --listen', I can connect to it via 127.0.0.1 but
> not "localhost": "Ncat: Connection refused."  I don't know if
> listening on "localhost" by default has any security implications?

I wonder, could localhost be resolving to your ethernet IP address?  Or maybe resolving to an IPv6 address?

What does /etc/hosts say?

-Dale

Message #11 received at 18914 <at> debbugs.gnu.org (full text, mbox):

From: taylanbayirli <at> gmail.com (Taylan Ulrich Bayırlı/Kammer)
To: <dsmich <at> roadrunner.com>
Cc: 18914 <at> debbugs.gnu.org
Subject: Re: bug#18914: 2.0.11 REPL server listens on 127.0.0.1 but not
 "localhost"
Date: Fri, 31 Oct 2014 23:49:16 +0100

<dsmich <at> roadrunner.com> writes:

> I wonder, could localhost be resolving to your ethernet IP address?
> Or maybe resolving to an IPv6 address?

tub <at> taylan:~$ nslookup localhost
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	localhost
Address: 127.0.0.1

tub <at> taylan:~$

The local DNS server is dnsmasq.

> What does /etc/hosts say?

tub <at> taylan:~$ cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	taylan.uni.cx   taylan

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
tub <at> taylan:~$

This is on Debian and I don't remember manually mucking with the file.

Were you not able to reproduce the bug?

Taylan

Message #14 received at 18914 <at> debbugs.gnu.org (full text, mbox):

From: <dsmich <at> roadrunner.com>
To: Taylan Ulrich Bayırlı/Kammer
 <taylanbayirli <at> gmail.com>
Cc: 18914 <at> debbugs.gnu.org
Subject: Re: bug#18914: 2.0.11 REPL server listens on 127.0.0.1 but not
 "localhost"
Date: Sat, 1 Nov 2014 16:56:35 -0400

---- "Taylan Ulrich Bayırlı/Kammer" <taylanbayirli <at> gmail.com> wrote: 
> <dsmich <at> roadrunner.com> writes:

> > What does /etc/hosts say?
> 
> tub <at> taylan:~$ cat /etc/hosts
> 127.0.0.1	localhost
> 127.0.1.1	taylan.uni.cx   taylan
> 
> # The following lines are desirable for IPv6 capable hosts
> ::1     localhost ip6-localhost ip6-loopback
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> tub <at> taylan:~$
> 
> This is on Debian and I don't remember manually mucking with the file.
> 
> Were you not able to reproduce the bug?

Seems to work fine on master

dsmith <at> stumpy:~$ ncat localhost 37146
GNU Guile 2.1.0.1583-7dba1
Copyright (C) 1995-2014 Free Software Foundation, Inc.
...


Maybe try strace, possibly limiting it with -e connect, to reveal what it's actually doing.

-Dale

Message #17 received at 18914 <at> debbugs.gnu.org (full text, mbox):

From: taylanbayirli <at> gmail.com (Taylan Ulrich Bayırlı/Kammer)
To: <dsmich <at> roadrunner.com>
Cc: 18914 <at> debbugs.gnu.org
Subject: Re: bug#18914: 2.0.11 REPL server listens on 127.0.0.1 but not
 "localhost"
Date: Sun, 02 Nov 2014 14:23:41 +0100

<dsmich <at> roadrunner.com> writes:

> Seems to work fine on master

I just built from the master branch to be sure and can still reproduce.

> Maybe try strace, possibly limiting it with -e connect, to reveal what
> it's actually doing.

Not sure what I should be looking for, but there is no connect() call,
no occurrence of "localhost" in the whole output, but the following
snippet at some point:

...
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 8
fcntl(8, F_GETFL)                       = 0x2 (flags O_RDWR)
lseek(8, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(8, {sa_family=AF_INET, sin_port=htons(37146), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
mmap(NULL, 8720384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f35aaf81000
mprotect(0x7f35aaf81000, 4096, PROT_NONE) = 0
clone(child_stack=0x7f35ab7d0ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f35ab7d19d0, tls=0x7f35ab7d1700, child_tidptr=0x7f35ab7d19d0) = 2099
futex(0x7fffd27a33fc, FUTEX_WAIT_PRIVATE, 1, NULL) = 0
...

which is also the sole occurrence of '127.0.0.1'.  Seems to come from
`make-tcp-server-socket' in module/system/repl/server.scm where it
passes INADDR_LOOPBACK, an integer whose value is 127.0.0.1 as a uint32,
to bind().  I don't know at what point it's normally supposed to make
the association with "localhost".

Any further help in how to debug this is appreciated.  I have little
knowledge of the POSIX networking API.

Taylan

Message #20 received at 18914 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: taylanbayirli <at> gmail.com (Taylan Ulrich "Bayırlı/Kammer")
Cc: 18914 <at> debbugs.gnu.org, dsmich <at> roadrunner.com
Subject: Re: bug#18914: 2.0.11 REPL server listens on 127.0.0.1 but not
 "localhost"
Date: Wed, 22 Jun 2016 10:32:06 +0200

Hi,

Works for me, with Guile 2.0.11 also.  Could it be that "nc" is trying
to connect to an IPv6 address?

Andy

On Sun 02 Nov 2014 14:23, taylanbayirli <at> gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> <dsmich <at> roadrunner.com> writes:
>
>> Seems to work fine on master
>
> I just built from the master branch to be sure and can still reproduce.
>
>> Maybe try strace, possibly limiting it with -e connect, to reveal what
>> it's actually doing.
>
> Not sure what I should be looking for, but there is no connect() call,
> no occurrence of "localhost" in the whole output, but the following
> snippet at some point:
>
> ...
> socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 8
> fcntl(8, F_GETFL)                       = 0x2 (flags O_RDWR)
> lseek(8, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
> setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> bind(8, {sa_family=AF_INET, sin_port=htons(37146), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> mmap(NULL, 8720384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f35aaf81000
> mprotect(0x7f35aaf81000, 4096, PROT_NONE) = 0
> clone(child_stack=0x7f35ab7d0ff0,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
> parent_tidptr=0x7f35ab7d19d0, tls=0x7f35ab7d1700,
> child_tidptr=0x7f35ab7d19d0) = 2099
> futex(0x7fffd27a33fc, FUTEX_WAIT_PRIVATE, 1, NULL) = 0
> ...
>
> which is also the sole occurrence of '127.0.0.1'.  Seems to come from
> `make-tcp-server-socket' in module/system/repl/server.scm where it
> passes INADDR_LOOPBACK, an integer whose value is 127.0.0.1 as a uint32,
> to bind().  I don't know at what point it's normally supposed to make
> the association with "localhost".
>
> Any further help in how to debug this is appreciated.  I have little
> knowledge of the POSIX networking API.
>
> Taylan

Message #23 received at 18914 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: taylanbayirli <at> gmail.com (Taylan Ulrich "Bayırlı/Kammer")
Cc: 18914 <at> debbugs.gnu.org, dsmich <at> roadrunner.com
Subject: Re: bug#18914: 2.0.11 REPL server listens on 127.0.0.1 but not
 "localhost"
Date: Tue, 12 Jul 2016 09:17:44 +0200

On Wed 22 Jun 2016 10:32, Andy Wingo <wingo <at> pobox.com> writes:

> Works for me, with Guile 2.0.11 also.  Could it be that "nc" is trying
> to connect to an IPv6 address?

Pretty sure that's what's going on here.  When Guile makes server
sockets, it assumes it should listen on a single family/address/port
triple.  Specifically for INADDR_LOOPBACK that's going to be IPv4
127.0.0.1 and not IPv6 at all.  Probably we should use getaddrinfo if
the user supplies a "host", and use that to plumb through a list of
addresses on which to bind (and/or connect).

Andy

Message #28 received at 18914-done <at> debbugs.gnu.org (full text, mbox):

From: Taylan Kammer <taylan.kammer <at> gmail.com>
To: 18914-done <at> debbugs.gnu.org
Subject: 2.0.11 REPL server listens on 127.0.0.1 but not "localhost"
Date: Mon, 17 May 2021 22:43:41 +0200

I don't have access to the exact system anymore since it's been more than
6 years, but on a Debian with the exact same /etc/hosts I can't reproduce
the issue anymore.  Since I was apparently the only one who could repro it
in the first place, I'm closing it now. :-)

Andy wrote:
> Could it be that "nc" is trying to connect to an IPv6 address?

Maybe that was the case on that system for some reason, despite the IPv4
address being on top in /etc/hosts and nslookup giving 127.0.0.1.

Maybe it was even a bug with the ncat I had installed, who knows.

-- 
Taylan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.