Le Sam 17 mars 2012 00:51, Glen Turner a écrit :
On 2012-03-15 Dan Williams wrote:
The only effect this checking will have is to change NetworkManager's
state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL. It
doesn't do anything odd like disconnect and retry some other
Le Lun 19 mars 2012 10:17, Nicolas Mailhot a écrit :
Le Sam 17 mars 2012 00:51, Glen Turner a écrit :
On 2012-03-15 Dan Williams wrote:
The only effect this checking will have is to change NetworkManager's
state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL. It
doesn't do
* Dan Williams
On Wed, 2012-03-14 at 20:47 +0100, Lars Seipel wrote:
The current behaviour of tearing down working IPv6 connections is
just painful IMHO.
If the IPv6 method is ignore (which is the current default) then NM
shouldn't be touching IPv6 stuff on that interface; kernel-assigned
Hi Dan,
* Dan Williams
On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote:
That is true, however, if IPv6 completes first, and IPv4 (still running
in the background) eventually ends up failing, the *entire connection*
will be torn down - including the perfectly working IPv6
* Petr Pisar
How does fd00::/16 differes from 10.0.0.0/8? Why getting site scope
address in IPv4 is Ok, while getting such address in IPv6 is considered
as failure?
Just a little comment regarding the terminology used here. The terms
global, site, and link scope have very specific and defined
On 2012-03-15 Dan Williams wrote:
The only effect this checking will have is to change NetworkManager's
state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL. It
doesn't do anything odd like disconnect and retry some other
connection,
which wouldn't make much sense. It just
On 2012-03-14, Dan Williams d...@redhat.com wrote:
On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote:
* Dan Williams
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
On Wed, 2012-03-14 at 20:47 +0100, Lars Seipel wrote:
On Wednesday 14 March 2012 13:36:06 Dan Williams wrote:
Whether we care enough about this regression (if you want to call it
that) versus enabling default IPv6 connectivity I don't know, I tend to
think we suck up the regression.
On Thu, 2012-03-15 at 10:07 +, Petr Pisar wrote:
On 2012-03-14, Dan Williams d...@redhat.com wrote:
On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote:
* Dan Williams
0.9.4 snapshots do not require both methods to complete (with either
success or failure) before saying the
On Thu, 15 Mar 2012, Dan Williams wrote:
The current connectivity checking code is built-but-inactive in F17, you
can enable it by adding these entries
to /etc/NetworkManager/NetworkManager.conf:
[connectivity]
uri=http://url
interval=120
the URL is expected to return one or both of:
1) an
On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote:
* Dan Williams
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
On Wednesday 14 March 2012 13:36:06 Dan Williams wrote:
Whether we care enough about this regression (if you want to call it
that) versus enabling default IPv6 connectivity I don't know, I tend to
think we suck up the regression.
Please do. The current behaviour of tearing down working IPv6
On 03/02/2012 11:31 PM, Tore Anderson wrote:
* Tom Callaway
On 03/02/2012 04:39 PM, Tore Anderson wrote:
This one *most likely* works (it assumes /sbin/dhclient in Fedora will
*always* use a link-local source address when building a DHCPv6 request.
I believe that is the case, but I have not
* Dan Williams
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.
That is true, however, if IPv6
Hi,
* Adam Williamson
If there's a bug against this, it could be nominated as a Beta or Final
blocker.
Here's a few:
https://bugzilla.redhat.com/show_bug.cgi?id=538499
https://bugzilla.redhat.com/show_bug.cgi?id=552099
https://bugzilla.redhat.com/show_bug.cgi?id=591630
* Tom Callaway
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
On 03/02/2012 03:59 PM, Tore Anderson wrote:
* Tom Callaway
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
On Fri, 2012-03-02 at 15:22 +0100, Tore Anderson wrote:
Looking forward, we might at some point want to explicitly 'support'
IPv6 in the release criteria, by specifying that 'connect to the
network' means all permutations of IPv4 / IPv6 networks should work...
Yes please. Besides, you
* Tom Callaway
I know less than nothing about DHCPv6. I used the rule offered earlier
in the thread by Paul Wouters. If there is a more appropriate ruleset,
please tell me what it is and I'll regenerate the patch.
This one will certainly work (it's the patch attached bug #591630):
ip6tables
* Adam Williamson
Yes please. Besides, you promised as much in the F12 release notes...
I'm _pretty_ sure I didn't write those. =)
I meant «you» as in «The Fedora Project». ;-)
--
Tore Anderson
--
devel mailing list
devel@lists.fedoraproject.org
On 03/02/2012 04:39 PM, Tore Anderson wrote:
This one *most likely* works (it assumes /sbin/dhclient in Fedora will
*always* use a link-local source address when building a DHCPv6 request.
I believe that is the case, but I have not reviewed its source code to
verify):
ip6tables -A INPUT -p
* Tom Callaway
On 03/02/2012 04:39 PM, Tore Anderson wrote:
This one *most likely* works (it assumes /sbin/dhclient in Fedora will
*always* use a link-local source address when building a DHCPv6 request.
I believe that is the case, but I have not reviewed its source code to
verify):
On 03/03/2012 03:11 AM, Tore Anderson wrote:
* Adam Williamson
Yes please. Besides, you promised as much in the F12 release notes...
I'm _pretty_ sure I didn't write those. =)
I meant «you» as in «The Fedora Project». ;-)
It's not a promise. Its a bug in the documentation. Happens
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)
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
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
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
On Thu, Mar 01, 2012 at 06:48:00PM +0100, 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:
On Thu, 2012-03-01 at 15:43 -0500, Chuck Anderson wrote:
On Thu, Mar 01, 2012 at 06:48:00PM +0100, 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
* Paul Wouters
Can we please address the following bug that is almsot two years old.
This bug causes long delays for people enabling IPV6, and causes
Fedora to not get any connectivity on IPv6 only networks, unless you
disable/reconfigure ip6tables manually
I find the fact that this bug is
On Wed, Feb 29, 2012 at 4:05 AM, Tore Anderson t...@fud.no wrote:
However, this is not the only problem related to IPv6. I just tested the
F17 Alpha Live CD, and one particular egregious issue is that by
default, the toggle «Require IPv4 addressing for this connection to
complete» is enabled
* 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
Can we please address the following bug that is almsot two years old.
This bug causes long delays for people enabling IPV6, and causes
Fedora to not get any connectivity on IPv6 only networks, unless you
disable/reconfigure ip6tables manually
https://bugzilla.redhat.com/show_bug.cgi?id=552099
On Mon, 2012-02-27 at 23:27 -0500, Paul Wouters wrote:
Can we please address the following bug that is almsot two years old.
This bug causes long delays for people enabling IPV6, and causes
Fedora to not get any connectivity on IPv6 only networks, unless you
disable/reconfigure ip6tables
34 matches
Mail list logo
