DHCPv6 *still* broken for F17 alpha
dcbw at redhat.com
Thu Mar 1 16:57:36 UTC 2012
On Thu, 2012-03-01 at 10:52 -0500, Paul Wouters wrote:
> On Thu, 1 Mar 2012, Dan Williams wrote:
> > On Wed, 2012-02-29 at 17:20 +0100, Tore Anderson wrote:
> >> * Jerry James
> >>> Interesting. I'm seeing kind of the inverse problem:
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=771130. Could that be
> >>> related to the issues discussed in this thread?
> >> Hard to tell, without (preferably debug-level) logs. I have the same
> >> problem you're describing occur in 0.9.2-1 (see bug #797524), but I've
> >> not seen it with 0.9.3-0.2.git20120215.
> > 0.9.4 snapshots do not require both methods to complete (with either
> > success or failure) before saying the machine is connected. Thus if
> > IPv4 completes first, NM will say it's connected, and continue IPv6 in
> > the background. And vice versa.
> But that does not yet address the dhcpv6 ip6tables ACCEPT rule that is
> missing right?
No, it doesn't; I was hoping the DHCPv6 rule would simply be added to
the default firewall config like the DHCPv4 rule is, rather than have NM
open up the port every time. In an ideal world, each service requiring
ports would ask the firewall itself, but the ISC DHCP client is pretty
slow-moving and not too receptive of platform-specific changes like
that. So if we don't get a default firewall rule for DHCPv6 then I
guess NM would have to do it manually.
What I was referring to was NM < 0.9.4 waiting for IPv6 to time out when
it already had an IPv4 address, which led to long delays in connectivity
where the user's network was not IPv6 enabled, but since we want to use
IPv6 if we have it, NM was waiting for it. That's fixed in 0.9.4.
(0.9.3 is the development version that will become 0.9.4).
More information about the devel