Hide Forgot
Description of problem: When an interface has 6to4 enabled in it "IPV6TO4INIT=yes" and AUTOCONF enabled "IPV6_AUTOCONF=yes" but no IPv6 Forwarding, Fedora14 correctly enables accept_ra on the base device. Fedora15 incorrectly disables it by improperly applying the sysctl settings to the wrong interface (the base interface instead of the 6to4 tunnel interface itself. It's also highly possible this same error may be occurring for other static sit tunnels by disabling autoconf on the base interface instead of the tunnel interface. Version-Release number of selected component (if applicable): F14 Works properly. F15 Broken. Confirmed in "initscripts-9.30-2.fc15.x86_64" How reproducible: 100% reliable. Steps to Reproduce: 1. Enable 6to4 and autoconf on an interface like eth0 and reboot machine. 2. Check for autoconfigured address on eth0. 3. No autoconf address appears. 4. Disable 6to4 in configuration and repeat. 5. Autoconfig address autoconfigures properly. Actual results: Autoconfiged eth or bridge interfaces fail to accept IPv6 router advertisements in spite of the global accept_ra and forwarding settings. Expected results: Autoconfiged interfaces should receive and process IPv6 router advertisements when received on a non-tunnel interface when forwarding is disabled and accept_ra is globally enabled and in the config. Additional info: The change doing the damage is here: Lines beginning at 614 of network-functions-ipv6 in F15: # Set sysctls proper (regardless "default") /sbin/sysctl -e -w net.ipv6.conf.$SYSCTLDEVICE.forwarding=1 >/dev/null 2>&1 /sbin/sysctl -e -w net.ipv6.conf.$SYSCTLDEVICE.accept_ra=0 >/dev/null 2>&1 /sbin/sysctl -e -w net.ipv6.conf.$SYSCTLDEVICE.accept_redirects=0 >/dev/null 2>&1 Same lines in F14 which behave correctly. Lines beginning at 764 of network-functions-ipv6 in F14: # Set sysctls proper (regardless "default") /sbin/sysctl -e -w net.ipv6.conf.$device.forwarding=1 >/dev/null 2>&1 /sbin/sysctl -e -w net.ipv6.conf.$device.accept_ra=0 >/dev/null 2>&1 /sbin/sysctl -e -w net.ipv6.conf.$device.accept_redirects=0 >/dev/null 2>&1 It's highly questionable if we should be forcing forwarding to be 1 even with static sit tunnels in either case when IPv6 Forwarding is disabled by sysctl or config. It is conceivable to have static sit tunnels where you do not what forwarding. It's even more questionable in the case of 6to4 auto tunnels to force forwarding to be on. The other two settings, accept_ra and accept_redirects are reasonable but probably unnecessary on the tunnel interfaces since those should never appear on a tunnel to begin with. To apply them to the base device, such as the supporting eth device or bridge device, is simply broken behavior. F14 got it right. F15 got it very wrong.
The change you're noting there is simply a sed of s|.|/| on the device name, in order to make sure the right thing happens on VLANs. (See bug 667211/665601) I take it you have '.' in your tunnel device name?
Sorry for taking so long to reply but, no, the tunnel did not have a dot in the name. It was the 6to4 autotunnel set up in the base device configuration like this: DEVICE=eth0 ONBOOT=yes BOOTPROTO=static IPADDR=... NETMASK=255.255.255.0 NETWORK=... BROADCAST=... GATEWAY=... IPV6INIT=yes IPV6_AUTOCONF=yes IPV6TO4INIT=yes That sets up a tunnel on tun6to4. I think it may have been a corner case that was overlooked since the 6to4 autotunnels don't have explicit tunnel configuration files, ifcfg-{tunnel} and are based off the interface.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping