[PATCH] standalone trac does not support IPv6

[sgala@…]

(error is: socket.gaierror: (-9, "Address family for hostname not supported")

The way sockets are initialized is wrong. trac (or the underlying wsgi code for python 2.4) is assuming socket.AF_INET before even knowing the server address.

Standard code for initializing a ipv6 aware socket, that will work in ipv4-only machines (see U. Drepper tutorial) is:

>>> import socket
>>> gais = socket.getaddrinfo("::",8000, socket.AF_UNSPEC, socket.SOCK_STREAM) # host, port, af, tcp, ... 
>>> for gai in gais:
...   try:
...     sock = socket.socket(*gai[:2])
...     sock.bind(gai[4])
...     break
...   except:
...     continue
... else:
...   sock = None
...   raise "Error, couldn't bind"

or something similar. This code should work on any python having getaddrinfo, which means anything modern enough. In fact this code will try to bind in any different possibilities given.

None means localhost in the most general way (127.0.0.1 or ::1); "::" or "0.0.0.0" means any ipv6/ipv4 or any ipv4 address. For concrete addresses, getaddrinfo will parse and take care of the socket parameters.

[anonymous]

someone should change this ticket to "tracd doesn't support IPv6" -b "::" doesn't ring a bell for most people… BTW this ticket is still valid for trac 0.11

[Christian Boos]

As we discussed r7915 on #irc, I came across this ticket and played around…

[Christian Boos]

When I start tracd with -b ::1 -p 8000, it seems I can successfully browser my Trac environment using ​http://[::1]:8000/devel

But then trying to connect ​http://127.0.0.1:8000/devel fails.

[Christian Boos]

attempts to listen on both ipv4 and ipv6 addresses

[Christian Boos]

​PythonBug:3213 and ​http://mail.python.org/pipermail/python-list/2008-May/489377.html were helpful here.

So with the second patch​ (which has to be applied in addition to the first), and starting tracd with -b :: -p 8000, I was able to connect to both ​http://[::1]:8000/devel and ​http://127.0.0.1:8000/devel (on Windows Vista).

As expected the second request shows up as a mapped ipv4 address:

::ffff:127.0.0.1 Trac[...

[Christian Boos]

Milestone 1.0 deleted

[Thijs Triemstra <lists@…>]

Seems to me this patch needs a review, I'll check it out.

[Thijs Triemstra <lists@…>]

#2491 is another ipv6 issue.

[Thijs Triemstra]

Updated the patch which works fine for http://[::1]:8000/test2:

$ tracd --port=8000 --hostname=::1 .
Server starting in PID 14348.
Serving on http://::1:8000/
Using HTTP/1.1 protocol version
::1 - - [30/Jan/2011 14:51:07] "GET /test2/wiki HTTP/1.1" 200 -
::1 - - [30/Jan/2011 14:51:07] "GET /test2/chrome/common/css/trac.css HTTP/1.1" 304 -
::1 - - [30/Jan/2011 14:51:07] "GET /test2/chrome/common/css/wiki.css HTTP/1.1" 304 -
::1 - - [30/Jan/2011 14:51:07] "GET /test2/chrome/common/js/jquery.js HTTP/1.1" 304 -
::1 - - [30/Jan/2011 14:51:08] "GET /test2/wiki HTTP/1.1" 200 -
::1 - - [30/Jan/2011 14:51:08] "GET /test2/chrome/common/css/trac.css HTTP/1.1" 304 -

but im not able to access it through http://127.0.0.1:8000.

[Thijs Triemstra]

against trunk r10501

[Thijs Triemstra]

Replying to thijstriemstra:

but im not able to access it through http://127.0.0.1:8000.

There was an issue with the patch, added a new one, and it runs fine on both now (ubuntu 10.10).

[Thijs Triemstra]

Uploading files and modifying wiki pages, as described in #2491, also works fine with this patch.

[Remy Blank]

I don't have a way of testing the patch, but if it works for you, I will apply it.

[Thijs Triemstra]

noticed that my patch forgot the url to the mailinglist post:

# in case Python doesn't know about the flags... ref.
# http://mail.python.org/pipermail/python-list/2008-May/489377.html

[Remy Blank]

Oh, sorry Christian, I hadn't noticed that those patches were yours.

[Christian Boos]

Well, yes, I wrote that a while ago, but it was more to get a bit familiar with this API than a real need from my side to support IPv6. Also, I didn't test the patch besides trying with the IPv6 loopback interface on my Windows box…

Thijs or Remy, if you were able to test the patch in some real conditions (IPv6 URLs anyone?), and if it works fine for you, then sure we can commit it.

[Remy Blank]

I don't have an IPv6 setup, so unfortunately I can't test the patch. But I have a few comments on it anyway:

• On my (Linux) box, socket.IPV6_V6ONLY is 26, not 27.
• It feels strange to have to hardcode those numbers. Couldn't we just try to import them, and not support IPv6 if they aren't found? There's also the socket.has_ipv6 flag that could be used to detect if IPv6 support is available.
• If we don't bind the socket to a specific IP address, will tracd work through IPv4 and IPv6 at the same time?

[Christian Boos]

Replying to rblank:

I don't have an IPv6 setup, so unfortunately I can't test the patch. But I have a few comments on it anyway:

• On my (Linux) box, socket.IPV6_V6ONLY is 26, not 27.

Right, that seems to be platform dependent.

• It feels strange to have to hardcode those numbers. Couldn't we just try to import them, and not support IPv6 if they aren't found? There's also the socket.has_ipv6 flag that could be used to detect if IPv6 support is available.

Python 2.5 on Windows socket.has_ipv6 is True, yet socket.IPV6_V6ONLY is not defined. We can play it safe and refuse to support IPV6 if that constant is not defined, even if by hardcoding the correct value we could make it work. It depends on how "critical" it is to support this feature for older versions of Python, which I suppose is "not at all critical" ;-)

• If we don't bind the socket to a specific IP address, will tracd work through IPv4 and IPv6 at the same time?

You mean, if the address is empty, we should do the same as if ::1 was specified, and we should activate IPv6 support? Why not, yes.

ipv6-5820.patch

@@ -271 @@
-    if ':' in options.hostname: 
+    if not options.hostname or ':' in options.hostname:

[anonymous]

Instead of trying to guess the value of IPV6_IPV6ONLY the patch could put the reference to those inside the try: block, and capture any error and pass if the machines doesn't know about this option.

Linux has IPV6_IPV6ONLY to 0 by default, and I think this is also true in most OSes. Windows has it enabled, so only windows needs this block. The failure to set the option will only result in the socket listening only on IPv6, not too bad if the host requested contains ":"…

[Remy Blank]

Preparing for 1.0.

[Ryan J Ollos]

Moved ticket assigned to next-stable-1.0.x since maintenance of 1.0.x is coming to a close. Please move the ticket back if it's critical to fix on 1.0.x.

[Ryan J Ollos]

Milestone renamed