DHCPv6 *still* broken for F17 alpha
tcallawa at redhat.com
Fri Mar 2 15:47:57 UTC 2012
On 03/01/2012 12:48 PM, Thomas Woerner wrote:
> On 03/01/2012 04:52 PM, 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?
> There will be a dhcpv6 service entry for firewalld soon and later on
> also for system-config-firewall.
> Where how and when it will and could be enabled will be evaluated.
As a temporary fix until the more "complete" service entry can be added,
I propose this patch. Anaconda invokes:
/usr/sbin/lokkit --quiet --nostart -f
This writes out the "default" firewall, where everything is locked down,
except for the hardcoded rules in system-config-firewall
(ESTABLISHED,RELATED, lo, ipv6-icmp). I simply added the dhcpv6 accept
to those hardcoded rules.
The obvious downside to this approach is that dhcpv6 connections will
always be explicitly accepted in generated ip6tables from the
system-config-firewall tools, for all network devices, and users that
want to change that will need to manually edit /etc/sysconfig/ip6tables.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 755 bytes
Desc: not available
More information about the devel