Skip Menu |

This queue is for tickets about the Net-Server CPAN distribution.

Report information
The Basics
Id: 78024
Status: resolved
Priority: 0/
Queue: Net-Server
People
Owner: Nobody in particular
Requestors: DKG [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in:
  • 2.000
  • 2.001
  • 2.002
  • 2.003
  • 2.004
  • 2.005
  • 2.006
Fixed in: (no value)

History Show all quoted text
  Mon Jun 25 02:37:43 2012 DKG [...] cpan.org - Ticket created
Subject: binding to port 0 to multi-address hostnames results in different ports on each address
Since Net::Server 2.00, the package has done the right thing when binding is requested on a named host that resolves to multiple IP addresses: it binds to each associated IP address. Another nice, relatively recent change is support of passing port 0, to bind to an arbitrary port. Unfortunately, these two nice features don't play well together. On an IPv4/IPv6 machine, binding to "localhost" with port 0 makes it so the port bound on 127.0.0.1 is different from the port bound on ::1. For example: 0 dkg@pip:~$ perl -e 'use base qw(Net::Server); main->run(host => "localhost", port => 0)' 2012/06/25-02:32:01 main (type Net::Server) starting! pid(7338) Resolved [localhost]:0 to [::1]:0, IPv6 Resolved [localhost]:0 to [127.0.0.1]:0, IPv4 Binding to TCP port 0 on host ::1 with IPv6 Bound to auto-assigned port 49245 Binding to TCP port 0 on host 127.0.0.1 with IPv4 Bound to auto-assigned port 45191 Group Not Defined. Defaulting to EGID '1000 4 20 24 25 27 29 44 46 107 109 110 115 126 1000' User Not Defined. Defaulting to EUID '1000' This is a bit surprising, since "localhost:45191" works to reach the server via IPv4 but not IPv6, and "localhost:49245" works to reach the server via IPv6 but not IPv4. Perhaps once an auto-assigned port is successfully chosen, it could be used in place of port 0 on all subsequently-bound addresses? This runs the risk that some of the addresses are already in use, of course, but the same risk exists when using explicit (non-0) port requests on multi-address hostnames. Maybe there are other possible solutions?
  Mon Jun 25 08:29:07 2012 Paul Seamons - Correspondence added
Subject: Re: [rt.cpan.org #78024] binding to port 0 to multi-address hostnames results in different ports on each address
Date: Mon, 25 Jun 2012 06:28:45 -0600
To: bug-Net-Server [...] rt.cpan.org
From: Paul Seamons <paul [...] seamons.com>
You are absolutely right. This will need to be fixed. I am out of town this week, but next week I'll release a version that fixes the behavior. Any IPv4/IPv6 pair (such as 0.0.0.0/::) that were defined because of ipv => * and that were using a randomly assigned port should absolutely be the same port. At the moment, this likely mostly affects the bsd's since their bindv6only status is defaulted to 1 whereas linux is defaulted to 0 - meaning that for the majority of default 0 cases there would've only been one port handling both ipv4/ipv6. However, it would also greatly affect any host where the hostname pointed to multiple ips. Thank you for pointing this out, and I'll get patch in place. Essentially we'll have to remember the generated pairing and at time of binding map the randomly assigned port to the other part of the pair (or all hosts in cases where the name resolved to multiple ip addresses). Paul On 06/25/2012 12:37 AM, Daniel Kahn Gillmor via RT wrote: Show quoted text
> Mon Jun 25 02:37:43 2012: Request 78024 was acted upon. > Transaction: Ticket created by DKG > Queue: Net-Server > Subject: binding to port 0 to multi-address hostnames results in different > ports on each address > Broken in: 2.000, 2.001, 2.002, 2.003, 2.004, 2.005, 2.006 > Severity: (no value) > Owner: Nobody > Requestors: DKG@cpan.org > Status: new > Ticket<URL: https://rt.cpan.org/Ticket/Display.html?id=78024> > > > Since Net::Server 2.00, the package has done the right thing when > binding is requested on a named host that resolves to multiple IP > addresses: it binds to each associated IP address. > > Another nice, relatively recent change is support of passing port 0, to > bind to an arbitrary port. > > Unfortunately, these two nice features don't play well together. > > On an IPv4/IPv6 machine, binding to "localhost" with port 0 makes it so > the port bound on 127.0.0.1 is different from the port bound on ::1. > > For example: > > 0 dkg@pip:~$ perl -e 'use base qw(Net::Server); main->run(host => > "localhost", port => 0)' > 2012/06/25-02:32:01 main (type Net::Server) starting! pid(7338) > Resolved [localhost]:0 to [::1]:0, IPv6 > Resolved [localhost]:0 to [127.0.0.1]:0, IPv4 > Binding to TCP port 0 on host ::1 with IPv6 > Bound to auto-assigned port 49245 > Binding to TCP port 0 on host 127.0.0.1 with IPv4 > Bound to auto-assigned port 45191 > Group Not Defined. Defaulting to EGID '1000 4 20 24 25 27 29 44 46 107 > 109 110 115 126 1000' > User Not Defined. Defaulting to EUID '1000' > > This is a bit surprising, since "localhost:45191" works to reach the > server via IPv4 but not IPv6, and "localhost:49245" works to reach the > server via IPv6 but not IPv4. > > Perhaps once an auto-assigned port is successfully chosen, it could be > used in place of port 0 on all subsequently-bound addresses? > > This runs the risk that some of the addresses are already in use, of > course, but the same risk exists when using explicit (non-0) port > requests on multi-address hostnames. > > Maybe there are other possible solutions? >
  Mon Jun 25 08:29:09 2012 The RT System itself - Status changed from 'new' to 'open'
  Thu Jan 10 02:54:45 2013 paul [...] seamons.com - Correspondence added
I attacked this several different ways before i found a clean solution that works with multiple port 0's and hupping. But it is fixed in 2.007
  Thu Jan 10 02:54:46 2013 paul [...] seamons.com - Status changed from 'open' to 'resolved'