You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
rakudo tries to connect to feather.perl6.nl:3000 over IPv6, which doesn't work. When it doesn't work, it doesn't try IPv4; it just fails. If I specify the socket family:
IO::Socket::INET.new(:host<feather.perl6.nl>, :port(3000), :family(2)) # 2 is INET
...the family parameter is not respected. I've disabled IPv6 on the machine for the time being, but I figured that others might run into this situation.
It presumably hasn't been picked up earlier because no-one has tested on an IPV6 enabled network.
It appears that if the network connection has IPV6 and the host has an AAAA record then IO::Socket::INET will attempt to connect first to the V6 address despite the family default being unchanged from PIO::SOCK_INET, if this attempt fails to connect (in the case in the bug report above, the server isn't listening on V6,) then the IPV4 isn't tried and the connection fails.
I think that for least surprise it should probably only attempt to connect on the socket family request, however if the V6 behaviour is to stay it should attempt both V6 and V4 and only fail if it isn't able to create either connection.
I might add I am personally not able to test on V6 just passing on a triaged 3rd party report.
There's actually a much simpler test for this and this was noticed in the wild as an issue against CheckSocket.
If you you have an /etc/hosts that does something like:
127.0.0.1 localhost
::1 localhost
(Which seems to be perfectly valid - FreeBSD for instance will create a hosts file like this if it is configured for IPv6 as well as v4,)
And you have some code that does something like:
my $socket = IO::Socket::INET.new(localhost => 'localhost', localport => $port, listen => True);
loop {
my $client = $socket.accept;
}
Then:
IO::Socket::INET.new(host => '127.0.0.1', port => $port)
Will fail, as will swapping the numeric IP and name in the server and client. Because you can't either specify the address family to be used, nor determine from the server socket which family it has been bound with there is no way to work around this which is somewhat unfortunate.
I think this kind of thing is going to come up more often as people start making network applications.
Migrated from rt.perl.org#123282 (status was 'new')
Searchable as RT123282$
The text was updated successfully, but these errors were encountered: