I'm running rawhide and have 2 files in /etc/modprobe.d which are not owned by any package and both contain the line "install ipv6 /bin/true". The files are called disable-ipv6 and disable-ipv6-0 - with these files present the ipv6 module is never loaded and therefore IPv6 will never work, even when you explicitly configure the network to use IPv6 and have a router advertising itself.
This seems like a backwards step - it causes problems for those of us who use IPv6 networks in our day to day lives and doesn't exactly help promote the badly needed migration towards IPv6.
Is there a good reason for disabling IPv6 by default (it's worth noting that not only did previous releases of Fedora enable it by default, but so does Mac OS X and I believe Windows Vista)?
On Thursday 24 May 2007 15:34:36 Steve Hill wrote:
I'm running rawhide and have 2 files in /etc/modprobe.d which are not owned by any package and both contain the line "install ipv6 /bin/true". The files are called disable-ipv6 and disable-ipv6-0 - with these files present the ipv6 module is never loaded and therefore IPv6 will never work, even when you explicitly configure the network to use IPv6 and have a router advertising itself.
This seems like a backwards step - it causes problems for those of us who use IPv6 networks in our day to day lives and doesn't exactly help promote the badly needed migration towards IPv6.
Is there a good reason for disabling IPv6 by default (it's worth noting that not only did previous releases of Fedora enable it by default, but so does Mac OS X and I believe Windows Vista)?
During your install, did you enable IPV6?
On Thu, 2007-05-24 at 20:34 +0100, Steve Hill wrote:
I'm running rawhide and have 2 files in /etc/modprobe.d which are not owned by any package and both contain the line "install ipv6 /bin/true". The files are called disable-ipv6 and disable-ipv6-0 - with these files present the ipv6 module is never loaded and therefore IPv6 will never work, even when you explicitly configure the network to use IPv6 and have a router advertising itself.
This seems like a backwards step - it causes problems for those of us who use IPv6 networks in our day to day lives and doesn't exactly help promote the badly needed migration towards IPv6.
Is there a good reason for disabling IPv6 by default (it's worth noting that not only did previous releases of Fedora enable it by default, but so does Mac OS X and I believe Windows Vista)?
No good reason. There was a miscommunication about an initscripts change which led to it happening for test4. It should be fixed now though -- F7 installations shouldn't suffer the same problem.
On Thu, 24 May 2007, David Woodhouse wrote:
No good reason. There was a miscommunication about an initscripts change which led to it happening for test4. It should be fixed now though -- F7 installations shouldn't suffer the same problem.
Ok, thanks.
Of course it appears the iwl3945 driver seems to break IPv6 address autoconfiguration anyway (Bugzilla'd) so oh well :-/
On Thu, 24 May 2007, David Woodhouse wrote:
On Thu, 2007-05-24 at 20:54 +0100, Steve Hill wrote:
Of course it appears the iwl3945 driver seems to break IPv6 address autoconfiguration anyway (Bugzilla'd) so oh well :-/
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241281
Hm. All Ethernet multicast is buggered?
Hmm.. good question. I'm not sure how I can test that?
On Thu, 2007-05-24 at 21:55 +0100, Steve Hill wrote:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241281
Hm. All Ethernet multicast is buggered?
Hmm.. good question. I'm not sure how I can test that?
Use tcpdump on your machine and on some other machine on the network -- observe the packets you're missing.
Often, observe that when tcpdump puts the interface into promiscuous work it actually starts working because you suddenly _do_ receive the RA packets :)
On Thu, 24 May 2007, David Woodhouse wrote:
Use tcpdump on your machine and on some other machine on the network -- observe the packets you're missing.
Often, observe that when tcpdump puts the interface into promiscuous work it actually starts working because you suddenly _do_ receive the RA packets :)
No, I think the problem is that the NIC isn't filtering the transmitted packets from being received, so the IPv6 stack is seeing it's own packets and thinking something else is already using the same address. (This is kind of all conjecture though - I've not done any real debugging on the problem).
I noticed yesterday evening that eventually it does sometimes manage to assign itself an IPv6 address, but you have to wait a lonnng time for that to happen.
Steve Hill wrote:
On Thu, 24 May 2007, David Woodhouse wrote:
Use tcpdump on your machine and on some other machine on the network -- observe the packets you're missing.
Often, observe that when tcpdump puts the interface into promiscuous work it actually starts working because you suddenly _do_ receive the RA packets :)
No, I think the problem is that the NIC isn't filtering the transmitted packets from being received, so the IPv6 stack is seeing it's own packets and thinking something else is already using the same address. (This is kind of all conjecture though - I've not done any real debugging on the problem).
I noticed yesterday evening that eventually it does sometimes manage to assign itself an IPv6 address, but you have to wait a lonnng time for that to happen.
Not sure that this is related to your problem, but it may be useful to readers of this list:
We have found that when using some wireless interfaces in infrastructure mode (hosts using an access point), the following occurs.
Assume host A and host B are communicating with the same access point and are within range of each other.
Now ping to B from A. All is well.
Now put the wireless interface on host A into promiscuous mode, say by running tcpdump, wireshare, or arpwatch.
The interface on host A no longer filters wireless frames by MAC address. As a result, it returns to tcpdump, etc. AND to the IP stack all frames it hears. This will include two copies of the ping request: the FRAME going from host A to the access point AND the FRAME going from the access point to host B.
Both frames contain the SAME IP packet. Thus you will receive the packets that you transmit. Likewise, you will see two copies of the packet from host B to host A (from the frame from B to the access point and from the frame from the access point to A).
Researchers often refer to tcpdump as a "passive" tool; it's not quite so in some circumstances, i.e. running it changes the characteristics of the network!
John DeDourek wrote:
Steve Hill wrote:
On Thu, 24 May 2007, David Woodhouse wrote:
Use tcpdump on your machine and on some other machine on the network -- observe the packets you're missing.
Often, observe that when tcpdump puts the interface into promiscuous work it actually starts working because you suddenly _do_ receive the RA packets :)
No, I think the problem is that the NIC isn't filtering the transmitted packets from being received, so the IPv6 stack is seeing it's own packets and thinking something else is already using the same address. (This is kind of all conjecture though - I've not done any real debugging on the problem).
I noticed yesterday evening that eventually it does sometimes manage to assign itself an IPv6 address, but you have to wait a lonnng time for that to happen.
Not sure that this is related to your problem, but it may be useful to readers of this list:
We have found that when using some wireless interfaces in infrastructure mode (hosts using an access point), the following occurs.
Assume host A and host B are communicating with the same access point and are within range of each other.
Now ping to B from A. All is well.
Now put the wireless interface on host A into promiscuous mode, say by running tcpdump, wireshare, or arpwatch.
The interface on host A no longer filters wireless frames by MAC address. As a result, it returns to tcpdump, etc. AND to the IP stack all frames it hears. This will include two copies of the ping request: the FRAME going from host A to the access point AND the FRAME going from the access point to host B. Both frames contain the SAME IP packet. Thus you will receive the packets that you transmit. Likewise, you will see two copies of the packet from host B to host A (from the frame from B to the access point and from the frame from the access point to A).
Researchers often refer to tcpdump as a "passive" tool; it's not quite so in some circumstances, i.e. running it changes the characteristics of the network!
Ooops. Sorry. Meant to say: "Now ping from A to B" not "Now ping from B to A"
On Fri, 2007-05-25 at 09:10 +0100, Steve Hill wrote:
No, I think the problem is that the NIC isn't filtering the transmitted packets from being received, so the IPv6 stack is seeing it's own packets and thinking something else is already using the same address. (This is kind of all conjecture though - I've not done any real debugging on the problem).
I noticed yesterday evening that eventually it does sometimes manage to assign itself an IPv6 address, but you have to wait a lonnng time for that to happen.
That sounds vaguely similar to the problem I see with bcm43xx-mac80211. Which I also haven't debugged yet.
On Fri, 25 May 2007, David Woodhouse wrote:
That sounds vaguely similar to the problem I see with bcm43xx-mac80211. Which I also haven't debugged yet.
Ok, I've done some debugging and posted the results in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241281