IPv6 support

[brianmay]

Hello,

Please can fanout listen on IPv6 sockets? Currently it only seems to listen for IPv4 connections.

Thanks

[travisghansen]

@brianmay when I get a free moment I'll see what it takes. It certainly needs to be added.

[travisghansen]

@brianmay can you test out SHA: a3db15f with your setup? It should work with both ipv4 and ipv6 clients.

[brianmay]

Hello,

Yes, it works fine. For me anyway. I am happy :-).

Unfortunately, there may be two problems with this solution, as currently written:

• Will break on machines without any kernel level IPv4 support.
• As far as I can tell, with just a quick glance, it assumes that the system has net.ipv6.bindv6only set to 0. This behaviour is depreciated and for backwards compatibility only. With net.ipv6.bindv6only set to 1, I think fanout will only listen on IPv6 and not IPv4.

The easiest solution for the second problem would be to call setsockopt and change the IPV6_V6ONLY value, presumable to 0. That way you get the desired behaviour even if the system default is changed. A more "proper" solution would require two sockets, one for IPv4 connections, and one for IPv6 connections.

Thanks

Brian

[travisghansen]

@brianmay I'm not familiar enough to understand why ipv4 support is (or would be necessary) necessary. I'm not aware of any code that would require it. As for item 2 I don't see how that's an issue either. As far as I can tell we currently have the best of all worlds, ipv6 is standard and ipv4 is left to the server admin to decide outside of the scope of fanout itself.

If anything, the only 'issue' at this point I can see is not having the option to not use ipv6 which I don't personally see as an issue. Perhaps I've misunderstood something though...

[jtrott]

On a CentOS 5 machine with no IPv6 support, running fanout gives me this:

ERROR: ERROR opening socket: Address family not supported by protocol

Going to download the older version and try that now.

[brianmay]

@travisghansen As you are creating and binding on a AF_INET6 socket, you have to have IPv6 support. Under Linux it won't work unless the compiled kernel has the ipv6 option turned on (and the resultant module, if any, loaded). I wish I could say I am surprised that CentOS 5 doesn't have this enabled - ipv6 has been around for years and years - unfortunately I am not surprised.

Unfortunately, most networks still only have ipv4 support, so ipv4 support is still required. In general, it is not possible to connect to an ipv6 only server from an ipv4 only client.

If you want I might be able to create a patch that fixes these issues, depends on my available time however.

[jtrott]

Older version seems to work, a bit crashy though but /etc/inittab takes care of that :)

[brianmay]

All issues should be fixed in #2. I copied from the example in http://www.akkadia.org/drepper/userapi-ipv6.html, except for a small change in how it binds to both IPv6 and IPv4 (getaddrinfo is suppose to sort IPv6 addresses first, but on my test machine doesn't).

It appears to work fine, although there might be unforeseen conditions were it doesn't crash. :-)

[travisghansen]

@brianmay Awesome work! I'll test it out and we'll see how it goes. To be clear on my previous code...I understand that the server must have ipv6 (which I assumed was pretty standard for quite a while now) but you could connect with ipv4 only clients fine. What you've done is clearly better though!

[jtrott]

All good, runs fine on systems with no IPv6 support now.

[brianmay]

@travisghansen Unfortunately, it seems, IPv6 isn't always available on servers. Partly due to distributions that have been slow to adopt it, and partly due to some people disabling it (sometimes for silly reasons). Also, any system that has net.ipv6.bindv6only set (current recommended practise, setting it to 0 is a bit of a kludge), the server will only work on IPv6. My code should work fine however.

[brianmay]

Am closing this, I think it has been well and truly resolved now :-).

[travisghansen]

I moved the production server to this over the weekend and the cpu ended up pegged I think due to this error in dmesg

IPv6 addrconf: prefix with wrong length 48

I've added the following to sysctl to see if it resolves the issue...

http://visei.com/2011/10/solving-ipv6-addrconf-prefix-with-wrong-length-48-permanently/

I'm also slightly worried about using the getsocketpeername function since I'm ignorant at C. Is using that function causing a memory leak?

[brianmay]

Just to clear up a bit of possible confusion, getsocketpeername() is defined in fanout.c, and it uses getpeername() and getnameinfo() to work. It uses ipstr, which is a globally defined variable, and as such does not dynamically allocate memory. So no, shouldn't cause any memory leaks. It will overwrite the previous result each time it is run however.

Trying to understand the source of these messages here. Does the network your production server is on support IPv6? I think perhaps the messages are just a warning, just actually an error. Still, that doesn't explain why your CPU would be pegged. Would be interested to know if the sysctl changes resolve the cpu load issues or not.

[travisghansen]

@brianmay ok, that's what I figured on getsocketpeer name but wasn't sure.

The server does support ipv6 and is listening on both ipv4 and ipv6 per netstat. I'm pretty sure the 'error' message is pretty useless but we just hung again (this time the cpu was not pegged) so I'm not sure what's going on. I removed those calls to getsocketpeername for now and we'll see how it reacts.

[brianmay]

As far as I can tell, the "IPv6 addrconf: prefix with wrong length 48" seems to be because your server is receiving IPv6 router advertisements for a /48 prefix. I think autoconf was only designed to work with /64. If you do have a /48 prefix, it might be better to do the configuration manually and disable autoconf.

[travisghansen]

Got a pegged cpu again :( I'm going to run it in gdb to see if I can get any useful info.

[brianmay]

strace might also help too.

[travisghansen]

@brianmay can you ping me in the sparkleshare irc channel?

[brianmay]

Sorry about the delay, was busy the last several days. I am on the sparkleshare irc channel now (I think), however I am the only one here....

[brianmay]

Also note I am in the UTC+10 timezone.

[brianmay]

Oops. I see I stuffed up joining the IRC channel, and somehow ended up on the wrong server. What is your IRC name?

[travisghansen]

@brianmay I'm thansen on gimpnet and freenode. I'll be on pretty sparse the next couple days, but if you catch me in there just let me know. Thanks!

[brianmay]

Unfortunately, email might be better. My schedule tends to be unpredictable. Where you still having problems with high CPU usage?

[travisghansen]

@brianmay yeah I'm running my ipv6 specific code on live right now because the generic code goes 100%