wicd, dhcpcd and ipv6 oh my! [solved]

[b0nafide]

Some years ago I decided to live on the bleeding edge and setup an ipv6 tunnel. All is well and continues to be well with my wired clients using dhcpcd and regular init scripts (interfaces receive ipv4 and ipv6 as they should). But just a few months ago, my netbook's wicd stopped working after an update.

I didn't think much of it at the time because I rarely used wireless and it was trivial to bypass just by bringing up networks manually. But I've just installed gentoo onto another laptop and ran into the same problem. I like wicd, so I dug into the logs and searched around online and found that what was probably happening was dhcpcd was forking into the background after getting the ipv6 portion of the request and breaking wicd.

dhcpcd has nice options like 'waitip' and 'timeout n' but unfortunately they do not help in this case.
wicd helpfully allows you to specify a dhcp client program, but oddly using pump doesn't seem to work either!

I have verified that after clicking 'connect' in wicd I only receive an ipv6 address, but running dhcpcd manually results in both ipv4 and ipv6 addresses.

Is it time for networkmanager?

[b0nafide]

Well, for the moment I've disabled wicd and emerged nm-applet after scaling back the overall number of dependencies. networkmanager works as I would expect it to in a mixed ipv4 and ipv6 network (I get both addresses).

[miket]

I may be speaking out of turn since 1. I don't have any wireless devices on my network and 2. most of the machines on my network have static IPv4 assignments.

BUT--I get dandy results with IPv6 Stateless Autoconfiguration. I don't have anything fancy to make my IPv6 interfaces listen for router advertisements: it just works. Like you, I get IPv6 through a tunnel.

Did you ever try specifying noipv6rs in your dhcpcd.conf? This would let you proceed with IPv4 DHCP (and get whatever goodies you need like the nameserver address, time-server address, and the MTU) but let the stateless autoconfiguration that is already implemented in the kernel handle the IPv6 side. In the world of tunnelling, I kind of doubt that you'd want to get name or time service through the tunnel, so there shouldn't be much harm in using IPv4 for these. (A name server you reach by IPv4 will still tell you about IPv6 addresses.)

My guess is that this would work even if you are getting IPv6 over wireless. I've never tried it, but that's my guess.

Let me leave you with a mind-blowing thought: some day we'll see IPv6-only 802.11.