strange difference between localhost and 127.0.0.1 with a Zinc server on mac
Hi, I experiencing a strange difference between localhost and 127.0.0.1. In Pharo I do: (ZnServer startDefaultOn: 4444) onRequestRespond: [ :request | ZnResponse ok: (ZnEntity text: 'hello') ] In bash: $ lsof -Pi | grep Pharo Pharo 2718 luc 7u IPv4 0x1e64a2e9381f409b 0t0 TCP *:4444 (LISTEN) I perfectly listen on port 4444 from all interfaces * $ curl http://127.0.0.1:4444 hello $ curl http://localhost:4444 curl: (7) Failed to connect to localhost port 4444: Connection refused *<- why ?* localhost is correctly resolved on my mac $ ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.044 ms I tested with other programs than Zinc to open listening sockets and it works. Any idea? #Luc
Canât reproduce (OSX 10.9.3). Both curl calls work perfectly for me. Maybe its your curl? Max On 13.06.2014, at 21:32, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
I experiencing a strange difference between localhost and 127.0.0.1.
In Pharo I do:
(ZnServer startDefaultOn: 4444) onRequestRespond: [ :request | ZnResponse ok: (ZnEntity text: 'hello') ]
In bash:
$ lsof -Pi | grep Pharo Pharo 2718 luc 7u IPv4 0x1e64a2e9381f409b 0t0 TCP *:4444 (LISTEN)
I perfectly listen on port 4444 from all interfaces *
$ curl http://127.0.0.1:4444 hello
$ curl http://localhost:4444 curl: (7) Failed to connect to localhost port 4444: Connection refused <- why ?
localhost is correctly resolved on my mac $ ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.044 ms
I tested with other programs than Zinc to open listening sockets and it works.
Any idea?
#Luc
2014-06-14 6:04 GMT+02:00 Ben Coman <btc@openinworld.com>:
Luc Fabresse wrote:
Hi,
I experiencing a strange difference between localhost and 127.0.0.1.
In Pharo I do:
(ZnServer startDefaultOn: 4444) onRequestRespond: [ :request | ZnResponse ok: (ZnEntity text: 'hello') ]
In bash:
$ lsof -Pi | grep Pharo Pharo 2718 luc 7u IPv4 0x1e64a2e9381f409b 0t0 TCP *:4444 (LISTEN)
I perfectly listen on port 4444 from all interfaces *
$ curl http://127.0.0.1:4444 hello
$ curl http://localhost:4444 curl: (7) Failed to connect to localhost port 4444: Connection refused *<- why ?*
localhost is correctly resolved on my mac $ ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.044 ms
I tested with other programs than Zinc to open listening sockets and it works.
Any idea?
#Luc
Humm, I use curl 7.36.0, so yes perhaps this bug fix is not integrated... Anyway, I was also suspecting curl but I tested with server: Apache on port 8888 and here curl works: httpd 621 luc 5u IPv6 0x6ea19c1d988f10db 0t0 TCP *:8888 <-- same as Zinc but both: curl http://127.0.0.1:8888 curl http://localhost:8888 are working. wget always works (Apache and Zinc): wget -qO- http://127.0.0.1:8888 wget -qO- http://localhost:8888 Thanks Max and Ben, Luc
2014-06-14 10:55 GMT+02:00 Ben Coman <btc@openinworld.com>:
Luc Fabresse wrote:
2014-06-14 6:04 GMT+02:00 Ben Coman <btc@openinworld.com>:
Luc Fabresse wrote:
Hi,
I experiencing a strange difference between localhost and 127.0.0.1.
In Pharo I do:
(ZnServer startDefaultOn: 4444) onRequestRespond: [ :request | ZnResponse ok: (ZnEntity text: 'hello') ]
In bash:
$ lsof -Pi | grep Pharo Pharo 2718 luc 7u IPv4 0x1e64a2e9381f409b 0t0 TCP *:4444 (LISTEN)
I perfectly listen on port 4444 from all interfaces *
$ curl http://127.0.0.1:4444 hello
$ curl http://localhost:4444 curl: (7) Failed to connect to localhost port 4444: Connection refused *<- why ?*
localhost is correctly resolved on my mac $ ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.044 ms
I tested with other programs than Zinc to open listening sockets and it works.
Any idea?
#Luc
Humm, I use curl 7.36.0, so yes perhaps this bug fix is not integrated...
Anyway, I was also suspecting curl but I tested with server: Apache on port 8888 and here curl works:
httpd 621 luc 5u IPv6 0x6ea19c1d988f10db 0t0 TCP *:8888 <-- same as Zinc
Yes. If the *:8888 means that Apache was listening on "all" IP addresses rather than just 127.0.0.1, then as you can see it was an IPv6 address that curl connected to.
ah right, I did not read the beginning of the line ;-) So now it is clearer. I conclude that it is a curl bug only for ipv4
btw, What do you get from `nslookup localhost` ?
$ nslookup localhost Server: 192.168.0.254 Address: 192.168.0.254#53 Name: localhost Address: 127.0.0.1
Anyway, the question then becomes... How well does Pharo / Zinc play with IPv6 ?
the Socket plugin supports some things but I do not remember now. Thx, Luc
cheers -ben
but both:
curl http://127.0.0.1:8888 curl http://localhost:8888
are working.
wget always works (Apache and Zinc):
wget -qO- http://127.0.0.1:8888 wget -qO- http://localhost:8888
Thanks Max and Ben,
Luc
Luc, I have seen this kind of weirdness before, but I mostly see it with ab (apache benchmark tool). I really have no idea. Have you tried with telnet to do a manual HTTP request ? $ telnet localhost 1701 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /random HTTP/1.1 Host:localhost:1701 HTTP/1.1 200 OK Content-Type: text/plain;charset=utf-8 Content-Length: 64 Date: Sat, 14 Jun 2014 08:58:48 GMT Server: Zinc HTTP Components 1.0 EF97C091498F3FEA3F79F65D36C40ECAFD116A68BA31F45D027DB61EBDD1579 ^] telnet> close Connection closed. You could also try using the same or a second Pharo image to do the request. $ ./pharo Pharo.image eval "ZnClient new get: 'http://localhost:8080/random'" '766EF4E6E5664EF4C5163D30125B5C35BFE2AED408835CB6D6206DF0A7A15FD ' In any case, the server socket used is normally listening on all interfaces [0.0.0.0] Sven On 14 Jun 2014, at 09:17, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2014-06-14 6:04 GMT+02:00 Ben Coman <btc@openinworld.com>: Luc Fabresse wrote:
Hi,
I experiencing a strange difference between localhost and 127.0.0.1.
In Pharo I do:
(ZnServer startDefaultOn: 4444) onRequestRespond: [ :request | ZnResponse ok: (ZnEntity text: 'hello') ]
In bash:
$ lsof -Pi | grep Pharo Pharo 2718 luc 7u IPv4 0x1e64a2e9381f409b 0t0 TCP *:4444 (LISTEN)
I perfectly listen on port 4444 from all interfaces *
$ curl http://127.0.0.1:4444 hello
$ curl http://localhost:4444 curl: (7) Failed to connect to localhost port 4444: Connection refused <- why ?
localhost is correctly resolved on my mac $ ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.044 ms
I tested with other programs than Zinc to open listening sockets and it works.
Any idea?
#Luc maybe http://sourceforge.net/p/curl/bugs/1337/
Humm, I use curl 7.36.0, so yes perhaps this bug fix is not integrated...
Anyway, I was also suspecting curl but I tested with server: Apache on port 8888 and here curl works:
httpd 621 luc 5u IPv6 0x6ea19c1d988f10db 0t0 TCP *:8888 <-- same as Zinc
but both:
curl http://127.0.0.1:8888 curl http://localhost:8888
are working.
wget always works (Apache and Zinc):
wget -qO- http://127.0.0.1:8888 wget -qO- http://localhost:8888
Thanks Max and Ben,
Luc
Hi Sven, $ telnet localhost 1701 works perfectly but I noticed that it first tries to connect to ::1 and then switch to 127.0.0.1 Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost but I suspected that curl does the same and do not fallback to 127.0.0.1 and yes this one works: curl --ipv4 http://localhost:1701 so by default my curl works on ipv6 I do not know why ::1 is before 127.0.0.1 on my mac 10.9.3. Is there a global option? in /etc/hosts 127.0.0.1 if first anyway, thanks problem solved and not related with Zinc ;-) Luc 2014-06-14 11:03 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:
Luc,
I have seen this kind of weirdness before, but I mostly see it with ab (apache benchmark tool). I really have no idea. Have you tried with telnet to do a manual HTTP request ?
$ telnet localhost 1701 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /random HTTP/1.1 Host:localhost:1701
HTTP/1.1 200 OK Content-Type: text/plain;charset=utf-8 Content-Length: 64 Date: Sat, 14 Jun 2014 08:58:48 GMT Server: Zinc HTTP Components 1.0
EF97C091498F3FEA3F79F65D36C40ECAFD116A68BA31F45D027DB61EBDD1579 ^] telnet> close Connection closed.
You could also try using the same or a second Pharo image to do the request.
$ ./pharo Pharo.image eval "ZnClient new get: ' http://localhost:8080/random'" '766EF4E6E5664EF4C5163D30125B5C35BFE2AED408835CB6D6206DF0A7A15FD '
In any case, the server socket used is normally listening on all interfaces [0.0.0.0]
Sven
On 14 Jun 2014, at 09:17, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2014-06-14 6:04 GMT+02:00 Ben Coman <btc@openinworld.com>: Luc Fabresse wrote:
Hi,
I experiencing a strange difference between localhost and 127.0.0.1.
In Pharo I do:
(ZnServer startDefaultOn: 4444) onRequestRespond: [ :request | ZnResponse ok: (ZnEntity text:
'hello') ]
In bash:
$ lsof -Pi | grep Pharo Pharo 2718 luc 7u IPv4 0x1e64a2e9381f409b 0t0 TCP *:4444
(LISTEN)
I perfectly listen on port 4444 from all interfaces *
$ curl http://127.0.0.1:4444 hello
$ curl http://localhost:4444 curl: (7) Failed to connect to localhost port 4444: Connection refused
<- why ?
localhost is correctly resolved on my mac $ ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.044 ms
I tested with other programs than Zinc to open listening sockets and it
works.
Any idea?
#Luc
maybe http://sourceforge.net/p/curl/bugs/1337/
Humm, I use curl 7.36.0, so yes perhaps this bug fix is not integrated...
Anyway, I was also suspecting curl but I tested with server: Apache on port 8888 and here curl works:
httpd 621 luc 5u IPv6 0x6ea19c1d988f10db 0t0 TCP *:8888 <-- same as Zinc
but both:
curl http://127.0.0.1:8888 curl http://localhost:8888
are working.
wget always works (Apache and Zinc):
wget -qO- http://127.0.0.1:8888 wget -qO- http://localhost:8888
Thanks Max and Ben,
Luc
I must admit that I haven't given the whole IPv6 issue much thought. It is good that you/users provide feedback, it is more an OS thing I think/hope. On 14 Jun 2014, at 11:37, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Sven,
$ telnet localhost 1701 works perfectly but I noticed that it first tries to connect to ::1 and then switch to 127.0.0.1
Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost
but I suspected that curl does the same and do not fallback to 127.0.0.1 and yes this one works:
curl --ipv4 http://localhost:1701
so by default my curl works on ipv6
I do not know why ::1 is before 127.0.0.1 on my mac 10.9.3. Is there a global option? in /etc/hosts 127.0.0.1 if first
anyway, thanks problem solved and not related with Zinc ;-)
Luc
2014-06-14 11:03 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>: Luc,
I have seen this kind of weirdness before, but I mostly see it with ab (apache benchmark tool). I really have no idea. Have you tried with telnet to do a manual HTTP request ?
$ telnet localhost 1701 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /random HTTP/1.1 Host:localhost:1701
HTTP/1.1 200 OK Content-Type: text/plain;charset=utf-8 Content-Length: 64 Date: Sat, 14 Jun 2014 08:58:48 GMT Server: Zinc HTTP Components 1.0
EF97C091498F3FEA3F79F65D36C40ECAFD116A68BA31F45D027DB61EBDD1579 ^] telnet> close Connection closed.
You could also try using the same or a second Pharo image to do the request.
$ ./pharo Pharo.image eval "ZnClient new get: 'http://localhost:8080/random'" '766EF4E6E5664EF4C5163D30125B5C35BFE2AED408835CB6D6206DF0A7A15FD '
In any case, the server socket used is normally listening on all interfaces [0.0.0.0]
Sven
On 14 Jun 2014, at 09:17, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2014-06-14 6:04 GMT+02:00 Ben Coman <btc@openinworld.com>: Luc Fabresse wrote:
Hi,
I experiencing a strange difference between localhost and 127.0.0.1.
In Pharo I do:
(ZnServer startDefaultOn: 4444) onRequestRespond: [ :request | ZnResponse ok: (ZnEntity text: 'hello') ]
In bash:
$ lsof -Pi | grep Pharo Pharo 2718 luc 7u IPv4 0x1e64a2e9381f409b 0t0 TCP *:4444 (LISTEN)
I perfectly listen on port 4444 from all interfaces *
$ curl http://127.0.0.1:4444 hello
$ curl http://localhost:4444 curl: (7) Failed to connect to localhost port 4444: Connection refused <- why ?
localhost is correctly resolved on my mac $ ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.044 ms
I tested with other programs than Zinc to open listening sockets and it works.
Any idea?
#Luc maybe http://sourceforge.net/p/curl/bugs/1337/
Humm, I use curl 7.36.0, so yes perhaps this bug fix is not integrated...
Anyway, I was also suspecting curl but I tested with server: Apache on port 8888 and here curl works:
httpd 621 luc 5u IPv6 0x6ea19c1d988f10db 0t0 TCP *:8888 <-- same as Zinc
but both:
curl http://127.0.0.1:8888 curl http://localhost:8888
are working.
wget always works (Apache and Zinc):
wget -qO- http://127.0.0.1:8888 wget -qO- http://localhost:8888
Thanks Max and Ben,
Luc
Sven Van Caekenberghe wrote:
In any case, the server socket used is normally listening on all interfaces [0.0.0.0]
Sven
Maybe it matters that [0.0.0.0] is the IPv4-Unspecified-Address and it might make a difference to use IPv6-Unspecified-Address [0:0:0:0:0:0:0:0] or [::] cheers -ben
On 14 Jun 2014, at 12:18, Ben Coman <btc@openInWorld.com> wrote:
Sven Van Caekenberghe wrote:
In any case, the server socket used is normally listening on all interfaces [0.0.0.0]
Sven
Maybe it matters that [0.0.0.0] is the IPv4-Unspecified-Address and it might make a difference to use IPv6-Unspecified-Address [0:0:0:0:0:0:0:0] or [::]
cheers -ben
I guess it all depends on the Socket plugin. ZnServer has #bindingAddress: which eventually calls Socket>>#listenOn:backlogSize:interface: but the question is, what is acceptable as last argument. And how is the difference between v4 and v6 handled. There is a 'primitives-ipv6' category, but no #listenOn with an interface there.
Hi Sven, On Sat, Jun 14, 2014 at 4:09 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Jun 2014, at 12:18, Ben Coman <btc@openInWorld.com> wrote:
Sven Van Caekenberghe wrote:
In any case, the server socket used is normally listening on all interfaces [0.0.0.0]
Sven
Maybe it matters that [0.0.0.0] is the IPv4-Unspecified-Address and it might make a difference to use IPv6-Unspecified-Address [0:0:0:0:0:0:0:0] or [::]
cheers -ben
I guess it all depends on the Socket plugin. ZnServer has #bindingAddress: which eventually calls Socket>>#listenOn:backlogSize:interface: but the question is, what is acceptable as last argument. And how is the difference between v4 and v6 handled. There is a 'primitives-ipv6' category, but no #listenOn with an interface there.
I wonder whether this commit is relevant: r2552 | eliot | 2012-05-02 16:13:02 -0700 (Wed, 02 May 2012) | 19 lines CogVM source as per VMMakerr.oscog-eem.159 ... Fix limitation in platforms/unix/plugins/SocketPlugin/sqUnixSocket.c which could cause NetNameResolver localHostAddress to answer 0 (if host has a set hostname not being honoured by local DNS servers). Fix falls back to localhost. ... Here's the relevant part of the platforms/unix/plugins/SocketPlugin/sqUnixSocket.c change: -sqInt sqResolverLocalAddress(void) { return nameToAddr(localHostName); } +sqInt sqResolverLocalAddress(void) +{ sqInt localaddr = nameToAddr(localHostName); + if (!localaddr) + localaddr = nameToAddr("localhost"); + return localaddr; +} This fixed several socket tests on my Mac OS box. I think it affects systems behind a broadband router, at least that's how it asffected me on my laptop at home. And here's what is probably the root cause in platforms/unix/plugins/SocketPlugin/sqUnixSocket.c: ... static char localHostName[MAXHOSTNAMELEN]; static u_long localHostAddress; /* GROSS IPv4 ASSUMPTION! */ ... /* start a new network session */ sqInt sqNetworkInit(sqInt resolverSemaIndex) { if (0 != thisNetSession) return 0; /* already initialised */ gethostname(localHostName, MAXHOSTNAMELEN); localHostAddress= nameToAddr(localHostName); thisNetSession= clock() + time(0); if (0 == thisNetSession) thisNetSession= 1; /* 0 => uninitialised */ resolverSema= resolverSemaIndex; return 0; } ... and so if gethostname answers something weird, attempts to access localHost are screwed from initialization on. HTH -- best, Eliot
Thanks for the explanation, Eliot. I am not sure there is a problem resolving localhost and binding to it, as the server did work in the case described, it was just not accessible by curl. I guess we might have to shake down some issue with ipv6 in the future, we'll see. On 14 Jun 2014, at 16:17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Sven,
On Sat, Jun 14, 2014 at 4:09 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Jun 2014, at 12:18, Ben Coman <btc@openInWorld.com> wrote:
Sven Van Caekenberghe wrote:
In any case, the server socket used is normally listening on all interfaces [0.0.0.0]
Sven
Maybe it matters that [0.0.0.0] is the IPv4-Unspecified-Address and it might make a difference to use IPv6-Unspecified-Address [0:0:0:0:0:0:0:0] or [::]
cheers -ben
I guess it all depends on the Socket plugin. ZnServer has #bindingAddress: which eventually calls Socket>>#listenOn:backlogSize:interface: but the question is, what is acceptable as last argument. And how is the difference between v4 and v6 handled. There is a 'primitives-ipv6' category, but no #listenOn with an interface there.
I wonder whether this commit is relevant:
r2552 | eliot | 2012-05-02 16:13:02 -0700 (Wed, 02 May 2012) | 19 lines
CogVM source as per VMMakerr.oscog-eem.159 ...
Fix limitation in platforms/unix/plugins/SocketPlugin/sqUnixSocket.c which could cause NetNameResolver localHostAddress to answer 0 (if host has a set hostname not being honoured by local DNS servers). Fix falls back to localhost. ...
Here's the relevant part of the platforms/unix/plugins/SocketPlugin/sqUnixSocket.c change:
-sqInt sqResolverLocalAddress(void) { return nameToAddr(localHostName); } +sqInt sqResolverLocalAddress(void) +{ sqInt localaddr = nameToAddr(localHostName); + if (!localaddr) + localaddr = nameToAddr("localhost"); + return localaddr; +}
This fixed several socket tests on my Mac OS box. I think it affects systems behind a broadband router, at least that's how it asffected me on my laptop at home. And here's what is probably the root cause in platforms/unix/plugins/SocketPlugin/sqUnixSocket.c:
... static char localHostName[MAXHOSTNAMELEN]; static u_long localHostAddress; /* GROSS IPv4 ASSUMPTION! */ ... /* start a new network session */
sqInt sqNetworkInit(sqInt resolverSemaIndex) { if (0 != thisNetSession) return 0; /* already initialised */ gethostname(localHostName, MAXHOSTNAMELEN); localHostAddress= nameToAddr(localHostName); thisNetSession= clock() + time(0); if (0 == thisNetSession) thisNetSession= 1; /* 0 => uninitialised */ resolverSema= resolverSemaIndex; return 0; } ... and so if gethostname answers something weird, attempts to access localHost are screwed from initialization on.
HTH -- best, Eliot
participants (5)
-
Ben Coman -
Eliot Miranda -
Luc Fabresse -
Max Leske -
Sven Van Caekenberghe