Description of problem: Networkmanager applet does NOT accept ipv6 info Version-Release number of selected component (if applicable): NetworkManager-gnome-0.7.996-7.git20091113.fc12.x86_64 NetworkManager-glib-0.7.996-7.git20091113.fc12.x86_64 NetworkManager-0.7.996-7.git20091113.fc12.x86_64 How reproducible: Have machine with working ipv4 eth0. Unconfigure (manually with vi and ifconfig etc) any ipv6 references to interface and to ifcfg-eth0 file. Then rightclick network thingie in system tray. Choose Edit Conenctions, select etho, click edit. Choose ipv6 tab, set to manual, enter number, etc. Enter route, etc. Click OK. Apply all stuff (enter root pass). Go back to applet, verify ipv6 settings to eth0, find them missing. Do ifconfig eth0; find specified ipv6 numer missing. Steps to Reproduce: 1. See above. 2. 3. Actual results: It doesn't work. Expected results: It does work. Additional info: Sever bug. Plesae do not discuss priority nor severity. If basic networking is this buggy I only want to know how to help you fix this. So please do not touch priority nor severity. Ask me/us for info etc. Dec 24 11:25:06 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:25:11 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:25:16 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:25:21 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:25:26 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:25:31 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:25:36 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:25:41 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:25:46 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:25:51 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:25:56 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:26:01 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:26:06 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:26:11 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:26:16 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:26:21 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:26:21 surfplank2 NetworkManager: ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-eth0 Dec 24 11:26:21 surfplank2 NetworkManager: ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-eth0 Dec 24 11:26:22 surfplank2 NetworkManager: ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-eth0 Dec 24 11:26:22 surfplank2 NetworkManager: ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-eth0 Dec 24 11:26:26 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:26:31 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:26:36 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:26:41 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:26:46 surfplank2 pulseaudio[4474]: ratelimit.c: 19 events suppressed Dec 24 11:26:51 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed Dec 24 11:26:56 surfplank2 pulseaudio[4474]: ratelimit.c: 16 events suppressed But no real updates were seen.
Also see https://bugzilla.redhat.com/show_bug.cgi?id=512155 for another issue in this area of design. BTW: the editing of ifcfg-eth0 method DOES work.
https://bugzilla.redhat.com/show_bug.cgi?id=523288 ? Might be an older issue, even, to add pain to the injury...
NetworkManager-gnome-0.7.997-2.git20091214.fc12.x86_64 NetworkManager-glib-0.7.997-2.git20091214.fc12.x86_64 NetworkManager-0.7.997-2.git20091214.fc12.x86_64 do not fix the issue....
udo: Do you have system-wide connections configured? If so, this is a duplicate of bug 523288.
Sharing stuff with all users (none besides me) is the default. (!) But why is it then the same as the bug you mention? I mean: i do not change that share setting, it is already enabled. The right IPv6 number can already be in ifcfg-eth0 or not, it doesn't matter. The info is never accepted. How could this ever be released? Yes, I know it is work from humans, etc, but these are the least complicated tests that the software should be able to pass. FC12 should have (!) matured beyond a certain acceptable point for basic functionalities by now. No, aside from me complaining, how can we find the root cause?
*** This bug has been marked as a duplicate of bug 523288 ***